Mapping von NULL auf primitive Datentypen, wie genau?

[s.h.a.r.k]

Hallo zusammen,

ich sitze gerade noch vor dem Rechner, weil ich ein Problem habe, welches ich auf die schnell nicht sinnvoll lösen kann. In meinem Fall ist es so, dass ich Daten aus Datenbank A laden und in Datenbank B speichern muss. Dies mache ich über mein Programm, da die Daten nocht nicht ganz reif für DB B sind.

Jedenfalls bin ich gerade an der Stelle, wo ich die Daten lade und diese auf Klassen mappe, was ja *eigentlich* kein Problem ist, bis auf diese dummen NULL-Werte eben. Bei Strings sehe ich da ja weniger das Problem, da ich dann einfach einen Leerstring habe, aber wie schaut das bei anderen Datentypen aus?

Code:

String  -> '' (Leerstring)
Integer -> ?
Float   -> ?
Boolean -> ?

Oder gibt es da andere Möglichkeiten? Ich habe es bisher noch nicht geschafft ein NULL einem String zuzuweisen :mrgreen:

Eine andere Möglichkeit wäre es ja, jede Eigenschaft einer Klasse als TValue (AnyDAC) oder TField (soweit ich weiß spuckt das ADO aus, wenn man ein Feld aus einem Dataset ausliest) angibt, aber dann erhöht sich zum einen der Aufwand bei der weiteren Programmierung und zum anderen ist das einfach ein Overkill (Speicher/Performance).

[mkinzler]

Man könnte Variants verwenden. Bei den Integer/Float-Typen müsstest du sonst einen Wert opfern

[Sherlock]

Bei den numerischen Werten hilft es ungemein zu wissen, welchen Wertebereich es gibt. Entsprechend wäre ein WErt ausserhalb des Wertebereichs als NULL anzusehen. Zur Not kannst Du halt sowas wie MAXINT als NULL verwenden.

Sherlock

[Blup]

Zitat:

Zitat von s.h.a.r.k

Eine andere Möglichkeit wäre es ja, jede Eigenschaft einer Klasse als TValue (AnyDAC) oder TField (soweit ich weiß spuckt das ADO aus, wenn man ein Feld aus einem Dataset ausliest) angibt, aber dann erhöht sich zum einen der Aufwand bei der weiteren Programmierung und zum anderen ist das einfach ein Overkill (Speicher/Performance).

Ich habe Datenimports /-exports mit Datenobjekten programmiert die eigene Feldobjekte haben und auch mit simplen Objekten nur mit Feldern. Von der Geschwindigkeit macht das keinen merklichen Unterschied. Der Speicherbedarf ist etwa doppelt so groß, aber auf aktuellen Systemen spielt auch das keine Rolle. Der Programmieraufwand ist in etwa gleich. Zumindest muss man nicht rätseln ob mit -1 nun Null oder in diesem Feld tatsächlich -1 gemeint ist. Das ist besonders bei der nachträglichen Pflege der Software ein nicht zu unterschätzender Vorteil.

[alzaimar]

[quote="s.h.a.r.k"]Bei Strings sehe ich da ja weniger das Problem, da ich dann einfach einen Leerstring habe.../quote] Nein! Es ist ein Riesenunterschied, ob man keine Telefonnummer hat (Leerstring) oder sie noch nicht angegeben hat (NULL).

Verwende Variants und spezielle Routinen (VarToStr, VarToInt), um Null-Werte in den einzelnen Datentypen darzustellen. Und hier kann man ja den Leerstring und 0-Werte verwenden...

Aber nur für die Darstellung, sonst geht dir Information verloren (also nicht konvertieren).

So machen es übrigens auch die TField-Derivate: Die Eigenschaften 'AsString', 'AsInteger' usw. liefern für NULL keine Exception, sondern eben ein 'leer', also '', 0, 0.00 usw.

[s.h.a.r.k]

Danke für euer Feedback. Die Idee mit einem eigenen Datenobjekten gefällt mir an sich recht gut, obwohl es dann halt wieder darauf hinaus läuft, dass es ein Mehraufwand darstellt :zwinker:

Über Variants habe ich gelesen, dass diese eher langsam im Vergleich zu den primitiven Datentypen sind, daher wollte ich darauf bisher eher verzichten. Aber ich will halt auch nicht einen Wert aus dem Wertebereich opfern müssen. Den Leerstring als NULL anzusehen ist, wie schon richtig bemerkt, auch nicht Sinn der Sache.

Ich glaube aber, dass es auf Variants hinauslaufen wird, zumindest meiner ersten Einschätzung nach. Man muss somit nicht all zu viel anpassen, wenn man schon fertige Objekte etc. hat und kann diesen Typ halt leicht in andere Formate umwandeln.