# Datentyp der Spalte beim Datenbankdesign unbekannt



## javagui (11. Aug 2012)

Hallo zusammen,

ich habe eine Tabelle in der die Die Feldnamen und Datentypen einer Spalte variieren. Also z.B.
Zeile;Feldname; Wert
1;Stadt;Berlin
2;Fahrzeugtyp;100
3;Seriennr;x2k9Irgendwas
4;Wann;18.3.2012

kann bei einem anderen auch so ausehen:
Zeile;Feldname; Wert
1;StadtId;12
2;KFZ-Nr;RE-XY 123
3;Flughafen;x2k9Irgendwas
4;Start;12.3.2012

Mein Ansatz ist zunächst, drei Tabellen zu benutzen in  denen die möglichen Feldname:Wert-Paare mit Typ definiert werden. Für die Speicherung in der DB wird dann alles auf String gecastet.
1. Tabelle Feldtypen beschreibt die möglichen Feldtypen.
2. Datendef-Tab enthält die Feldnamen mit Positionen und Verweisen auf den Feldtyp.
3. Daten-Tab hat Verweise auf Feldname;Typ;Wert

Tabelle Feldtypen beschreibt die möglichen Feldtypen:
Zeile;Feldname; Beschreibung
1;int;Ganzzahl
2;numeric;Kommazahl
3;date;Datum
4;char;alphanumerisch

Datendef-Tab enthält die Feldnamen mit Positionen und Verweisen auf den Feldtyp.
Zeile;Feldname;Beschreibung;prio;Feldtyp
1;Stadt;Stadt;1;4
2;Fahrzeugtyp;Fahrzeugtyp;2;1
3;Wann;Datum;4;3.

Daten-Tab enthält dann die eigentlichen Werte;
Zeile;Datendef-Tab-Id;prio;wert
1;1;1;Berlin
2;2;2;100
4;3;4;18.3.2012

So richtig glücklich bin ich aber mit dieser Lösung nicht.
Vielleicht beschreibt Ihr kurz mal Eure Vorgehensweise.

Gruß javagui


----------



## Gast2 (11. Aug 2012)

Moin,

ich bin fasziniert wieso alle Welt immer versucht Unbekanntes (welches definitiv irgendwann Bytes von 0 bis 31 enthält) in einem String zu speichern. Das sind simple binäre Daten - dafür gibt es auch entsprechende Datentypen.

hand, mogel


----------



## javagui (11. Aug 2012)

Danke für den Hinweis, da treibts einen wohl in die eingetretenen Pfade.

OK, kein String, dann ist der Wert wohl immer ein character-Array. Aber ich bin mit der 3-tabellen-Logik nicht so besonders im Wohlfühlbereich.


----------



## Camino (11. Aug 2012)

javagui hat gesagt.:


> Aber ich bin mit der 3-tabellen-Logik nicht so besonders im Wohlfühlbereich.



Ich versteh auch noch nicht so ganz, wozu das gut sein soll. Sinn einer Datenbank ist doch, dass die Daten/Datensätze eine gleiche Struktur haben. Warum sollte in einer Tabelle in einer Spalte einmal eine Seriennummer und ein anderes mal ein Flughafen stehen?


----------



## Gast2 (11. Aug 2012)

javagui hat gesagt.:


> Danke für den Hinweis, da treibts einen wohl in die eingetretenen Pfade.


und wieder treibt es Dich in die eingetretenen Pfad



> OK, kein String, dann ist der Wert wohl immer ein character-Array.


fühle die Macht und vertraue dem BLOB, mein junger Padawan

ansonsten - was Du versuchst in Zeilen zu speichern ist alles ein Datensatz, kommt also alles in eine Zeile in verschiedenen Spalten


----------



## javagui (11. Aug 2012)

Ich glaube, ich hab die Anforderungen nicht gut beschrieben. Also:
Der Nutzer bearbeitet eine Tabelle:
Feldname;Wert
Feld1;10
Feld2;Venedig
Feld4;RE-BX 789
Feld5;X57-123ABC897

Dabei sind sowohl die Feldnamen als auch die Werte unbekannt. Feld2 kann bei dem einen Kunden Flughafen sein "Flughafen:Berlin", beim nächsten ist es "KFZ-Kennzeichen:RE-BL 786", bein Dritten "Datum:12.10.2011", beim Vierten "Warenwert:10.000". Nach mogels Hinweis sind es aber wohl immer Paare der Art Feldname/Character. Gegebüber BLOB hat das den Vortei, dass die Wertepaare in der DB für lesbar bleiben. 

Gegen eine einheitliche Satz/Tabellenstruuktur spricht die Vielzahl der Möglichkeiten.
Die möglichen Feldname:Wert-Paare (z.B. Flughafen:Character oder Warenwert:currency" kann eine weitere Tabelle definieren.

Schönen Abbent


----------



## Camino (12. Aug 2012)

Kannst du mal genauer beschreiben, was der Sinn so einer Tabelle sein soll, also für welchen Zweck das eingesetzt wird? Ich vermute ja, dass sich das bestimmt anders/besser strukturieren lassen könnte.


----------



## mla.rue (13. Aug 2012)

kann mich meinem Vorredner nur anschließen, der Sinn so einer "Struktur" erschließt sich mir jedenfalls nicht so wirklich.


----------



## javagui (13. Aug 2012)

Na, es gibt n Kunden die für Lieferungen leider auch n verschiedene Kennwerte benutzen. Dem einen ist das Kennzeichen des Lieferfahrzeugs wichtig, dem anderen die Nummer des Fliegers, dem nächsten eine Dokumentenkennung. Und das variiert noch innerhalb der Unternehmen pro Abteilung. Leider gibt es momentan zu viele Unbekannte. Damit das über Einstellungen konfigurierbar bleibt und ich nicht jedesmal die Source anpassen muss, lande ich bei einer Konfig über Tabellen.

Also gekürzt:
Eine Tabelle enthält mögliche Feldtypen, also int, decimal, char,date.
Eine Tabelle enthält Feldname,Datentyp,Sortfolge.
Eine Tabelle definiert Sets von Feldnamen (die können in verschiedenen Abteilungen unterschiedliche sein).
Eine Tabelle enthält die operativen Daten, also Liefer-Id,Id des Feldnamen, Wert.

So kann ich die zu bearbeitenden Feldname:Wert-Paare über ein feines Konfig-Formular pro Kunde/Abteilung, wenns sein muss pro Arbeitsplatz einstellen, ohne an die Sourcen zu müssen.

Vielleicht bin ich a wengel betriebsblind, aber ich sehe nicht wie ich das in eine feste Struktur giesse, die auch noch möglichst wartungsarm bleibt.

Schuftet nicht zu dolle, schönen Tag noch, Pott's steigert die Intelligenz.


----------



## areafo (13. Aug 2012)

So ich trage hier mal was bei 

Und paar Gedanken:

- Feldnamen sollten gleich bleiben und nicht vom Inhalt abhängen
- Datensätze in relationalen Datenbanken sollten normalisiert
- bei nicht klaren Datentypen immer den höchstmöglichen / generischsten nehmen. In deinem Fall String >>> daraus ergibt sich natürlich eine Typunsicherheit

So das wars

Hab mir die "Problemstellung" nochmal angeschaut

Das Vorhaben widerspricht dem Sinn einer relationalen Datenbank und wird hier nur als Strukturspeicher mit Datenhaltung genutzt.

Mann sollte die Strukturbeschreibung vielleicht auslagern in XML und die Datenhaltung normalisiert vollbringen.

Auch wenn es schwer ist aber alles lässt sich normalisieren


----------



## mla.rue (13. Aug 2012)

Aha ok ich verstehe dein Problem, dein Lösungsansatz widerspricht aber, wie schon erwähnt, dem Sinn einer relationalen Datenbank.

Vorschlag: mach eine Tabelle mit ALLEN notwendigen Spalten, mit den entsprechenden Datentypen. Welche Spalten angezeigt/geladen/gespeichert werden löst du mit deinem Code (GUI etc). Ob diese (z.B. 4) Spalten und deren Prioritäten in einer Config Datei stehen, oder in der Kundentabelle gespeichert werden, ob in separaten Spalten, oder in einer steigender (Priorität) Reihenfolge. Alles deine Entscheidung.

Dynamische Spaltennamen + dynamische Datentypen der Spalten müsste deine DB unterstützten, ich kenne ersteinmal keine, die das kann.

Habe Vergleichbares gehabt. Tabelle mit 10 Werten, wobei jedem Kunden eine andere Spalte wichtig war, mal 2, mal 3, mal 10. Kontextmenü eingebaut, mit dem Sich die Spalten aktivieren/deaktivieren lassen, so hat jeder was er will, wie er will.


----------



## bone2 (13. Aug 2012)

hat jede abteilung nur einen datensatz? nimm nen properties. Sowas baut man einfach nicht in eine datenbank. das ist doch keine basis da was sinnvolles ranzuhängen. wozu noch ne datenbank, für chaotische daten tut es auch eine binärdatei.
Da bekommt jede abteilung richtig eine eigene datenbank und programm dazu.

alternativ wäre noch noSql und objekte speichern, oder wie schon genannt eine sehr breite tabelle die alle möglichkeiten abdeckt...


----------



## javagui (13. Aug 2012)

Danke für die Diskussion,

ich werd wohl erst mal mla.rues Vorschlag folgen und später, falls das nicht mehr reicht ein HBase oder so was dranhängen.

Vielen Dank allen.


----------

