Seite 1 von 1

Performance-Frage, Mysql vs. Python...

Verfasst: Mittwoch 15. Oktober 2008, 22:29
von Voronwe
Hallo, bin relativer Neuling...

ich frage mich gerade, was performance-technisch besser wäre als Lösung für folgende Sache.

In einem mysql-Feld habe ich eine Liste ['foo', 'bar',...] direkt so abgespeichert. Und jetzt möchte ich einzelne Datensätze die einzelne Listenelemente enthalten.

also, was ist besser (Performance): SELECT ... WHERE feld IS LIKE %bla%

oder alle Datensätze aus der Tabelle ausgeben und dann die Liste als Python-Objekt haben und dann mit entsprechendem Befehl durchsuchen?

Ich hoffe ihr versteht was ich meine ;)

Herzlichen Dank schonmal

Verfasst: Mittwoch 15. Oktober 2008, 23:55
von BlackJack
Ausprobieren. Wobei es an sich schon mal ziemlich nach einem Entwurfsfehler bei der Datenbank aussieht eine Liste in einem Feld zu speichern.

Verfasst: Donnerstag 16. Oktober 2008, 13:31
von Voronwe
Danke für die Antwort... naja das so so ein "tag-Feld" sein wie bei Blogs, und da würde ich jetzt keine extra Tabelle für diese Tags machen und die dann verknüpfen...

Verfasst: Donnerstag 16. Oktober 2008, 14:18
von rayo
Hi

Ene N:N Verbindung ist hier eigentlich angebracht.
Da würden 3 Tabellen gebraucht:
Eintrag (Blog oder was du auch immer hast)
Tag (Unabhängig von den Einträgen, alle existierenden Tags)
EintragTag (für jeden Eintrag und Tag gibts hier einen Eintrag)

Somit kannst du deine Like-Abfrage vergessen und ordentliche Abfragen mit join gestalten (eine gute Datenbank kann so eine Abfrage optimieren, deine Like-Abfrage nicht)

Gruss

Verfasst: Donnerstag 16. Oktober 2008, 16:05
von BlackJack
@Voronwe: Wenn die Tags alle in einem Feld stehen, muss man immer *alle* Datsätze anfassen, egal ob nun intern oder extern. Bei einer eigenen Tabelle für die Tags kann man einen Index anlegen und es müssen nur noch die Datensätze angefasst werden, bei denen auch wirklich ein gesuchtes Tag gesetzt ist. Ausserdem muss man bei der ``LIKE``-Lösung aufpassen, dass man die so gestaltet, dass Tagnamen auch Bestandteil von anderen Tagnamen sein können, ohne dass man bei einer Abfrage zu viele Ergebnisse bekommt.

Verfasst: Freitag 17. Oktober 2008, 08:54
von sma
Ergänzend zu meinen Vorrednern: Wenn die Menge der zu durchsuchenden Daten relativ groß im Vergleich zu der Menge der Treffer ist und/oder wenn der DB-Server auf einem anderen Rechner läuft als der Client, wäre mein Tipp, dass die Datenbank das "LIKE" schneller ausführt als wenn man alles zum Client überträgt und dort Python die Suche durchführen lässt.

Ein normalisiertes Datenbankschema, wo die Tags in einer einzelnen Tabelle stehen und eine zweite Tabelle diese auf die Daten abbildet könnte sogar noch schneller sein (und bei großen Datenmengen mit vielen Tags auch weniger Platz verbrauchen da weniger Redundanz vorhanden ist) denn die Datenbank muss jetzt nicht jeden Datensatz laden und prüfen, sondern kann über den Index gehen, der meist effizienter organisiert und möglicherweise immer im Hauptspeicher ist.

Stefan

Verfasst: Montag 20. Oktober 2008, 19:27
von Y0Gi
Normalisierung ist immer gut.

Was ist, wenn du mal ein Tag und alle seine Verwendungen umbenennen willst?

Verfasst: Freitag 7. November 2008, 03:50
von Voronwe
ok, also doch eine Tabelle mit den Tags ;) Danke.

Normalerweise normalisiere ich auch immer alles und vllt. viel zu viel, wollte hier mal was anderes ausprobieren aber wahrscheinlich ist wieder das Bewährte besser... ;)

Verfasst: Freitag 7. November 2008, 08:52
von veers
Wenn du deine Tags in einer separaten Tabelle hast und auf dem ganzen Namen suchst wird das ganze je nach DBMS/Index Typ irgend wo zwischen O(1) und O(log(n)) liegen, wobei n die Anzahl unterschiedlicher Tags ist - was so viel heisst wie schnell ;)

Dein Like '%tag%' ist sehr langsam.

Das war der Praktische, theoretisch ist deine Datenbank wie schon gesagt nicht normalisiert siehe: http://de.wikipedia.org/wiki/Normalisie ... _.281NF.29