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
Performance-Frage, Mysql vs. Python...
die ente ist eine scheibe.
www.simon-says.org
www.simon-says.org
Ausprobieren. Wobei es an sich schon mal ziemlich nach einem Entwurfsfehler bei der Datenbank aussieht eine Liste in einem Feld zu speichern.
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...
die ente ist eine scheibe.
www.simon-says.org
www.simon-says.org
-
- User
- Beiträge: 773
- Registriert: Mittwoch 5. November 2003, 18:06
- Wohnort: Schweiz
- Kontaktdaten:
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
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
@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.
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
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
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...
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...
die ente ist eine scheibe.
www.simon-says.org
www.simon-says.org
- veers
- User
- Beiträge: 1219
- Registriert: Mittwoch 28. Februar 2007, 20:01
- Wohnort: Zürich (CH)
- Kontaktdaten:
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
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
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann