Spezialfall: Speicherung einer Liste in einer Spalte - Nachteile?

[Headbucket]

Hallo,

angenommen ich habe folgende Tabelle 1:

Name	Typ	Others
Foo	A	1,25
Bar	A;B	3,86
Baz	A;B;C	0,98

Zur Zeit speichere ich eine Art Liste in einer einzigen Spalte (Typ) einer Tabelle einer SQLite Datenbank. Das man das nicht tun sollte ist mir bekannt, weshalb ich gerade dabei war das ganze umzustricken:
Erstellung zwei weiterer Tabellen:
- Tabelle 2: Enhält alle möglichen Einträge der Liste (A, B, C, ...)
- Tabelle 3: Enthält die Zuordnung Listeneintrag und Haupttabelle (Foo, A) (Bar, A) (Bar, B) (...)

Nun stelle ich mir aber die Frage, ob es nicht in ganz konkreten Anwendungsfällen doch sinnvoll ist eine Liste in einer einzelnen Spalte abzuspeichern.

Ich habe nämlich zur Zeit folgenden Anwendungsfall:
- Laden der kompletten Tabelle 1 (unbedingt notwendig und auch in Zukunft so)
- Erstellung einer echten Liste in Delphi aus Spalte "Typ"
- fertig

Würde ich die Datenbank nach "Lehrbuch" erstellen dann sähe mein Ablauf folgendermaßen aus:
- Laden der kompletten Tabelle 1
- Laden der kompletten Tabelle 3 und Zuordnung zu den Einträgen aus Tabelle 1
- fertig

Gefühlt sollte die zweite Variante DEUTLICH länger dauern, da ich dort ja extrem viele Abfragen an die Datenbank stellen muss. Bei meiner aktuellen Umsetzung ist es nur eine einzige Abfrage (SELECT * FROM Tabelle 1)
Keine Frage: Würde ich nur Elemente von Typ C auslesen wollen, dann wäre die zweite Variante deutlich schneller, denn ich müsste nicht die komplette Tabelle 1 auslesen. Wenn ich aber sowieso die komplette Tabelle 1 auslesen muss - dann sollte das doch die schnellste Version sein?

Das Auslesen ist leider sehr zeitkritisch, weshalb ich unbedingt so effektiv wie möglich sein möchte. Natürlich gefällt mir Variante 2 besser. Wenn ich dadurch aber statt 1 Sekunde 5 Sekunden brauche dann geht das einfach nicht.

Ich hoffe alles war einigermaßen verständlich.

Ich bedanke mich schonmal!

Grüße
Headbucket

[Blup]

Bis zu welcher Normalform du gehst, ist letztendlich deine Entscheidung.
Der erste Schritt wäre:

Tabelle T1

ID	Name	Others
1	Foo	1,25
2	Bar	3,86
3	Baz	0,98

Tabelle T2

ID_T1	Typ
1	A
2	A
2	B
3	A
3	B
3	C

Wenn zu jedem Typ zusätzliche Daten gehören, würde ich einen Schritt weiter gehen:

Tabelle T1

ID	Name	Others
1	Foo	1,25
2	Bar	3,86
3	Baz	0,98

Tabelle T2

ID_T1	Typ	Info
101	A	InfoA
102	B	InfoB
103	C	InfoC

Tabelle T3

ID_T1	ID_T2
1	101
2	101
2	102
3	101
3	102
3	103

Beim Lesen der Daten kommt man trotzdem mit einer Abfrage aus:

Code:

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

Delphi-Quellcode:

  while not Query.EOF do
  begin
    if (not Assigned(MyObject)) or (MyObject.ID <> Query.FieldByName('ID').AsInteger) then
    begin
      MyObject := TMyObject.Create;
      MyObject.ID := Query.FieldByName('ID').AsInteger;
      MyObject.Name :=  Query.FieldByName('Name').AsString;
      {...}
      MyList.Add(MyObject);
    end;
    if Query.FieldByName('ID_T2').AsInteger <> 0 then
    begin
      MyObjectTyp := TMyObjectTyp.Create;
      MyObjectTyp.ID_T1 := Query.FieldByName('ID').AsInteger;
      MyObjectTyp.ID_T2 := Query.FieldByName('ID_T2').AsInteger;
      {...}
      MyObject.Items.Add(MyObjectTyp);
    end;
    Query.Next;
  end;

Der zeitliche Mehraufwand dürfte kaum spürbar sein.

[p80286]

Falls "Typ" ein String zur näheren Beschreibung ist, dann ändere nichts daran.
Sollte aber irgendwann einmal nach dem Typen "A" suchen oder nach "A" or "B" and not "C", dann kannst Du die Eintabellenlösung vergessen.

und sooo viel langsamer ist die 3Tabellenlösung nur wenn die DB von einem echten Greenhorn definiert wurde.

Gruß
K-H
p.s.
Falls als Ausgabe unbedingt eine "Typliste" /A;B..;Z) gefragt ist, wird es etwas umständlicher.

[Jumpy]

Je nach DB, kann man sich die Liste mit einer GroupConcat-Funktion zusammenstellen, so dass man auch in Fall2 mit einem einzigen SQL-Aufruf auskommt.

Edit: Sehe gerade DB is SQLite, da gäbe es sowas: guckst du

[jobo]

Ich würde da differenzieren, in welcher Form ich Zugriff auf einzelne Elemente einer der Listen aus T1 benötige.
Geht es nur um "Pauschalzugriff" auf ein Set von Listen, dass durch distinkte Werte in anderen Spalten definiert ist, kann man wohl auf die Normalisierung verzichten.
Benötige ich dagegen gezielten Zugriff auf Einzelwerte aus einer oder mehreren Listen, wird es kritisch, besonders wenn diese Einzelwerte wieder weitere Relationen definieren oder bei Reports einzeln ausgewertet werden müssen.

Daten für Business Logik würde ich immer ausmodellieren. Nutz/Rohdaten dagegen, die an anderer Stelle von autarken Algorithmen en block verarbeitet werden, kann man m.E. auch gut en blocl speichern.

Bsp:
Id|Liste
12|A;B;C

Ein "Select Liste from BSP where ID =12" ist unproblematisch.
Ein "Select ID from BSP where Liste like '%B%" dagegen ist schon mehr als unschön. Standard Index ist nicht mehr nutzbar, komplexere Kriterien sind ggF. nur noch per Regex abzufragen, ..

P.S.: Der Hinweis von Jumpy ist auch sehr bedenkenswert. Die reine Speicherung der Werte ist eine andere Frage als die Nutzung / Darstellung. Aus einer relationalen Speicherung kann ich problemlos beliebige Aggregate erstellen, auch mit guter Geschwindigkeit. Umgekehrt ein gespeichertes Aggregat zu "verformen" oder zu zerpflücken, macht nicht so einen Spaß.

[Headbucket]

Vielen Dank für die zahlreichen Antworten!

Bei Typ handelt es sich tatsächlich um einen String. Nichtsdestotrotz werde ich es dann wohl doch mal auf einen Versuch ankommen lassen und die Speicherung umstellen. Dazu habt ihr mich nun bekräftigt.

Vielen Dank und ein schönes Wochenende!

[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