mysql not null oder null

[rookie]

Hallo, ich frage mich immer wieder beim erstellen einer neuen Mysql tabelle, was diese Voreinstellung "not null" oder "null" bedeutet.

Früher gabs das ja nicht im phpmyadmin.

Welche Einstellung empfehlt ihr mir?
Ich habe zwar die Sache im Manual gelesen, verstehen tu ich sie nicht wirklich.

0 ist ja nicht gleich Null
genausowenig '' gleich Null ist.

Ich will doch nur in den meissten Fällen, dass ein leeres Feld in
einer Spalte auch leer sein soll, stattdessen steht das 'NULL'

Bitte kann das mal einer erklären für Dumme?

Habt Dank
rookie

[rookie]

Hallo, wenn ich schon mal dabei bin:

Ich nutze immer Kollation latin_1_german_ci, ohne die richtige bedeutung, dessen was ich tue zu begreifen. Klar ich weiss das
hängt mit den characters zusammen, aber russische Zeichen hatte ich
bisher noch nicht, könnte ich dann Probleme kriegen?

oder umgekehrt wenn ich auf utf-8 umstelle bekomme ich dann probleme mit meinen bisherigen Ausgaben aus der Mysql?

Bitte sagt jetzt nicht lies das und das und das mal durch.

Viele Sachen habe ich versucht zu lesen, aber wenn die Basics fehlen kapiert man es nicht. geht mir auch bestimmt nicht alleine so, nur
viele trauen sich nicht zu fragen, weil wenns läuft dann läufts halt.

Aber ich will es jetzt endlich mal wissen. Bitte.

rookie

[dedlfix]

echo $begrüßung;

Bitte sagt jetzt nicht lies das und das und das mal durch.

Und was ist an einer Forumsantwort anders? Musst du die nicht lesen und verstehen? Das Thema ist auch einfach zu umfangreich und es mit einer Forumsantwort erschlagen zu können.

Viele Sachen habe ich versucht zu lesen, aber wenn die Basics fehlen kapiert man es nicht.

Die Grundlagen, wie Computer mit Zeichen umgehen, findest du im SELFHTML-Kapitel Internationalisierung (die ersten drei).

"Kollation" sind Sortier- bzw. Vergleichsregeln, die besagen, welche Zeichen in welcher Reihenfolge zu stehen kommen. Die ist bei den verschiedenen Sprachen anders, und selbst innerhalb einer Sprache kann es mehrere Regeln geben.

Ich nutze immer Kollation latin_1_german_ci, ohne die richtige bedeutung, dessen was ich tue zu begreifen. Klar ich weiss das hängt mit den characters zusammen, aber russische Zeichen hatte ich bisher noch nicht, könnte ich dann Probleme kriegen?

Es gibt einfach keine russischen Zeichen in Latin1, du kannst sie damit nicht darstellen. Es gibt andere Zeichensätze, dir kyrillische Zeichen enthalten, doch die haben wiederum keine arabischen, chinesischen, japanischen Zeichen usw. usf. Unicode ist ein System, das praktisch alle Schriftzeichen der Welt aufnehmen kann. UTF-8 eine Zeichenkodierung, die den Unicode-Codepoints Bytewerte zuordnet, die in real existierenden Dateien verwendet werden können.

oder umgekehrt wenn ich auf utf-8 umstelle bekomme ich dann probleme mit meinen bisherigen Ausgaben aus der Mysql?

Das ist anzunehmen, wenn du Zeichen verwendest, die über ASCII (0-127) hinausgehen, und du dich nicht mit der Art und Weise beschäftigt hast, wie MySQL mit der Zeichensatz-Problematik umgeht.

Aber ich will es jetzt endlich mal wissen. Bitte.

Wenn du nach der Lektüre der Grundlagenkapitel und gegebenenfalls weiterer Literatur, beispielsweise Wikipedia und das MySQL-Handbuchkapitel Character Set Support, noch Fragen offen hast, die auch das hiesige Archiv nicht klärt, kannst du gern nochmal detailliert nachfragen.

echo "$verabschiedung $name";

[rookie]

Thx Dedlfix,

Es gibt einfach keine russischen Zeichen in Latin1, du kannst sie damit nicht darstellen. Es gibt andere Zeichensätze, dir kyrillische Zeichen enthalten, doch die haben wiederum keine arabischen, chinesischen, japanischen Zeichen usw. usf. Unicode ist ein System, das praktisch alle Schriftzeichen der Welt aufnehmen kann. UTF-8 eine Zeichenkodierung, die den Unicode-Codepoints Bytewerte zuordnet, die in real existierenden Dateien verwendet werden können.

Au Backe, habe das gerade mal probiert und sowas eingefügt:
предложения по ведению

Nach dem Speichern waren nur noch Fragezeichen.

Aber wenn ich dich richtig verstehe müsste doch mir der Codierung 'utf8_unicode_ci' alles in Butter sein oder?

Zumindest zeigt mir ein Test dann alles richtig an. Aber glauben tu ich das nicht so ganz, denn dann wären ja die unzähligen anderen codierungen überflüssig wenn 'utf8_unicode_ci' so ein UniversalAllHeilmittel wäre. Also wo ist der Haken?

thx
rookie

[dedlfix]

echo $begrüßung;

Nach dem Speichern waren nur noch Fragezeichen.
Aber wenn ich dich richtig verstehe müsste doch mir der Codierung 'utf8_unicode_ci' alles in Butter sein oder?

Ja, wenn du mit dem Server richtig kommunizierst. Es gibt 10 verschiedenartige Stellen, an denen Kodierungen im MySQL-Server eine Rolle spielen. Die wichtigsten sind die Werte der Felder und die Einstellung der aktuellen Client-Verbindung. Letztere ist so wichtig, dass sogar das wesentliche Statement dazu auf der Einstiegsseite des bereits verlinkten Handbuch-Kapitels steht.

Zumindest zeigt mir ein Test dann alles richtig an. Aber glauben tu ich das nicht so ganz, denn dann wären ja die unzähligen anderen codierungen überflüssig wenn 'utf8_unicode_ci' so ein UniversalAllHeilmittel wäre. Also wo ist der Haken?

Du musst nun überall UTF-8 *) sprechen, sonst gibt es Datenverlust.

*) bzw. eine der anderen Unicode-Kodierungen, aber UTF-8 ist sicher die praktikabelste.

echo "$verabschiedung $name";

[rookie]

Dedlfix,

... dass sogar das wesentliche Statement dazu auf der Einstiegsseite des bereits verlinkten Handbuch-Kapitels steht.

Alles sehr theorisiert wie leider alle Manuals dazu die ich kenne.
Wäre schön wenn sowas mal mit mehr Praxisbeispielen aufgefüllt wäre.

Du musst nun überall UTF-8 *) sprechen, sonst gibt es Datenverlust.

Sprechen? Wie meinst Du das? Kann ich nun nicht mehr einfach ein
Ü in einen Insert schreiben wenn ich den Umlaut meine, oder muss
ich nun die UTF-8 Variante nehmen? Das wäre in der Tat grausam, weil
viel zu ändern.

thx
rookie

[dedlfix]

echo $begrüßung;

Alles sehr theorisiert wie leider alle Manuals dazu die ich kenne.
Wäre schön wenn sowas mal mit mehr Praxisbeispielen aufgefüllt wäre.

Praxisbeispiele findest du im Forumsarchiv :-)

Du musst nun überall UTF-8 *) sprechen, sonst gibt es Datenverlust.
Sprechen? Wie meinst Du das?

Jedes der beteiligten Programme muss darüber informiert sein, dass die Daten, die es zum Verarbeiten bekommt, UTF-8-kodiert sind, und dass es UTF-8-kodierte Daten weiterreicht. Natürlich muss es dazu in der Lage sein, mit UTF-8 umgehen zu können. PHP beispielsweise kann es derzeit (Versionen kleiner 6) nur eingeschränkt.

Kann ich nun nicht mehr einfach ein Ü in einen Insert schreiben wenn ich den Umlaut meine, oder muss ich nun die UTF-8 Variante nehmen?

Ja und ja. Bisher hatte ein Ü den Bytewert, den es gemäß Latin1/ISO-8859-1/Win-1252 hatte. Nun muss es die Bytewerte bekommen, die es gemäß UTF-8 hat. Doch das macht normalerweise dein Editor für dich, wenn du ihm sagst, dass er bitteschön UTF-8 zu verwenden hat.

Das wäre in der Tat grausam, weil viel zu ändern.

Kann passieren, wenn man es nicht gleich richtig angeht :-) Doch was "richtig" ist, muss man wie so oft im Leben erst lernen, gegebenenfalls auch verlustreich.

echo "$verabschiedung $name";

[rookie]

Dedlfix,

Ja und ja. Bisher hatte ein Ü den Bytewert, den es gemäß Latin1/ISO-8859-1/Win-1252 hatte. Nun muss es die Bytewerte bekommen, die es gemäß UTF-8 hat. Doch das macht normalerweise dein Editor für dich, wenn du ihm sagst, dass er bitteschön UTF-8 zu verwenden hat.

Editor? Ein ganz normales PHP Script führt ein Mysql Insert Query aus, ohne browsereingabe oder sonstwas. Wenn in einem der values ein Umlaut steht, müsste ich da jetzt etwas ändern, weil es nun UTF-unicode beim mysql-feld ist?

thx
rookie

[dedlfix]

echo $begrüßung;

Editor? Ein ganz normales PHP Script führt ein Mysql Insert Query aus, ohne browsereingabe oder sonstwas. Wenn in einem der values ein Umlaut steht, müsste ich da jetzt etwas ändern, weil es nun UTF-unicode beim mysql-feld ist?

Du unterhältst dich mit Person X in Sprache Y. Person X soll nun Sprache Z sprechen. Musst du nun was ändern? Antwort: Ja, du musst ebenfalls auf Sprache Z umstellen, und diese möglicherweise zunächst erstmal lernen.

echo "$verabschiedung $name";

[rookie]

Dedlfix,

Editor? Ein ganz normales PHP Script führt ein Mysql Insert Query aus, ohne browsereingabe oder sonstwas. Wenn in einem der values ein Umlaut steht, müsste ich da jetzt etwas ändern, weil es nun UTF-unicode beim mysql-feld ist?

Du unterhältst dich mit Person X in Sprache Y. Person X soll nun Sprache Z sprechen. Musst du nun was ändern? Antwort: Ja, du musst ebenfalls auf Sprache Z umstellen, und diese möglicherweise zunächst erstmal lernen.

Auaaaaaaaaaaaaaaaaaaaaa, mist.

Jetzt kann ich Tonnen an Scripts umschreiben mit utf8_encode()
und natürlich die Ausgaben ebenso mit utf8_decode().

Bin ich danach (ca. 1/2 Jahr :-(  ) denn wenigstens auf der sicheren Seite und somit jeder Sprache und jedem exotischen Char gewappnet, oder ist die aufwendige prozedur nur vom temporären Erfolg gekrönt?

thx
rookie

[dedlfix]

echo $begrüßung;

Jetzt kann ich Tonnen an Scripts umschreiben mit utf8_encode() und natürlich die Ausgaben ebenso mit utf8_decode().

Genau das solltest du nicht tun, denn damit kodierst du nur ISO-8859-1 nach UTF-8 um und umgekehrt. Und was passiert, wenn du versuchst, die 70.936.234.112 theoretisch möglichen Werte mit 256 Werten darzustellen versuchst? Es geht nicht. Statt dessen solltest du auf der ganzen Linie UTF-8 fahren, von der Datenhaltung über die Verarbeitung bis hin zur Darstellung beim Client. Nicht zu vergessen: deine Werkzeuge, mit denen du die Programme schreibst.

Bin ich danach (ca. 1/2 Jahr :-(  ) denn wenigstens auf der sicheren Seite und somit jeder Sprache und jedem exotischen Char gewappnet, oder ist die aufwendige prozedur nur vom temporären Erfolg gekrönt?

Theoretisch bist du dann sicher. Unwägbarkeiten können sich beim Client ergeben, auf den du keinen Einfluss hast, der möglicherweise keine Schriftart installiert hat, die für die darzustellenden Zeichen Glyphen enthält. Doch das sollte nicht dein Problem sein. In den meisten Fällen dürfte jemand, der solche Zeichen sehen will, die dafür nötige Unterstützung auf seinem Rechner installiert haben.

echo "$verabschiedung $name";

[rookie]

Deldfix,

ich sehe schon, das ist mir im Moment nicht machbar. Denn wenn ich nicht utf8_encode() verwenden soll, weiss ich auch nicht weiter.

Aber mal was anderes, wie hat MySQL-Client-Version: 3.23.49
das eigentlich gehandhabt? Da gabs doch soetwas wie Kolllation gar nicht.

Sehe mir gerade eine alte DB an und selbst im topaktuellen
PHPmyadmin erscheint nirgendwo eine Sprachcharacterangabe.

thx
rookie

[Vinzenz Mai]

Hallo

Aber mal was anderes, wie hat MySQL-Client-Version: 3.23.49
das eigentlich gehandhabt? Da gabs doch soetwas wie Kolllation gar nicht.

Welche Serverversion ist im Einsatz? Das sagt Dir übrigens

SELECT VERSION()

Freundliche Grüße

Vinzenz

[dedlfix]

echo $begrüßung;

ich sehe schon, das ist mir im Moment nicht machbar. Denn wenn ich nicht utf8_encode() verwenden soll, weiss ich auch nicht weiter.

Wie ich sagte, du sollst generell auf UTF-8 umstellen, zumindest die Teile deiner Entwicklungsumgebung und deines Servers, die sich mit den Webseiten beschäftigen.

• Content-Type im Header mit passender charset-Angabe ausliefern.
• Content-Type-Meta-Element ebenso gestalten. Braucht man vor allem, wenn man die Seite lokal speichert und dann keinen HTTP-Header mehr hat.
• Quelltexte als UTF-8 speichern. Das ist nur dann unbedingt nötig, wenn darin Zeichen jenseits von ASCII vorkommen.
• (mindestens) Datenbankfelder unstellen
• Verbindung mit "SET NAMES utf8" umstellen, besser noch mysqli und mysqli_set_charset() verwenden.
• Beachten, dass PHP derzeit noch von 1 Zeichen == 1 Byte ausgeht und Stringoperationen UTF-8-Bytefolgen möglicherweise auftrennen.

Aber mal was anderes, wie hat MySQL-Client-Version: 3.23.49 das eigentlich gehandhabt? Da gabs doch soetwas wie Kolllation gar nicht.

Das ist die Client-API, der Teil in deinem PHP, der sich mit einem MySQL-Server unterhalten kann. Wenn keine aktuelleren API-Features (ab Version 4.1) verwendet werden, kann diese Version auch mit MySQL-Servern kleiner als 4.1 kommunizieren. Bytes werden einfach nur durchgereicht, die Kodierung ignoriert. Die Kollation (Sortierung) spielt beim Durchreichen sowieso keine Rolle.

Die Version eines bestimmten Servers bekommst du erst, wenn du dich mit diesem verbindest und ihn nach seiner Version befragst. Das kann die gleiche Version wie die Client-API sein, wenn beide aus den gleichen Quellen kompiliert wurden, muss aber nicht.

Sehe mir gerade eine alte DB an und selbst im topaktuellen PHPmyadmin erscheint nirgendwo eine Sprachcharacterangabe.

Alte MySQL-Server kennen nur eine Systemeinstellung für alles. Wenn es dich wirklich interessiert, lade dir aus dem MySQL-Archiv eine alte Version. Achte darauf, dass noch nicht das 4.1er Handbuch drin enthalten ist. Neuere 4.0er Versionen wurden bereits mit dem 4.1er Handbuch ausgeliefert.

echo "$verabschiedung $name";

[Sven Rautenberg]

Moin!

• Beachten, dass PHP derzeit noch von 1 Zeichen == 1 Byte ausgeht und Stringoperationen UTF-8-Bytefolgen möglicherweise auftrennen.

Die Multibyte-Stringfunktionen (mb_xxx()) funktionieren sehr gut. Und mit der Option der Überladung der klassischen Funktionen müßte man sogar seinen alten Code nicht mehr ändern.

Es ist also derzeit schon problemlos möglich, mit PHP Unicode-Stringverarbeitung zu realisieren.

- Sven Rautenberg

[dedlfix]

echo $begrüßung;

• Beachten, dass PHP derzeit noch von 1 Zeichen == 1 Byte ausgeht und Stringoperationen UTF-8-Bytefolgen möglicherweise auftrennen.
  Die Multibyte-Stringfunktionen (mb_xxx()) funktionieren sehr gut. Und mit der Option der Überladung der klassischen Funktionen müßte man sogar seinen alten Code nicht mehr ändern.

Gerüchten (bzw. Erfahrungsberichten anderer) zufolge ist die mb-Erweiterung aber deutlich langsamer als die klassischen String-Funktionen.

Es ist also derzeit schon problemlos möglich, mit PHP Unicode-Stringverarbeitung zu realisieren.

Mittlerweile hab ich auch den Link wiedergefunden, den ich schon in meinem gestrigen Posting erwähnen wollte: http://wiki.silverorange.com/UTF-8_Notes. Doch dieses Dokument gibt es nicht mehr. Ich fand nur eine Ausführung in der WayBack Machine: http://web.archive.org/web/20060518015123/http://wiki.silverorange.com/UTF-8_Notes. Dort gibt es eine Aufstellung über die UTF-8-Kompatibilität von PHP-Funktionen.

echo "$verabschiedung $name";

[Ilja]

yo,

Welche Einstellung empfehlt ihr mir?

der constraint NOT NULL ist für die spalten sinnvoll zu setzen, die immer einen Wert enhalten müssen. so besitzt jeder primary key zum beispiel automatisch diese eigenschaft, aber auch bei anderen spalten kann man sie explizit zuweisen, zum beispiel dass in einer tabelle kunden, der nachname immer einen wert enthalten muss also die NOT NULL eigenschaft besitzt, während das geburtsdatum ruhig auch mal leer sein kann.

wenn eine spalte nun die eigenschaft NOT NULL besitzt (in unserem beispiel der nachname) und es wird versucht, einen neuen Datensatz einzufügen oder so zu verändern, dass der Nachname NULL ist, dann wird der entsprechende Datensatz vom dbms abgelehnt, sprich nicht in die tabelle hinzugefügt, bzw. nicht verändert.

es liegt also an dir festtzutellen, welche spalten in einer tabelle müssen immmer einen wert enthalten und welche können auch leer, bzw. besser gesagt NULL sein. durch diesen constraint kannst du bestimmen, welche informationen immer einen wert enthalten müssen.

Ilja

[rookie]

Hallo Ilja

wenn eine spalte nun die eigenschaft NOT NULL besitzt (in unserem beispiel der nachname) und es wird versucht, einen neuen Datensatz einzufügen oder so zu verändern, dass der Nachname NULL ist, dann wird der entsprechende Datensatz vom dbms abgelehnt, sprich nicht in die tabelle hinzugefügt, bzw. nicht verändert.

da hätten wir ja genau die Preisfrage. Im Phpmyadmin ist der Vorgabewert ja 'NOT NULL'. Und den benutze ich auch meisstens.

Du sagst jetzt aber ein leerer Datensatz wird dann abgelehnt, stimmt aber nicht. Wahrscheinlich meinst du auch keinen leeren Datensatz, sondern NULL. Was ist denn dieses verflixte NULL und warum sollte ich jemals NULL einfügen wollen, wo kommt sowas vor? Wenn ein Wert bei mir nicht vorhanden ist, ist er eben '' also leer.

Du siehst ich verstehe es immer noch nicht.

thx
rookie

[Ilja]

yo,

Wenn ein Wert bei mir nicht vorhanden ist, ist er eben '' also leer.

'' ist nicht immer gleich NULL, du musst schon den Wert NULL explizit angeben, bzw. bei einer insert anweisung die spalten nicht mit angeben.

NULL ist verwirrend, weil es nicht bedeutet, dass der wert "leer" ist, vielmehr bedeutet es, es sind keine Aussagen über diesen Spalteninhalt möglich.

Ilja

[rookie]

Ilja,

'' ist nicht immer gleich NULL, du musst schon den Wert NULL explizit angeben, bzw. bei einer insert anweisung die spalten nicht mit angeben.

Ich habe jetzt mal zum Test eine Insert anweisung gemacht und dabei eine Spalte weggelassen. Nach deiner Beschreibung dürfte das doch nicht gehen, geht aber doch !?

NULL ist verwirrend, weil es nicht bedeutet, dass der wert "leer" ist, vielmehr bedeutet es, es sind keine Aussagen über diesen Spalteninhalt möglich.

Na ja es gibt da schon einen Unterschied. wenn ich frage nach
 select * from tbl where xy=''; klappt das nur, solange das Feld ein
"NOT NULL" Feld ist.

thx
rookie

[Rouven]

Hello,

Na ja es gibt da schon einen Unterschied. wenn ich frage nach
select * from tbl where xy=''; klappt das nur, solange das Feld ein
"NOT NULL" Feld ist.

ja - deswegen unterscheidet beispielsweise Microsoft Access auch zwischen Value required (NULL/NOT NULL) und allow zero length ('').
Zunächst mal: Es bleibt im Prinzip dir überlassen, wie du für dich einen nicht vorhandenen Eintrag kennzeichnen möchtest. Nach meinem Verständnis der relationalen Lehre ist das ganze etwa so gedacht:
Nehmen wir mal an, du hast eine Kundendatenbank mit einer Spalte Telefonnummer. Nun gibt es verschiedene Zustände:

1. du weißt nichts über die Telefonnummer
2. du weißt, dass der Kunde keine Telefonnummer hat
3. du weißt, welche Telefonnummer der Kunde hat.
   -> wir erkennen eine Art 3-wertiger Logik. Diese wird mit Hilfe von NULL/''/{wert} abgebildet.
   Beachte weiterhin, dass NULL ein reserviertes Wort der Datenbank ist. PHPMyAdmin zeigt dir als Inhalt zwar NULL an, andere Datenbanksysteme schreiben u.U. einfach gar nichts hin. Auf gar keinen Fall steht in dem Feld 'NULL' drin, das ist etwas völlig anderes als NULL. Ersteres ist eine Zeichenfolge von 4 Zeichen N-U-L-L, letzteres ist einfach nichts.
   Wie bekommst du einen NULL-Wert in die Tabelle? Wie Ilja schon sagte: Lasse die Spalte im INSERT-Statement weg, oder schreibe als Wert explizit NULL hin.

MfG
Rouven

[Ilja]

yo,

Ich habe jetzt mal zum Test eine Insert anweisung gemacht und dabei eine Spalte weggelassen. Nach deiner Beschreibung dürfte das doch nicht gehen, geht aber doch !?

es sei den, die spalte hat einen default wert....schreib am besten explizit NULL rein, dann sollte das dbms den datensatz bei dem NOT NULL contraint ablehnen.

Ilja

[King^Lully]

NULL ist verwirrend, weil es nicht bedeutet, dass der wert "leer" ist, vielmehr bedeutet es, es sind keine Aussagen über diesen Spalteninhalt möglich.

Aussagen über den Wert des Datenfelds sind schon möglich, NULL bedeutet Information nicht verfügbar bzw. nicht erfasst.

Wir haben - und das verwirrt viele Entwickler - auf einmal eine "dreiwertige Logik", ein Wert kann unbekannt sein oder als Wert einen String der Länge 0 haben oder eben einen String der Länge grösser 0 haben.

NULL wurde eingeführt, weil die Kodierung "Leerstring für Information nicht verfügbar bzw. nicht erfasst" als inkonsistent empfunden wurde bzw. inkonsistent ist.

Einige "Weise" empfehlen grunsätzlich auf nullability zu verzichten um die Entwickler nicht zu verwirren, Wir gehören nicht zu diesen "Weisen".

[Sven Rautenberg (off site)]

Moin,

Was ist denn dieses verflixte NULL und warum sollte ich jemals NULL einfügen wollen, wo kommt sowas vor? Wenn ein Wert bei mir nicht vorhanden ist, ist er eben '' also leer.

Angenommen, du mißt jeden Tag Temperatur und Luftfeuchte und trägst diese in eine DB ein.

Als Wertebereich nimmst du z.B. Integer.

Nach einigen Wochen des Messens fällt die Batterie in deinem Thermometer aus, und du kannst nicht mehr messen. Die Luftfeuchtigkeit kannst du aber noch ablesen.

Was schreibst du jetzt als Temperatur in die Datenbank? Die Zahl 0 ist falsch, weil es nicht 0 Grad warm war. Irgendeine andere Zahl funktioniert auch nicht, weil du dir damit die Ermittlung der Durchschnittstemperatur pro Monat (mit AVG()) zerstörst.

Antwort deshalb: Das Temperaturfeld kriegt NULL erlaubt, und die nicht messbare Temperatur trägst du mit NULL dort ein. NULL-Werte werden von der Datenbank besonders behandelt, so dass sie z.B. nicht im Durchschnitt einfließen.

Für Textfelder ist NULL dagegen ein eher sinnloser Wert, weil gegenüber dem Benutzer in der Oberfläche nur selten ein Unterschied gemacht wird zwischen "Textstring ist der Leerstring" und "Textstring ist nicht vorhanden". Man müßte ja (beispielsweise) jedem Textfeld noch eine Checkbox hinzufügen, die man anklicken muß, wenn der String NULL sein soll. Leerstrings funktionieren in der Regel perfekt.

- Sven Rautenberg

[rookie]

Sven,

Was schreibst du jetzt als Temperatur in die Datenbank? Die Zahl 0 ist falsch, weil es nicht 0 Grad warm war. Irgendeine andere Zahl funktioniert auch nicht, weil du dir damit die Ermittlung der Durchschnittstemperatur pro Monat (mit AVG()) zerstörst.

Antwort deshalb: Das Temperaturfeld kriegt NULL erlaubt, und die nicht messbare Temperatur trägst du mit NULL dort ein. NULL-Werte werden von der Datenbank besonders behandelt, so dass sie z.B. nicht im Durchschnitt einfließen.

Also Feld ist varchar(200) NOT NULL
Wenn ich die Temperatur nicht weiss schreibe ich '' als Value.

Und so steht es dann auch in PhpMyAddmin. Ohne Komplikation.

Wäre das Feld jetzt aber varchar(200) NULL, kommt bei so einem Eintrag NULL im PhpMyAdmin zu lesen.

Alle Antworten hier klingen so, als wenn '' also leer nicht gehen würde wenn das feld 'NOT NULL' hat, aber es geht. Was verstehe ich denn da falsch?

thx
rookie

[Rouven]

Hello,

Alle Antworten hier klingen so, als wenn '' also leer nicht gehen würde wenn das feld 'NOT NULL' hat, aber es geht. Was verstehe ich denn da falsch?

...den Unterschied zwischen '' und NULL. Wenn ein Feld NOT NULL deklariert ist, dann kann dort NULL nicht eingetragen werden ('' aber schon). Du bist gezwungen, bei einem INSERT INTO für die Spalte einen Wert anzugeben (mindestens '').
Ist das Feld als NULL definiert, kannst du einen Wert eintragen, einen leeren String eintragen, oder die Spalte vollkommen ignorieren (wodurch automatisch NULL eingetragen wird).

MfG
Rouven

[rookie]

Rouven,

Ist das Feld als NULL definiert, kannst du einen Wert eintragen, einen leeren String eintragen, oder die Spalte vollkommen ignorieren (wodurch automatisch NULL eingetragen wird).

Ja dann steht da in der Tat 'Null' im phpmyadmin. Aber ansonsten, NOT NULL Feld, steht eben nichts da drin, wenn ich die spalte ignoriere oder einen leeren String eintrage. Wofür soll also dieses
NULL gut sein.

Hat denn nicht mal einer von euch ein praktisches konkretes Beispiel, dass mir zeigen könnte wann und warum es wichtig sein kann ein feld auf 'NULL' anstatt 'NOT NULL' zu setzen?

thx
rookie

[Rouven]

Hello,

Hat denn nicht mal einer von euch ein praktisches konkretes Beispiel, dass mir zeigen könnte wann und warum es wichtig sein kann ein feld auf 'NULL' anstatt 'NOT NULL' zu setzen?

Sven: Thermometer kaputt
Rouven: Telefonnummer

lies es bitte nochmal und mach dir den Unterschied zwischen UNBEKANNT und BEKANNT, ABER LEER klar.

MfG
Rouven

[rookie]

Rouven,

Sven: Thermometer kaputt
Rouven: Telefonnummer

Svens Beispiel kann ich nicht nachvollziehen.

Bei deiner  Aussage:

1. du weißt nichts über die Telefonnummer
2. du weißt, dass der Kunde keine Telefonnummer hat
3. du weißt, welche Telefonnummer der Kunde hat.
   -> wir erkennen eine Art 3-wertiger Logik. Diese wird mit Hilfe von NULL/''/{wert} abgebildet.

irretiert mich: NULL/''/{wert}.

Hättest Du geschrieben /''/NULL/{wert}, hätte ich heureka geschrien, weil ich da einen Ansatz gesehen hätte, nämlich die absolute sicherheit, dass der Kunde keine Telefonnummer haben kann. Aber der Gedankengang scheint ja uch falsch zu sein.

Wann und warum wäre 'NULL' zu bevorzugen?

thx
rookie

[Rouven]

Hello,

Wann und warum wäre 'NULL' zu bevorzugen?

genau da liegt dein "Fehler": nicht 'NULL', sondern NULL. PHPMyAdmin gaukelt dir vor, da stünde ein Text 'NULL' in dem Feld - dem ist nicht so. In dem Feld steht einfach gar nichts. Nichts und wieder nichts. In der Datenbankwelt wird das als NULL bezeichnet. Dementsprechend darfst du heureka schreien, wenn du ansonsten mit meinem Beispiel einverstanden bist.

MfG
Rouven

[rookie]

Rouven,

Wann und warum wäre 'NULL' zu bevorzugen?
genau da liegt dein "Fehler": nicht 'NULL', sondern NULL. PHPMyAdmin gaukelt dir vor, da stünde ein Text 'NULL' in dem Feld - dem ist nicht so. In dem Feld steht einfach gar nichts. Nichts und wieder nichts. In der Datenbankwelt wird das als NULL bezeichnet. Dementsprechend darfst du heureka schreien, wenn du ansonsten mit meinem Beispiel einverstanden bist.

Ich nerve zwar bestimmt, aber ich komme nicht dahinter. Was soll ich denn in deinem Beispiel bei der Erstellung der Tabelle bei dem Feld angeben? NOT NULL oder NULL ?

Denn alle 3 Optionen können ja im Lauf der einzelnen Inserts zutreffen. Also bei einem weiss ich, dass er keine Nummer hat, beim nächsten kenne ich sie nicht, beim nächsten ist sie xxxx-xxxx.

thx
rookie

[Rouven]

Hello,

Denn alle 3 Optionen können ja im Lauf der einzelnen Inserts zutreffen. Also bei einem weiss ich, dass er keine Nummer hat, beim nächsten kenne ich sie nicht, beim nächsten ist sie xxxx-xxxx.

genau. Wenn du 3 Optionen brauchst, musst du das Feld als NULL deklarieren. Damit signalisierst du der Datenbank gegenüber "hey, pass auf, möglicherweise sage ich dir bei einigen Datensätzen keinen Wert dafür".
Möchtest du hingegen datenbankseitig dafür sorgen, dass entweder eine Telefonnummer eingetragen ist, oder zumindest mittels '' signalisiert wird, dass es keine gibt (sinngemäß: verdammt noch mal, stell dem Kunden die Frage und prügele eine Antwort aus ihm raus. Entweder er hat ein Telefon oder nicht), dann deklarierst du die Spalte als NOT NULL - die Datenbank verweigert dann die Angabe von NULL-Werten.

MfG
Rouven

[rookie]

Rouven,

Denn alle 3 Optionen können ja im Lauf der einzelnen Inserts zutreffen. Also bei einem weiss ich, dass er keine Nummer hat, beim nächsten kenne ich sie nicht, beim nächsten ist sie xxxx-xxxx.
genau. Wenn du 3 Optionen brauchst, musst du das Feld als NULL deklarieren. Damit signalisierst du der Datenbank gegenüber "hey, pass auf, möglicherweise sage ich dir bei einigen Datensätzen keinen Wert dafür".

Aber im Grunde braucht man doch nie die 3. Option oder?
Entweder 'Inhalt' oder 'kein Inhalt'.

Wie würdest Du das dem Telefonbuch zuordnen?

Möchtest du hingegen datenbankseitig dafür sorgen, dass entweder eine Telefonnummer eingetragen ist, oder zumindest mittels '' signalisiert wird, dass es keine gibt (sinngemäß: verdammt noch mal, stell dem Kunden die Frage und prügele eine Antwort aus ihm raus. Entweder er hat ein Telefon oder nicht), dann deklarierst du die Spalte als NOT NULL - die Datenbank verweigert dann die Angabe von NULL-Werten.

Netter Vergleich :-) Die Angabe von NULL Wert wird verweigert stattdessen steht eben das Feld leer da, was mich zur where bedingung "...where xyz=''"; führt und ordnungsgemäss ausgeführt wird.

thx
rookie

[Rouven]

Hello,

Aber im Grunde braucht man doch nie die 3. Option oder?
Entweder 'Inhalt' oder 'kein Inhalt'.

zurück zum Telefonbuch: wie unterscheidest du verlässlich, ob jemand keine Telefonnummer hat, oder ob du seine Telefonnummer nicht kennst?

MfG
Rouven

[rookie]

Rouven,

Aber im Grunde braucht man doch nie die 3. Option oder?
Entweder 'Inhalt' oder 'kein Inhalt'.
zurück zum Telefonbuch: wie unterscheidest du verlässlich, ob jemand keine Telefonnummer hat, oder ob du seine Telefonnummer nicht kennst?

dachte eigentlich, ich hätte mich heute morgen schon bedankt. Aber war wohl nur die Vorschau. Dann also nochmal:

Ich denke ich habs soweit kapiert. Dein letzter Satz macht Sinn.

Also wenn ich jetzt eine behördliche KFZ Seite machen wollte könnte ich durch den Null wert wissen, dass eine Person kein Auto hat,
während '' feststellt, dass ich es nicht weiss. Richtig so weit?

Warum setzt phpmyadmin eigentlich NOT NULL als Standard? Wird NULL doch eher selten benutzt?

Vielen Dank nochmals
rookie

[Rouven]

Hello,

Also wenn ich jetzt eine behördliche KFZ Seite machen wollte könnte ich durch den Null wert wissen, dass eine Person kein Auto hat,
während '' feststellt, dass ich es nicht weiss. Richtig so weit?

ähm - ne, anders rum. NULL ist ein Wert für "dieses Feld hat noch niemand beachtet". '' ist ein Wert für "dieses Feld hat jemand explizit auf einen leeren Eintrag gesetzt".

Warum setzt phpmyadmin eigentlich NOT NULL als Standard? Wird NULL doch eher selten benutzt?

vmtl. weil man ein Datenmodell immer so streng wie möglich modellieren sollte. NULL-Werte würde man dementsprechend nur für optionale Felder erlauben. Andererseits ist PHPMyAdmin nur eine Software unter vielen. Wenn du deine DDL-Befehle von Hand schreibst, sprich CREATE TABLE ... selbst ausführst, dann ist NULL die Standardeinstellung, während NOT NULL explizit mit angegeben werden muss.

MfG
Rouven

[rookie]

Rouven,

ähm - ne, anders rum. NULL ist ein Wert für "dieses Feld hat noch niemand beachtet". '' ist ein Wert für "dieses Feld hat jemand explizit auf einen leeren Eintrag gesetzt".

»»

Aha, prima da fällt mir doch direkt ein Nutzen ein. Kann also gezielt die NULL Einträge raussuchen um klarzustellen, dass diese noch zu bearbeiten sind während '' ja mindestens schon einmal bearbeitet wurde.

Warum setzt phpmyadmin eigentlich NOT NULL als Standard? Wird NULL doch eher selten benutzt?
...CREATE TABLE ... selbst ausführst, dann ist NULL die Standardeinstellung, während NOT NULL explizit mit angegeben werden muss.

Genau diese abweichende Standardeinstellung von phpmyadmin hat mich stutzig gemacht.

Nochmals Danke für Mühe und Ausdauer
rookie

ps. Du hättest nicht zufällig auch eine Lösung für mein anderes 'KOLLATION' Problem? ;-)

[Sven Rautenberg]

Moin!

Antwort deshalb: Das Temperaturfeld kriegt NULL erlaubt, und die nicht messbare Temperatur trägst du mit NULL dort ein. NULL-Werte werden von der Datenbank besonders behandelt, so dass sie z.B. nicht im Durchschnitt einfließen.

Also Feld ist varchar(200) NOT NULL
Wenn ich die Temperatur nicht weiss schreibe ich '' als Value.

Nein, das Datenbankfeld in MEINEM Beispiel ist eines vom Typ INTEGER, dort kannst du keinen Leerstring eintragen, alle Werte dort sind zwingend Zahlen. Also hast du außer durch NULL keine andere Möglichkeit, "keine Zahl" einzutragen.

Bei Textfeldern wie VARCHAR ist NULL dagegen eher ungewöhnlich, NOT NULL der Normalzustand. "Nichts" ist dort eben üblicherweise der Leerstring, der Wert NULL erfordert hingegen relativ hohen Sonderaufwand im Benutzerinterface.

Alle Antworten hier klingen so, als wenn '' also leer nicht gehen würde wenn das feld 'NOT NULL' hat, aber es geht. Was verstehe ich denn da falsch?

Das hat ja niemand behauptet.

- Sven Rautenberg

[King^Lully]

Für Textfelder ist NULL dagegen ein eher sinnloser Wert, weil gegenüber dem Benutzer in der Oberfläche nur selten ein Unterschied gemacht wird zwischen "Textstring ist der Leerstring" und "Textstring ist nicht vorhanden". Man müßte ja (beispielsweise) jedem Textfeld noch eine Checkbox hinzufügen, die man anklicken muß, wenn der String NULL sein soll. Leerstrings funktionieren in der Regel perfekt.

Dein Beispiel mit den Temperaturen ist OK, dasselbe gilt natürlich auch für Datumswerte oder Fremdschlüssel, allerdings hat auch bei character-Feldern NULL seine Berechtigung, auch wenn es z.B. bei der typischen Kommunikationsdatenerfassung für die erfassenden MAs oft das Problem gibt "Heisst NULL jetzt nicht erfasst (soll ich nacherfassen?) oder Information nicht verfügbar?".

Strenggenommen könnte es sogar verschiedene NULLs geben, aber solche Überlegungen dürften in die Klapse führen, also sollte man NULL vermutlich als "Nicht erfasst" verstehen. Sicher bin ich da aber nicht.