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.