hts

Hi Leute,

ich poste mein Problem mal in den OT-Bereich.

Ich habe eine CSV-Datei mit knapp 2000 Variablen, die ich in unsere Datenbank importieren muss. Jede Variable kann dabei die besonderen Werte "nicht dokumentiert" und "nicht anwendbar" annehmen. Anscheinend ist es den Leuten wichtig zu unterscheiden, ob der Wert vegessen/noch nicht erfasst wurde oder eben einer der zwei o.g. Status zutrifft.

Bei Optionslisten, die ich an unserer Datenbankoberfläche per Drop-Down abbilden kann, ist das kein Problem. Kopfzerbrechen bereiten mir die Integer-Felder, hier werden diese speziellen Werte mit hohen Int-Werten kodiert (8888 und 9999), die nicht im normalen Wertebereich liegen. Bei Datumsfeldern wird eine Kodierung mit weit entfernten Zeitpunkten (Jahr 2111 und 2222) benutzt.

Meint ihr, man kann diese vorhandene Kodierung übernehmen? Weil richtig erscheint mir dieses Vorgehen nicht, aber noch zusätzlich für jedes Feld in der DB ein Flag zu hinterlegen + an der Oberfläche ein Drop-Down erscheint mir auch nicht praktikabel. Wie würdet ihr vorgehen?

Mister Ad

mimomamu

Wie sieht denn die aus? Eine Variable pro Zeile? Eine Variable pro Spalte? Was sind das denn für Variablen übrhaupt?

Da würde ich ansetzen. Frag den Auftraggeber, warum das wichtig ist. Bestenfalls bekommst du dann zu hören: "Ach, so wichtig ist das nicht. Wenn das Probleme macht, dann kannste das einfach weglassen".

__________________
Meinungen, die ich geäußert habe, sind nicht notwendigerweise meine eigenen. Abweichungen von der deutschen Rechtschreibung unterliegen dem Urheberrecht, dürfen aber unter den Bedingungen von verwendet werden

ChrisB

Vergessen/noch nicht erfasst wäre für mich NULL.

Die genannten Statii wären dann noch separat abzubilden. Das würde ich dann aber wirklich über entsprechende Kennzeichen machen, und nicht einfach irgendwelche Werte dafür missbrauchen.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

Wolla

Falls die Werte grundsätzlich nur positiv sein können, so kann man die gewünschten Ausprägungen mit -1 und -2 abbilden.
Ansonsten helfen nur flags: 0=zahl gilt, 1=nicht dokumentiert, 2=nicht anwendbar

__________________
Warum denkt mein Hund eigentlich immer dann, wenn es an der Tür klingelt, es sei für ihn?

hts

Die Daten stammen aus SPSS (Statistik-Programm). Das kannst du dir als eine große "Excel"-Tabelle vorstellen. Ich frage mich, wie die Leute bei der Dateneingabe überhaupt damit klargekommen sind.
Jede Zeile entspricht einem Patienten, die 2000 Spalten stellen medizinische Messwerte (Herzfrequenz, Blutdruck, Laborwerte, etc.) dar.

Ja, werde ich wohl machen, wollte nur vorher hier im Forum andere Ideen/Meinungen hören. Wobei ich mir aufgrund der Datenart (Medizin/Rettungsstation) denken kann, das dies schon wichtig ist

Also für jedes Feld ein zusätzliches Status-Flag. Ist aber sehr umständlich für die Datenerfassung, ich gehe hier aber mit dir prinzipiell konform.
Was wäre für dich das stichaltigste Argument gegen die Kodierung mit Sonderwerten?

@Wolla
Negative Zahlen sind nun auch nicht besser. Datumsfelder gibt es außerdem noch.

ChrisB

Dass das nicht sonderlich intuitiv ist, und dass dabei Daten eine ganz andere Bedeutung zugemessen bekommen.
Und dass sowas immer wieder lustig wird, wenn irgendwann der Fall eintritt, dass so ein „Sonderwert“ dann plötzlich doch mal als normales Datum auftaucht - vielleicht auch erst in der Zukunft.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

hts

Ich wollte gerade schreiben, dass das egal ist, da ich das nicht mehr erlebe, zumindest für die Datumswerte ...

Aber dieses Argument sticht: sämtliche Datenbankabfragen -Berechnungen müssten dann auch diese Sonderfälle berücksichtigen (Blutdruck > x, MessertY fehlt=>NULL, Durchschnitt Gewicht) und auch alle externen Programme zur weiteren Berechnung/Statistik nach einem Datenexport.

mquadrat

Jep genau das ist der Hauptgrund, warum das Probleme macht.

DB NULL ist imho auch keine Lösung, da das im Programmverlauf zu "echten" Werten wie int 0 werden könnte.

__________________
Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

hts

So, hab' ich gemacht und der "worst case" ist eingetreten. Es soll wirklich für jedes Feld ein zusätzlicher Status erfassbar sein, wenn keine Daten vorliegen.

ChrisB

NULL ist für solche Fälle gedacht.
Wenn (d)ein Script damit nicht korrekt umgehen kann, ist das doch kein Problem des Datenmodells.

Und warum ist das jetzt der worst case ...?
Du hast noch mal explizit bestätigt bekommen, dass du es vernünftig machen sollst.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?