NULL oder ''

[UlZi]

Es gibt da aber leider noch ein anderes Problem.

MS ACCESS erlaubt keine '' in Textfeldern, wenn man es ihm nicht explizit sagt. Dies ist aber nicht möglich, wenn man die Tabellen über ODBC erstellt.

Siehe dazu auch meinen Beitrag:

"Leere Strings über SQL zulassen"

Ich bin auf dieses Problem gestoßen, weil ich von Java aus per JDBC-ODBC '' in Textfelder schreiben wollte. Leider macht die JVM das nicht mit und schmiert gnadenlos ab. NULL's lassen sich aber problemlos schreiben.

Was die sich wohl dabei gedacht haben

Zu dem zusätzlichen Bit wegen dem NULL-Eintrag: Ich glaube nicht, daß das speicherplatzmäßig auffällt. Schaut Euch Eure Datenbanken mal an.

The never ending story: NULL or NOT NULL ...ich bin da auch immer wieder am grübeln.

EDIT:

---

beitrag verlinkt.... Abraxax

---

[Abraxax]

Original geschrieben von Troublegum
Ich würde sagen, NULL brauchst du nur, wenn du zwischen einer leeren Eingabe und keiner Eingabe unterscheiden musst. Aber mir fällt da im Moment kein Beispiel ein, wo das notwendig wäre.

mir fällt auch kein beispiel ein....

denn wenn ich eine FORM hab und die poste, so habe ich auch bei den feldern wo keine eingabe ist, einen leeren string enthalten...

[Troublegum]

Ich würde sagen, NULL brauchst du nur, wenn du zwischen einer leeren Eingabe und keiner Eingabe unterscheiden musst. Aber mir fällt da im Moment kein Beispiel ein, wo das notwendig wäre.

[Abraxax]

hey vielen dank für die ausführliche erläuterung. jetzt habe ich es auch kapiert.

und aus ...

(Diese Entfernung von Leerzeichen weicht von der ANSI-SQL-Spezifikation ab.)

... ist auch meine info gewesen. ich nahm ja an, dass aufgefüllt wird. und da es nicht gefüllt wird, werde ich jetzt '' verwenden...

denoch eine frage dann zu NULL : wann macht das dann überhaupt noch sinn?

[wahsaga]

Original geschrieben von Abraxax
habe ich dann richtig verstanden, dass bei VARCHAR(30) nur das stingende enthalten ist, wenn kein inhalt da ist, und nicht, wie ich angenommen habe, 30 zeichen reserviert werden?

zitat manual:
Werte in VARCHAR-Spalten sind Zeichenketten variabler Länge. Sie können eine VARCHAR-Spalte mit jeder Länge zwischen 1 und 255 deklarieren, genau wie für CHAR-Spalten. Im Gegensatz zu CHAR werden VARCHAR-Werte jedoch nur mit so vielen Zeichen wie nötig gespeichert, plus 1 Byte, um die Länge zu speichern. Die Werte werden nicht aufgefüllt; statt dessen werden Leerzeichen am Ende beim Speichern entfernt. (Diese Entfernung von Leerzeichen weicht von der ANSI-SQL-Spezifikation ab.)

das mit der binären null als stringende hab ich aus C übernommen, kann nicht sicher sagen ob mysql die daten auch genau so abspeichert, aber ich denke mal schon.
aber wie du am zitat siehst, verbraucht ein leeres varchar-feld auch nur ein oder zwei byte (je nachdem, ob in so einem fall nur länge=0 abgespeichert wird, oder länge=1 und erstes zeichen dann binäre null. ich vermute aber ersteres).

[MelloPie]

wegnormalisieren im Sinne von :

wenn in einer Tabelle eine Spalte oft leer oder null ist, dann nimm sie aus der Tabelle und referenziere Sie auf die Mastertabelle...
Da gehts nicht um auto_increment werte, die dürfen sowieso nicht null sein...

[Abraxax]

ok. klingt logisch und habe ich auch verstanden... werde wohl daher auf NOT NULL umsteigen (müssen). macht die arbeit ja auch leichter.

habe ich dann richtig verstanden, dass bei VARCHAR(30) nur das stingende enthalten ist, wenn kein inhalt da ist, und nicht, wie ich angenommen habe, 30 zeichen reserviert werden?

[wahsaga]

Original geschrieben von Abraxax
was das hier betrifft ...... so verstehe ich spontan nicht, warum ich dadurch ein bit sparen kann. eigentlich war ich nämlich davon ausgegangen, dass das NULL die kleinste einheit ist.

wenn ich z.b. VARCHAR(30) habe, so werden mir 30 zeichen im eintrag reserviert in der tabelle. auch wenn ich nur ein zeichen oder keines dort stehen habe. wenn ich NULL habe, so wird nichts reserviert. das war zumindest meine bisherige information.

zitat mysql-manual:
Jede NULL-Spalte benötigt ein zusätzliches Bit, gerundet auf das nächste Byte.

(es wird davon ausgegangen, dass du im normalfall deine felder überwiegend mit werten füllst anstatt sie leer zu lassen.)

wenn du jetzt ein feld mit NULL definiert hast, muss es ja noch irgendein kennzeichen geben, ob der wert jetzt wirklich NULL ist oder einfach nur ein integer mit wert 0 oder ein string der nur eine binäre null (stringendezeichen) enthält.
denn ohne dieses kennzeichen kannst du nicht feststellen, ob 0 jetzt integer-0 (bzw. stringende) bedeutet, oder wirklich ein feld darstellt dem noch gar kein wert zugewiesen wurde.

bei einer NOT NULL spalte bedeutet 0 jetzt aber auf jeden fall eine integer-null, du brauchst hier also dieses kennzeichen nicht und hast also ein bit gespart.

[Abraxax]

also bei JOINs verwende ich schon id-felder und die sind natürlich nicht NULL sondern haben in der regel, wie es auch sein sollte, einen autoincrement enthalten. eine 'wegnormalisierung' kann damit eigentlich nicht stattfinden. oder?

was das hier betrifft ...

Deklarieren Sie Spalten - falls möglich - als NOT NULL. Das macht alles schneller und Sie sparen ein Bit pro Spalte. Beachten Sie, dass, wenn Sie wirklich NULL in Ihrer Applikation benötigen, Sie dieses natürlich benutzen sollten. Vermeiden Sie nur, einfach alle Spalten vorgabemäßig auf NULL zu haben.

... so verstehe ich spontan nicht, warum ich dadurch ein bit sparen kann. eigentlich war ich nämlich davon ausgegangen, dass das NULL die kleinste einheit ist.

wenn ich z.b. VARCHAR(30) habe, so werden mir 30 zeichen im eintrag reserviert in der tabelle. auch wenn ich nur ein zeichen oder keines dort stehen habe. wenn ich NULL habe, so wird nichts reserviert. das war zumindest meine bisherige information.

kann mich hier mal bitte jemand aufklären?

wenn es aber alles darauf hindeutet, dass ich doch '' statt NULL verwenden sollte, weil es besser ist, so habe ich auch kein problem damit. es würde sogar die programmierarbeit minimieren, da ich kein ISNULL() oder IF in der DB und kein isset() in php verwenden bräuchte.

[MelloPie]

Bei Feldern die null sein können, sollte man sich die Frage stellen, ob sie nicht in eine andere Tabelle quasi "wegnormalisiert" werden können.

@see Antwort goth

EDIT:

---

und die ifnull variante dann in den JOINS verwenden...

---

[Troublegum]

Wieso schlagt Ihr hier alle NULL vor?
Im MySQL Manual steht doch ausdrücklich:

Deklarieren Sie Spalten - falls möglich - als NOT NULL. Das macht alles schneller und Sie sparen ein Bit pro Spalte. Beachten Sie, dass, wenn Sie wirklich NULL in Ihrer Applikation benötigen, Sie dieses natürlich benutzen sollten. Vermeiden Sie nur, einfach alle Spalten vorgabemäßig auf NULL zu haben.

[Abraxax]

ok. dann sind wir uns alle einig, dass NULL das beste ist. davon war ich auch ausgegangen...

aber ....

wie würdet ihr dies am saubersten handeln? variante 1 oder 2?
im zuge der sauberen programmierung natürlich. (siehe auch: ErrorReporting: sauber oder sauberer?)



variante 1

$sql = "SELECT eMail FROM ....";
.
.
$email = (isset($zeile["eMail"])) ? $zeile["eMail"] : ""; 

variante 2

$sql = "SELECT IF(ISNULL(eMail),'',eMail) eMail FROM ....";
.
.
$email = $zeile["eMail"]; 

EDIT:

---

beide varianten funktionieren korrekt.

---

[goth]

Eindeutig NULL ... wenn überhaupt ... und es nicht weiter normalisiert werden kann ... da kann man so schön IFNULL() drauf anwenden ... !

[mrhappiness]

d'accord

[TobiaZ]

Spontan finde ich NULL schöner.