Seite 1 von 1

Liste in ein einzelnes DB-Feld?

Verfasst: Dienstag 10. November 2009, 13:24
von Achimt
Gibt es eine Möglichkeit, in einer Tabelle einer Datenbank ein Feld zu definieren, in welches eine Liste geschrieben werden kann? Dabei soll die Liste eine Liste von 0 ... n Integer-Zahlen sein, d.h. in jedem Datensatz anders.


Bsp. einer Definition:
http://paste.pocoo.org/show/149770/

--> "Trupp_IDs XXXXXX"\


Ich weiß, ich könnte Strings mit "," als Trennzeichen erzeugen, in die DB als TEXT schreiben und nach dem Lesen aus der DB wieder zerpflücken.
Wenn ich den/die Datensatz mit der Trupp-ID 1234 filtern will, geht das dann mit

Code: Alles auswählen

sql = "SELECT * from WELT WHERE Trupp_IDs LIKE '%1234%' "
Ich werde aber im Programmlauf '1234' als Variable übergeben müssen.

Gibt es da eine elegantere / einfachere Lösung?

Verfasst: Dienstag 10. November 2009, 13:37
von EyDu
Suchst du vielleicht ein ORM?

Verfasst: Dienstag 10. November 2009, 13:39
von Achimt
hmm, was ist ein ORM?

Ich habe ewig nicht mehr programmiert (zuletzt vor 15 Jahren glaub ich, und das in Pascal) und mit Python erst vor kurzem angefangen.

Verfasst: Dienstag 10. November 2009, 13:42
von EyDu
Das hätte dir Google aber auch gesagt.

Re: Liste in ein einzelnes DB-Feld?

Verfasst: Dienstag 10. November 2009, 13:44
von pillmuncher
Achimt hat geschrieben:Gibt es da eine elegantere / einfachere Lösung?
Ja, normalisiere deine Daten und vermeide es, mehrere Informationen in ein einzelnes Feld zu packen. Hier wirst du geholfen (besonders interessiert dich 1NF).

Gruß,
Mick.

Re: Liste in ein einzelnes DB-Feld?

Verfasst: Dienstag 10. November 2009, 13:44
von /me
Achimt hat geschrieben:Gibt es eine Möglichkeit, in einer Tabelle einer Datenbank ein Feld zu definieren, in welches eine Liste geschrieben werden kann? Dabei soll die Liste eine Liste von 0 ... n Integer-Zahlen sein, d.h. in jedem Datensatz anders.
Bei einer normalen relationalen Datenbank ist das nicht möglich und auch (zu Recht) nicht vorgesehen. In so einem Fall baust du einfach eine zweite Tabelle auf die als Felder zum ersten eine Referenz auf deine erste Tabelle hat (Fremdschlüssel) und zum zweiten ein Feld für eine Integer-Zahl. In dieser Tabelle kannst du dann zu einem Datensatz in der ersten Tabelle beliebige viele Integer-Werte speichern.

Verfasst: Dienstag 10. November 2009, 13:48
von Achimt
Vielen Dank erstmal @all.

Viel Stoff zum Lesen und Lernen...

Re: Liste in ein einzelnes DB-Feld?

Verfasst: Dienstag 10. November 2009, 15:31
von Achimt
/me hat geschrieben: ... In so einem Fall baust du einfach eine zweite Tabelle auf die als Felder zum ersten eine Referenz auf deine erste Tabelle hat (Fremdschlüssel) und zum zweiten ein Feld für eine Integer-Zahl. In dieser Tabelle ....
So einfach scheint es zumindest bei SQLite nicht zu sein
http://glossar.hs-augsburg.de/SQLite_Fo ... _erzwingen

Grundsätzlich scheint mir die Idee mit der zweiten ausgelagerten Tabelle am Besten für mein Problem geeignet zu sein.

Re: Liste in ein einzelnes DB-Feld?

Verfasst: Dienstag 10. November 2009, 16:19
von Käptn Haddock
/me hat geschrieben:
Achimt hat geschrieben:Gibt es eine Möglichkeit, in einer Tabelle einer Datenbank ein Feld zu definieren, in welches eine Liste geschrieben werden kann? Dabei soll die Liste eine Liste von 0 ... n Integer-Zahlen sein, d.h. in jedem Datensatz anders.
Bei einer normalen relationalen Datenbank ist das nicht möglich und auch (zu Recht) nicht vorgesehen. In so einem Fall baust du einfach eine zweite Tabelle auf die als Felder zum ersten eine Referenz auf deine erste Tabelle hat (Fremdschlüssel) und zum zweiten ein Feld für eine Integer-Zahl. In dieser Tabelle kannst du dann zu einem Datensatz in der ersten Tabelle beliebige viele Integer-Werte speichern.
Dem möchte ich ein wenig widersprechen. Sowohl in Oracle als auch in Postgres (Sqlite aber anscheinend nicht) besteht die Möglichkeit Datenbankfelder als Arrays anzulegen, die solche Listen speichern können. Damit sind dann einige Sachen möglich, die einem unter SQL das Leben schwer machen. Ob das jetzt SQL-Standardkonform ist oder hier sinnvoll ist sei nun mal dahin gestellt. Aber es ist vorhanden, funktioniert und hat durchaus eine Berechtigung... ;)

CU Uwe

Re: Liste in ein einzelnes DB-Feld?

Verfasst: Dienstag 10. November 2009, 18:34
von Hyperion
Käptn Haddock hat geschrieben:Damit sind dann einige Sachen möglich, die einem unter SQL das Leben schwer machen. Ob das jetzt SQL-Standardkonform ist oder hier sinnvoll ist sei nun mal dahin gestellt. Aber es ist vorhanden, funktioniert und hat durchaus eine Berechtigung... ;)
Kannst Du da mal bitte ein Beispiel geben?

@Achimt: Ob das RDMS nun foreign keys direkt unterstützt ist nicht entscheident für ein gutes DB-Design ;-) Denn Relationen bleiben nun einmal Relationen, foreign key constraints hin oder her.

Re: Liste in ein einzelnes DB-Feld?

Verfasst: Mittwoch 11. November 2009, 17:31
von veers
Hyperion hat geschrieben:
Käptn Haddock hat geschrieben:Damit sind dann einige Sachen möglich, die einem unter SQL das Leben schwer machen. Ob das jetzt SQL-Standardkonform ist oder hier sinnvoll ist sei nun mal dahin gestellt. Aber es ist vorhanden, funktioniert und hat durchaus eine Berechtigung... ;)
Kannst Du da mal bitte ein Beispiel geben?
Ein Beispiel das ich kenne sind Räumliche Daten bei PostGIS. Eine effiziente SQL Query zur Abfrage aller Polygone in denen der Punkt X enthalten ist zu schreiben macht bestimmt Spass. ;)

Aber ich denke der Punkt da ist das die Daten aus sicht des Datenbankmodelles Atomar sein müssen. Es legt ja auch keine vernünftige Person eine 'Date' Tabelle die aus 'Year', 'Month' und 'Day' besteht an. Oder Bit, Byte und Int etc.

Das ist in diesem Fall aber ganz klar nicht gegeben. Achimt, ich empfehle dir schwer dich zuerst etwas mit Relationalen Datenbanken zu beschäftigen bevor du ein Browsergame baust. Und wenn du damit fertig bist, verwende SqlAlchemy (mit oder ohne ORM) und nicht SQL direkt.

Gruss,
Jonas

Verfasst: Donnerstag 19. November 2009, 17:11
von Achimt
Danke nochmal an alle, die geantwortet haben. Ich versuche mich erst mal an Datenbanken an sich. Werde mich aber an Python und Sqlite abmühen.