SQL = und <> (Mysql)

[Enurian]

Was hat das Frontend damit zu tun, wie ich das im Backend speichere? Ist mir doch völlig egal was da im HTML hantiert wird, am Ende muss das Datalayer was übermittelt bekommen und das muss dann eben die Information "hat der User leer gelassen" sein. Model und ViewModel ist nicht dasselbe.
Dein Post hat überhaupt nichts mit meinem zu tun.
1:1-Relationen sind ja nicht das einzige, es gibt zig Beispiele wo nullable Spalten absolut sinnvoll sind.
"Ablagedatum" z.B.
Das krampfhaft zu umschiffen ist sicher kein Qualitätsmerkmal.

 

[ayngush]

Du hast doch mit deinen 10 Comboboxen angefangen?!
Und du hantierst die ganze Zeit bei deinen Ausführungen mit binärer Logik herum um eine ternäre Logik zu rechtfertigen. Merkste selber...

 

[RalphS]

NULL ist nicht "unbekannt" oder "weiß nicht".
Es bedeutet, dass der Wert nicht gesetzt ist und nichts anderes.

Maa... ich würde sagen, wir meinen dasselbe, drücken uns nur anders aus.

Wenn ich einen Datensatz anlege und ich kann einen Wert nicht kennen- wie zB erledigungsdatum- dann muss dieser NULL annehmen können.

Wenn ich ein Datum vergessen oder eine Zuordnung aufheben muss, dann kann ich nicht einfach einen arbiträren Wert nehmen. Dann brauch ich NULL.

Wenn ich einen Datensatz haben möchte und dieser erfordert daß ich zB ein Geburtsdatum angebe, und ich verlange NOT NULL per Design, dann kann ich den Datensatz nicht vor Bekanntwerden aller Attribute anlegen, ergo die Anwender tragen Platzhalter ein und mein Schema versagt in der Praxis.


Man muss halt nachdenken. Ja, wie @ayngush sagt wird die Welt von deppen regiert. Aber dann muss man da gegensteuern und darf nicht den kleinsten gemeinsamen Trottellevel annehmen. Sonst hat man am Ende servergespeicherte Exceltabellen.


Und ebenfalls ja, ich hab genug solcher Erfahrungen gesammelt wo “Ablage Papierkorb” die einzig mögliche Empfehlung war und wo dann irgendwas zusammengeflickt werden mußte weil nichts anderes in gegebener Zeit machbar war. Aber das muss die Ausnahme werden.
DBMS sind nun mal eigenes Sach und Fachgebiet.

 

[Enurian]

Du hast doch mit deinen 10 Comboboxen angefangen?!
Und du hantierst die ganze Zeit bei deinen Ausführungen mit binärer Logik herum um eine ternäre Logik zu rechtfertigen. Merkste selber...

Ich merke vor allem, dass du keinen Plan hast, wovon du redest.
Die Comboboxen können auf einer Webseite, einer Desktop App oder meinetwegen auch in einer Excel-Datei liegen. Es ist doch völlig uninteressant wie und wo das implementiert wird. Es ging darum, wie die Informationen logisch in der SQL-Datenbank abgelegt werden und da bist du mit irgendwelchem HTML-Gedöns ausgewichen. Fehlt das Verständnis oder gehen dir nur die Argumente aus?

 

[Oelepoeto]

Dann kommt man schnell zu dem Schluss, dass es so etwas wie "weiß nicht" wirklich nur in Ausnahmefällen gibt, denn meistens ist ein "weiß nicht" dann einfach kein Eintrag einer Entität und nicht ein NULL-fähiges Attribut.

Stimme ich dir jetzt nicht zu, bei große Datenbanksysteme ist es durchaus gerechtfertigt bzw. sogar notwendig viel mit Nullable Felder zu arbeiten, um unnötige Datenmengen zu vermeiden. NULL im Sinne von "Wert nicht gesetz" - so wie du es auch selber beschreibst - macht in der Hinsicht für mich mehr Sinn als irgendwelche Default-Werte oder Blanks. Aber es kommt immer auf die konkrete Anwendung an.

 

[ayngush]

Das macht, gerade in großen Systemen, überhaupt keinen Sinn, da man es u. a. nicht indizieren kann. Viel Spaß dann beim Abfragen, wenn man mal was mit solchen Attributen machen muss. Wenn es nur "Produkteigenschaften" sind, dann baut man das System anders auf und geht nicht in die "Breite" damit, sondern macht ne neue Entität "Produkteigenschaften" mit EigeschaftID und EigenschaftWert z.B.

Du kannst ja auch keine Constraints darauf aufbauen - NULL ist eben kein Wert, sondern ein Zustand. Es verstößt ja auch gegen das Prinzip einer relationalen Datenbank... Stichwort 3NF und so...

Aber genau so wie du das beschreibst sehen viele Datenbanken leider aus. Die Leute denken halt immer, dass eine Datenbank aussieht wie eine "Matrix" und bauen einfach nur große Exceltabellen.

 

[Oelepoeto]

Und diese Produkteigenschaften beinhalten dann Nullable-Felder. Versteh dein Problem damit nicht? Wieso soll ich ein Constraint auf ein Betragsfeld oder ähnlich setzen wollen? Gerade da spart man sich Speicherplatz wenn statt 0.00 einfach NULL steht.

Ergänzung: nirgends in mein Beitrag war übrigens die Rede von eine große Tabelle oder so, mir geht es nur um das Prinzip: Nullable-Felder in SQL Datenbanken haben ein Nutzen und man kann nicht pauschal sagen das sie "nur in Ausnahmefällen" verwendet werden sollten. Datenbank-Design ist mehr als nur Normalform anwenden, man muss sich schon auch Sachen wie z.B. Speichermengen anschauen.

 

[AW4]

Gerade da spart man sich Speicherplatz wenn statt 0.00 einfach NULL steht.

Das ist in der Regel nicht korrekt.
Tabellen werden von den meisten Datenbanken Blockweise angelegt und verwaltet, sodass jedes Feld in dieser Tabelle, das nicht explizit oder implizit durch den Felddatentyp (z.B. so ziemlich alle BLOB-Felder) fragmentiert gespeichert wird, Speicherplatz entsprechend seines Datentyps einnimmt.

Dieses Vorgehen ergibt sich aus der Natur der zeitoptimierten Datenverwaltung, bzw. dem zeitoptmierten Zugriff auf die Daten, gegenüber einer simplen Datei.
Würde eine Datenbank tatsächlich für NULL-Werte keinen Speicherplatz belegen, wäre es entweder sehr zeitintsiv, große Teile des Tabelleninhalts neu auf die Platte zu schreiben, nur weil sich das Alignment wegen einem nun gefüllten NULL-Feld verändert, oder es würde einerseit generellen den Speicherbedarf erhöhen und andererseits die Zugriffszeiten auf die Feldwerte negativ beeinflussen, wenn du alle Felder einer Tabelle einzeln fragmentiert in eigenen Speicherblöcken ablegst. (Der erhöhte Speicherplatzbedarf ergibt sich dabei dann daraus, dass es irgendwo einen Zeiger geben muss, der auf den Speicherplatz des Feldwerts zeigt.)

 

[Oelepoeto]

Also mein Verständnis nach (und ich gebe zu, so ganz tief bin ich in der Materie nicht drinnen) speichert z.B. MSSQL-Server die Filespages so, dass für Nullable Spalten eine Markierung ist, ob NULL oder NOT NULL, und wenn NOT NULL dann ebenfalls der Wert abgelegt wird. Vielleicht beschreibe ich es etwas krumm. In dem Fall wird natürlich ein Bit benötigt für NULL/NOT NULL, aber im Falle von NULL wird kein weiterer Speicherplatz für den Datentyp der eigentliche Spalte benötigt.

 

[AW4]

InnoDB, die standard Database Engine von mySQL und MariaDB, kann so konfiguriert werden (bzw. ist es standardmäßig schon), dass das was du beschreibst als standard gemacht wird. (InnoDB Row Formats; siehe Row Format "DYNAMIC", bzw. "COMPACT").
So wie man viele Features von Informix nach DB2 bluten hat sehen können, nachdem IBM Informix aufgekauft hat, gibts dieses InnoDB-Feature auch schon einige Zeit in Oracle-DB.

Bei SQL Server aber musst du Felder explizit als Sparse Column deklarieren, um dieses Verhalten zu erreichen, standard ist das jedoch nicht.

DB2 oder Informix wiederum kennen dieses Konzept ausschließlich über Datentyen variabler Länge (z.B. VARCHAR u.ä.).

 

[Dalek]

Würde eine Datenbank tatsächlich für NULL-Werte keinen Speicherplatz belegen, wäre es entweder sehr zeitintsiv, große Teile des Tabelleninhalts neu auf die Platte zu schreiben, nur weil sich das Alignment wegen einem nun gefüllten NULL-Feld verändert, oder es würde einerseit generellen den Speicherbedarf erhöhen und andererseits die Zugriffszeiten auf die Feldwerte negativ beeinflussen, wenn du alle Felder einer Tabelle einzeln fragmentiert in eigenen Speicherblöcken ablegst. (Der erhöhte Speicherplatzbedarf ergibt sich dabei dann daraus, dass es irgendwo einen Zeiger geben muss, der auf den Speicherplatz des Feldwerts zeigt.)

Postgres zum Beispiel hat ein NULL Bitmap, d.h es braucht 1 bit pro Column um zu speichern ob diese Column in der Row vorhanden ist oder nicht. Man spart damit also schon deutlich Platz wenn viele nullable Columns in der Tabelle sind und die meisten tatsächlich NULL.

Ist aber trotzdem kein Grund nur aus Platzgründen NULL zu verwenden, wenn die Daten wirklich so viele Lücken haben gibt es vermutlich auch ein besseres Schema dafür.

 

[Oelepoeto]

Bei SQL Server aber musst du Felder explizit als Sparse Column deklarieren, um dieses Verhalten zu erreichen, standard ist das jedoch nicht

Ah ja, so war das! Danke für die Erläuterungen, finde es ein interessantes Thema aber bin eben noch nicht wirklich Sattelfest 🙂

 

[mental.dIseASe]

Für mich macht eine Modellierung von optionalen Attributen mittels Null-Werten gedanklich mehr Sinn. Wir haben zum Beispiel eine Anwender-Entität mit 'nem optionalen E-Mail-Attribut. Wenn der Anwender für Second-Factor-Auth oder das Password-Reset-Feature eine angeben will, dann kommt die da rein und ansonsten ist sie null. Klar könnte man das auch mit zwei Tabellen PROPERTY und PROPERTY_VALUE abfrühstücken, aber das finde ich hier irgendwie unintuitiv. Für Anwendereinstellungen (Sprache und diverse) und die Einstellungen unserer Mandanten haben wir das wiederum genauso umgesetzt, weil es da einfach viel mehr solche Attribute/Einstellungen gibt, aber die sind auch anders (auch optisch) in der Anwendung aufgehängt.

Wenn es da keine direkten Vorgaben gibt und die Performance stimmt, sehe ich das als Geschmackssache. Ich als Wartungsmensch fände es zumindest doof, wenn die Alternative in unserer Anwendung überhandnähme.

Zum Anfang zurück: sowas offensichtlich Zweiwertiges wie ein Flag "storniert" nullable zu machen, ist natürlich relativ Banane. Da gibt's nur "ja" oder "nee", und wenn man später doch noch was anderes braucht, macht man das Enum-wertig.

 

[KingLz]

Zum Anfang zurück: sowas offensichtlich Zweiwertiges wie ein Flag "storniert" nullable zu machen, ist natürlich relativ Banane. Da gibt's nur "ja" oder "nee", und wenn man später doch noch was anderes braucht, macht man das Enum-wertig.

Die Aussage ist viel zu einfach, da wir die Geschäftslogik nicht kennen. Wenn ich das Schemata modellieren würde und in 1:100000 Fällen gibt es Gegenstände, die nicht storniert werden können/dürfen, dann würde ich z.B. keine extra Spalte anlegen wollen für diesen sehr seltenen Sonderfall, sondern null = "es gibt keinen Stornostatus, weil es kein Storno geben kann".

Und bevor hier einer um die Ecke kommt mit "aber aber X ist besser", das ist nur ein Beispiel warum es so sein könnte. Wir kennen das Schemata nicht und es gibt immer Gründe warum etwas nicht nach "best practice" gemacht werden kann. Oder das Schemata ist wirklich nicht gut, kann natürlich auch sein.
Im Zweifelsfall sollte jede Spalte einen NOT NULL Constraint haben und nur wenn man sich Gedanken darüber gemacht hat NULL zulassen.

Übrigens noch so als Einwurf: Egal was sich der Schemataersteller bei der nullbaren Spalte gedacht hat, wenn die Intention war "das ist was Besonderes, Anwender geb Acht!", dann hat er doch bei der regen Diskussion hier alles richtig gemacht. Wenn wir bloß die Doku hätten.

 

[ayngush]

Ich verstehe ja auch nicht, was daran so schwer zu akzeptieren ist, wenn ich schreibe "NULL nur in Ausnahmefällen", dann sind alle aufgeführten Beispiele bis hierhin solche Ausnahmen.
Wichtig ist, dass man sich Gedanken um sein Datenmodell und in der Folge um sein Datenbankschema macht. Dabei auch die allgemein anerkannten und seit Jahrzehnten bewährte Methoden wie die Abbildung der 3NF berücksichtigt. Die gibt es bei relationalen Datenbanken ja nicht zum Spaß...

Stimme ich dir jetzt nicht zu, bei große Datenbanksysteme ist es durchaus gerechtfertigt bzw. sogar notwendig viel mit Nullable Felder zu arbeiten, um unnötige Datenmengen zu vermeiden.

(und ich gebe zu, so ganz tief bin ich in der Materie nicht drinnen)

Jetzt mal ernsthaft. Wie kommst du dann dazu solch eine Aussage zu treffen, dass es gerade bei großen Datenbanken notwendig(sic) sei viel mit NULL zu arbeiten?

Grüße

Steffen
Certified IT Systems Manager
Oracle Certiefied Professional Database Administrator
Microsoft Certified Database Administrator (ja, ist alt... ich bin alt...)
15 Jahre Berufserfahrung als Softwareentwickler UND Datenbank /-admin /-designer
Tief in der Materie drinnen.

 

[Oelepoeto]

Wichtig ist, dass man sich Gedanken um sein Datenmodell und in der Folge um sein Datenbankschema macht

Darum geht es mir, hättest du das gleich gesagt dann würden deine 15 Jahre Erfahrung sich auch zeigen. Es bleibt für mich falsch zu sagen, dass NULL für Ausnahmefällen zu verwenden ist, um dann jetzt zu sagen, dass es dann wohl viele Ausnahmen gibt.

Jetzt mal ernsthaft. Wie kommst du dann dazu solch eine Aussage zu treffen, dass es gerade bei großen Datenbanken notwendig(sic) sei viel mit NULL zu arbeiten?

Mea culpa, scheinbar nicht genug aufgepasst, darauf hat ja eh schon jemand hingewiesen. Ich habe es jedenfalls als Beispiel für eine legitime Verwendung von Nullable Spalten verwendet, nicht unbedingt als einziger oder wichtigster Grund dafür. Wie auch bereits von anderen erwähnt ist Nullability oftmals eine Entscheidung die auf Geschäftslogik basiert, und sollte daher nicht pauschal vermieden werden.

Grüße,
Niek
(nicht titelgeil)

 

[ayngush]

Ich bin auch nicht Titelgeil, ist Diskutiere jedoch nicht an Themen herum, von denen ich keine Ahnung habe und stelle mich dabei aber zunächst als Experte dar.

Es bleibt für mich falsch zu sagen, dass NULL für Ausnahmefällen zu verwenden ist, um dann jetzt zu sagen, dass es dann wohl viele Ausnahmen gibt.

Du widersprichst dir irgendwie selber in deinen eigenen Satz.
Weißt du was eine Ausnahme ist?
Nur in Ausnahmefällen und und jetzt(sic) sage ich erst, dass es wohl Ausnahmen gibt.
Siehe meinen Ersten Beitrag hier zum Thema, worin ich sagte, "in Ausnahmefällen ist NULL OK".

 

[Oelepoeto]

ich Diskutiere jedoch nicht an Themen herum, von denen ich keine Ahnung habe und stelle mich dabei aber zunächst als Experte dar

Ich hab schon Ahnung, nur nicht genug scheinbar, was ich auch schon mehrmals zugegeben hab. Als Experte hab ich mich nie bezeichnet, und mein Beispiel war vielleicht irreführend. Meine Intention war auch nicht dich persönlich zu widersprechen, aber deine Aussagen klingen mir zu pauschal.

Du widersprichst dir irgendwie selber in deinen eigenen Satz.

Sehe ich nicht so, wenn es laut deiner Logik in 10 Fällen 5 Ausnahmen gibt (/geben kann), sind das für mich keine Ausnahmen sondern einfach Anwendungsfälle.

Jedenfalls möchte ich nicht mit dir streiten (und der verweis auf Titelgeil war wohl unnötig - sorry), sondern nur auf etwas hinweisen, was für mich so nicht passt, und vielleicht für Anfänger in DB-Modellierung verwirrend ist: das Nullable-Felder generell zu vermeiden sind. Im echten Leben wäre so eine Diskussion bestimmt angenehmer verlaufen als jetzt Online.

 

[ayngush]

Wo haben ich etwas von "50% Ausnahmen" erzählt?
Transferiere doch bitte die Definition einer Ausnahme im Kontext eines Regelwerkes auf Datenbankdesign.
Ausnahmen sind Abweichungen von einer Regel. Eine Regel kann man pauschal beschreiben, weil sie nun mal Pauschal ist, sonst wäre es ja keine Regel. Und eine der Regeln eines guten Datenbankschemas für relationale Datenbanken gemäß der dritten Normalform, die immer anzustreben ist, ist, dass Attribute nur von sich selbst und seinen Schlüsselelement abhängig sind.
Wendet man das an, kann es keine Stornos mit NULL geben - aber auch keine Tabellen mit 50 Attributen die auch NULL stehen können, denn dann sind sie nicht mehr nur von seinen Schlüsselelement abhängig.

Abgesehen davon baut man solche Datenbankschemen anders auf: Wie gesagt wären "Produkteingeschaften" eine eigene Entität. Das mag vom Denkmuster, welches oftmals in "Zeilen und Spalten" stattfindet zwar erst mal komisch aussehen aber aus Sicht einer Datenbank ist es besser. Und dann verschwinden auch die NULL-Attribute, denn wenn dann einfach nichts für eine Eigenschaft gesetzt ist, ist einfach kein Eintrag Tupel vorhanden. So ein Design spart übrigens am meisten Speicherplatz

Ein Storno um beim Ur-Thema zu bleiben hat zum Beispiel ja meistens noch weitere, eigene Eigenschaften und wäre demnach auch eine eigene Entität. Auch schon, damit man ein ordentliches System drum herum aufbauen kann. Stornos können ja auch ggf. zurückgenommen werden. Löscht man dann einfach "X"? Was ist mit Buchhaltung? Man löscht solche einträge nicht einfach, sondern bucht einen Korrektureintrag (Audit Trail). Und schon beträgt die Kardinalität von "Umsatz" und "Storno" 1:n. Und ein Storno kann dann positiv und negativ sein und hat ein Wirksamkeitsdatum und der Eintrag ein Systemdatum und vor allem auch einen Sachbearbeiter(!) und eine Erstattungshöhe (Teilstorno...) usw.

Tipp wie man am besten mit den Erstellen eines Datenbankschemas anfägt: Einfach mal das Vorhaben in natürlicher Sprache mit allen Details aufschreiben. Alle Pronomen raussuchen; das sind in der Regel schon mal die Entitäten, mit denen man es zu tun hat. Diese trägt man dann in sein ER-Diagramm ein und fängt an sein Datenbank zu modellieren.

 

[Enurian]

Das macht, gerade in großen Systemen, überhaupt keinen Sinn, da man es u. a. nicht indizieren kann. Viel Spaß dann beim Abfragen, wenn man mal was mit solchen Attributen machen muss

??
Klar kann ich einen Index auf nullable Spalten setzen. Die NULLs sind sogar im Index und IS NULL / IS NOT NULL wird entsprechend (je nach Inhalt) beschleunigt. Mit SQL Server kann man die NULLs auch aus dem Index rausfiltern lassen.

Wenn es nur "Produkteigenschaften" sind, dann baut man das System anders auf und geht nicht in die "Breite" damit, sondern macht ne neue Entität "Produkteigenschaften" mit EigeschaftID und EigenschaftWert z.B.

Das ist dein Tipp? Wirklich? Die Werte sind dann alles Strings oder was? Oder ForeignKeys, die aber keine echten ForeignKeys (mit Constraint) sein können, weil ja alle möglichen Eigenschaften in der Tabelle stehen? Du willst ja schließlich nicht die Normalisierung verletzen und überall Redundanzen anlegen, hoffe ich. Vor allem da du gerade "große Datenbanken" und "denk mal an die Abfragen" angesprochen hast. DAS ist eine Ausnahme, nämlich für Fälle in denen die "Eigenschaften" sehr dynamisch sein müssen. Wenn eine Entität nach Normalisierung hunderte Eigenschaften hat, ist das ebenfalls eher eine Ausnahme als was du hier allen als Ausnahmen weiß machen willst. Dann bricht man sie aber einfach in mehrere Tabellen auf.
Bevor man so einen Quatsch ohne Notwendigkeit macht, lieber X einzelne Tabellen anlegen.

Du kannst ja auch keine Constraints darauf aufbauen - NULL ist eben kein Wert, sondern ein Zustand. Es verstößt ja auch gegen das Prinzip einer relationalen Datenbank... Stichwort 3NF und so...

Welche denn nicht?
Foreign Key? Kein Problem.
Index? Kein Problem.
Unique? Auch das geht, beim SQL Server muss man das nur glaube ich im Constraint filtern.
Check? Funktioniert.
Also was genau geht nicht, das nicht prinzipbedingt NULLs unsinnig macht (PrimaryKey)?

Dass du ständig auf der formalen Normalisierung ("kein Wert" = "keine Relation") herumreitest, aber solche Alternativvorschläge sowie Falschaussagen machst, lassen deinen Vorwurf andere seien keine Experten etwas ironisch erscheinen. Die Eigenschaftstabelle ist jedenfalls der absolute Knaller. Keine Typsicherheit, keine Keys, einfach eine geniale Grundlage als Pauschalempfehlung.

Nur fürs Protokoll: NOT NULL da wo es hingehört, klar. Bin ich überhaupt nicht dagegen und hat seine Vorteile. Aber sich das Design zu vergurken, nur weil man meint nullable wäre die Ausgeburt der Hölle, ist doch mal äußerst fragwürdig.