Performance-Frage, Mysql vs. Python...

[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

[BlackJack]

Ausprobieren. Wobei es an sich schon mal ziemlich nach einem Entwurfsfehler bei der Datenbank aussieht eine Liste in einem Feld zu speichern.

[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...

[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

[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.

[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

[Y0Gi]

Normalisierung ist immer gut.

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

[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...

[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