Spezialfall: Speicherung einer Liste in einer Spalte - Nachteile?

[jobo]

Um das Thema noch etwas einzuordnen bzw. zur Diskussion:

Also nehmen wir denn Fall, dass die Daten keinen weiteren, relevanten Bezug zu anderen Tabellen aufweisen außer zu dem Satz, unter dem sie gespeichert wurden. (Bspw. sowas wie Messwerte Wetterstation, ..)

Für mich ist das die / eine Grenze zum noSQL Bereich. Und zwar nicht im Sinne einer ganz oder garnicht Ideologie, sondern einer praxisbezogenen Anforderungsvielfalt.
Ich sage gleich dazu, dass ich keine nennenswerten Erfahrungen mit reinem noSQL Systemen habe.
Ich sehe es aber so, dass ein sklavisches Normalisieren eben nicht unbedingt Sinn macht, abhängig von der Weiterverwendung der Daten. Listen, Dokumentdaten, JSON, XML, BLOB .. können in einer Form vorliegen oder verwendet werden, die den Nutzen von SQL und relationalen Strukturen einschränkt bzw. keine Vorteile bringt.
Wo im Einzelfall die Grenze zu ziehen ist, muss natürlich von Fall zu Fall geklärt werden. Es bietet sich dann aber an, andere Wege zu gehen, bspw. ein Mischbetrieb mit DB-Systemen, die dazu gute Funktionalität mitbringen oder natürlich der Schwenk auf Application Server, Clients, die auf die Verarbeitung dieser Datenstrukturen optimiert sind.

[hoika]

Hallo,

Delphi-Quellcode:

select t1.id, t1.name, t1.Others, t3.id_t2, t2.typ, t.info 
from      t1
left join t3 on t3.id_t1 = t1.id
left join t2 on t2.id = t3.id_t2

Ohne das Left Join geht es viel schneller.

[p80286]

Zitat von hoika:

Ohne das Left Join geht es viel schneller.

Viel schneller?
Kommt darauf an, wie die Fragestellung ist. Wenn im Ergebnis nur Datensätze mit einem "Typ" auftauchen sollen, kann man auf das Left verzichten.
Wenn man wissen will wo der "Typ" fehlt muß man es mit Left machen, oder aber mit exists. Wobei ich ein join left mit einem xID is null bevorzuge, Das ist aber wohl stark von der DB abhängig.

Gruß
K-H

[Headbucket]

Hallo zusammen,

ich konnte die Ratschläge inzwischen umsetzen und möchte euch nun (der Vollständigkeit halber) meine Lösung darstellen.

Meine ursprüngliche Umsetzung bestand aus einer Tabelle. Für das komplette Einlesen von 5000 Datensätzen benötigte ich ca. 110 ms (SQLite-Abfrage + Delphi-Prozedur).
Mein Ziel bestand also darin nicht langsamer zu werden.

Ich habe mich für die erste Normalform entschieden, welche sehr gut im zweiten Beitrag von Blup zu sehen ist. Die reine SQLite-Abfrage dauerte nur unwesentlich länger als früher. Da ich aber in meinem Programm aus jedem Datenbankeintrag ein Objekt erzeuge, hat es hier deutlich länger gedauert. Das hing damit zusammen: Früher war Anzahl der Datensätze = Anzahl zu erzeugender Objekte. Nun habe ich aber für ein und dasselbe Objekt mehrere Datensätze gehabt - halt für jeden Listeneintrag eine Zeile. Deshalb musste ich in Delphi dann natürlich jedes mal schauen, ob es das Objekt schon gibt und ggf. nur ergänzen. Das ganze hat dann direkt mal stolze 1170 ms gedauert.

Eine kleine Optimierung konnte ich noch vornehmen indem ich bei der Abfrage nach der ID sortiert habe. Auf diese Weise musste ich in meiner Schleife zur Erzeugung der Objekte lediglich prüfen, ob sich die ID ändert (=neues Objekt). Damit kam ich immerhin auf 460 ms. Hier war das Problem, dass ich die Objekte noch sortieren musste, da ich sie später natürlich NICHT nach der ID sortiert haben wollte.

Meine endgültige Lösung sieht nun so aus:

Code:

SELECT T1.Name, T1.Others, GROUP_CONCAT(T2.Typ) AS Typ
FROM T1 
JOIN T2 ON T1.ID = T2.ID 
GROUP BY T1.ID
ORDER BY T1.Name

Damit bekomme ich für meinen Listentyp in der Abfrage wieder eine Liste, welche ich nach meiner alten Methode umwandeln kann. Die Anzahl der Datensätze entspricht wieder der Anzahl der zu erzeugenden Objekte und das ganze dauert 94 ms und ist bereits sortiert. Ich weiß, dass man ORDER BY möglichst vermeiden sollte. Jedoch bekomme ich es in Delphi zZ nicht schneller hin. Ich kann mir auch nicht erklären, wieso es auf einmal schneller ist als am Anfang, da die Abfrage ja doch minimal länger dauert. Aber natürlich sind die Zeiten hier auch nur sehr grobe Anhaltspunkte.

Somit hat die Datenbank nun eine bessere Struktur, was vernünftigere Abfragen zulässt. Für meinen speziellen Fall (alle Daten auslesen) habe ich auch eine Lösung gefunden schnell an die Daten zu kommen. Ein LEFT JOIN kommt übrigens nicht in Frage, da ZWINGEND ein Eintrag in Tabelle 2 für jeden Eintrag in Tabelle 1 existieren muss.

Grüße
Headbucket