[MySQL] declaratie NOT NULL/DEFAULT

[CaptBiele]

Ik heb hier een voorbeeld van een creatie van een tabel:

MySQL:

CREATE TABLE icompany (company_id MEDIUMINT UNSIGNED ZEROFILL AUTO_INCREMENT PRIMARY KEY,
company_name CHAR(60) NOT NULL,
company_street CHAR(60) NOT NULL,
company_city CHAR(24) NOT NULL,
company_postcode CHAR(10) NOT NULL,
company_phone CHAR(16) NOT NULL,
company_fax CHAR(16),
company_mobile CHAR(16),
company_email CHAR(100) NOT NULL);

Nu heb ik mijn script laten reviewen door een collega, en hij zei me dit:

# It is advised (also mentioned by the MySQL guys) to make ALL fields "NOT NULL".
# a. It makes everything faster and you save one bit per column
# b. It saves checking on "ISNULL" While retrieving data
# c. By having all data "NOT NULL", you can use receiving a "NULL" value before creating a record to indicate error in application
# d. Having all fields "NOT NULL" it is advised to initiate all fields with an "empty" value (= NOT NULL) before creating a record. This can be done automatically to set for all fields the 'default' value to "empty"

Maar nu weet ik niet of dit wel het beste is qua performance.

a: waarom scheelt dit een bit per column?
b: waarom is het checken op ISNULL zo erg? anders moet ik checken op een lege string oid? wat is het verschil?
c: het lijkt me erg gebruikersonvriendelijk om alles NOT NULL te maken. (niet iedereen heeft een fax bijvoorbeeld)
d: Je kan dit natuurlijk vermijden door een DEFAULT waarde in te stellen (zoals lege string of zo), maar het gebruik van DEFAULT en NOT NULL tegelijkertijd is toch overbodig? Als ik een DEFAULT waarde instel, kan het toch nooit NULL zijn

Ik heb het gevoel alsof ik iets heel simpels over het hoofd zie, maar dat zou ik dan graag willen horen

[whoami]

Wat is dat nu voor zever om alle fiels als 'NOT NULL' te declareren? Als een bepaald veld niet verplicht is om in te vullen, dan hoef je het ook niet als not null te definieren.

Een lege string <> NULL.

[cameodski]

Als het enigszins kan, is het inderdaad aan te raden om kolommen NOT NULL te maken.
Het is beter voor de performance en het voorkomt bugs. Als je bijvoorbeeld twee strings optelt waarvan er eentje NULL is, dan is je resultaat dus ook NULL en dat is meestal niet wat je wilt.
Het probleem is dat NULL gewoonweg één grote uitzondering is, waar je RDBMS steeds rekening mee moet houden.

[bigbeng]

Ik heb dat verhaaltje over die bit (is trouwens een hele byte zeggen ze) hier ook gevonden.

Dit is trouwens wel erg lowlevel tweaking. Dit wordt pas interessant als je echt performance issues begint te verwachten.

[whoami]

Mjah, ik denk toch niet dat deze issue het verschil in performantie zal maken hoor....

[CaptBiele]

offtopic:
ah, whoami is back in black en gooit de remmen los: hij gebruikt het woord zever!

Tnx voor je reply. Ik vond het ook al erg vaag... maar het commentaar komt toch wel van gasten die ervaring hebben op dit gebied
heb je verder nog commentaar op andere punten?

Zo heb ik bijvoorbeeld gelezen dat MySQL eigenlijk alle velden als DEFAULT behandeld, ook al is het niet opgegeven.... MySQL vult er zelf een NULL, 0 oid in...

[cameodski]

CaptBiele schreef op 04 mei 2004 @ 16:22:
Tnx voor je reply. Ik vond het ook al erg vaag... maar het commentaar komt toch wel van gasten die ervaring hebben op dit gebied

Jij vindt het vaag, maar als je er heel diep in zou duiken, zou je ontdekken, dat het helemaal zo vaag niet is.
NULL is een buitenbeentje die altijd overal in de weg zit, dus zoveel mogelijk vermijden.

Wat bijvoorbeeld een veel voorkomend performance probleem is, is dat er gezocht wordt in een kolom die null kan zijn en waar ook een index op ligt.
Doordat er ook gecontroleerd moet worden of er een null value is, wordt zomaar opeens de index niet meer gebruikt en weg is je performance.

[ Voor 25% gewijzigd door cameodski op 04-05-2004 16:33 ]

[whoami]

Mjah, in de weg zitten..... Daar ben ik het niet mee eens eigenlijk.

Als iets geen waarde heeft, is dat NULL en niet een lege string of een 0.

[cameodski]

whoami schreef op 04 mei 2004 @ 16:33:
Mjah, in de weg zitten..... Daar ben ik het niet mee eens eigenlijk.

Als iets geen waarde heeft, is dat NULL en niet een lege string of een 0.

En wat levert het jou voor voordelen op om ipv een lege string null te hebben?

[gorgi_19]

cameodski schreef op 04 mei 2004 @ 16:36:
[...]

En wat levert het jou voor voordelen op om ipv een lege string null te hebben?

Hangt van de applicatie af; een waarde is bijvoorbeeld nog niet eerder gedefinieerd?

[CaptBiele]

@cameodski: dus jij denkt dat ik het beste zoiets kan gebruiken als:

code:

company_name CHAR(60) DEFAULT ""

of iets in die richting? Ik zie veel verschillende gebruiken... zelfs DEFAULT NULL.

[whoami]

cameodski schreef op 04 mei 2004 @ 16:36:
[...]

En wat levert het jou voor voordelen op om ipv een lege string null te hebben?

Stel dat je een FK veld hebt dat niet hoeft verplicht ingevuld te zijn. Als je relatie referentiele integriteit afdwingt, dan moet je wel een NULL value in dat FK veld zetten.

[cameodski]

gorgi_19 schreef op 04 mei 2004 @ 16:38:
[...]

Hangt van de applicatie af; een waarde is bijvoorbeeld nog niet eerder gedefinieerd?

Maar wat is dan het voordeel om geen lege string te gebruiken? Overigens hebben de meeste programmeertalen ook weinig plezier van null values.

CaptBiele schreef op 04 mei 2004 @ 16:39:
@cameodski: dus jij denkt dat ik het beste zoiets kan gebruiken als:

code:

company_name CHAR(60) DEFAULT ""

of iets in die richting? Ik zie veel verschillende gebruiken... zelfs DEFAULT NULL.

Ja, maar misschien is het wel een idee om VARCHAR te gebruiken.

whoami schreef op 04 mei 2004 @ 16:44:
[...]


Stel dat je een FK veld hebt dat niet hoeft verplicht ingevuld te zijn. Als je relatie referentiele integriteit afdwingt, dan moet je wel een NULL value in dat FK veld zetten.

Gebruik jij dan string velden om relaties te leggen
In MSSQL voorkom ik probleem van optionele FK's door in de gerelateerde table een record met ID = 0 toe te voegen, zodat de FK niet meer NULL hoeft te zijn.
Daardoor kan ik vervolgens een INNER JOIN gebruiken, wat ook weer beter is voor de performance. Het enige nadeel is, dat ik af en toe in de user interface het record met ID = 0 eruit moet filteren.

[ Voor 34% gewijzigd door cameodski op 04-05-2004 16:47 ]

[whoami]

cameodski schreef op 04 mei 2004 @ 16:44:
[...]

Maar wat is dan het voordeel om geen lege string te gebruiken? Overigens hebben de meeste programmeertalen ook weinig plezier van null values.

Hoezo?

[Verwijderd]

cameodski schreef op 04 mei 2004 @ 16:44:
[...]

Gebruik jij dan string velden om relaties te leggen
In MSSQL voorkom ik probleem van optionele FK's door in de gerelateerde table een record met ID = 0 toe te voegen, zodat de FK niet meer NULL hoeft te zijn.
Daardoor kan ik vervolgens een INNER JOIN gebruiken, wat ook weer beter is voor de performance. Het enige nadeel is, dat ik af en toe in de user interface het record met ID = 0 eruit moet filteren.

Dit is wel een erg geforceerde manier om NULL values te vermijden. 1) wat is er mis met een relatie op een string of een code die uit CHARs bestaat? 2) Dus jij gaat extra records toevoegen die alleen nodig zijn om NULL values te vermijden en die je vervolgens ook nog in de user interface eruit moet filteren. 3) FK relaties werken prima als er keys zijn met een NULL value.

[Verwijderd]

NULL values zijn in sommige situaties erg nuttig en zelfs onvermijdelijk.

voorbeeld 1) Stel je wilt een bepaalde periode vastleggen met een begin en einddatum (b.v. mederwerker is in dient van... tot...). De begindatum is de datum van indiensttreding maar de einddatum is natuurlijk vaak nog onbekent. Wat vul je dan in voor de einddatum? Juist: NULL

voorbeeld 2) Een systeem met medische informatie per persoon (M/V), Bij een vrouw wordt o.a. bijgehouden hoeveel kinderen ze heeft gehad. Stel bij het invoeren van een nieuwe vrouwelijke patient is even niet bekent hoeveel kinderen zij heeft gehad. Wat vul je in? juist: NULL. Als je namelijk 0 (het cijder nul) zou invullen is het later niet meer mogelijk om onderscheid te maken tussen: Heeft deze vrouw 0 kinderen gehad of heb ik dit veld nog niet ingevuld omdat het nog niet bekent was.

edit:
typos

[ Voor 3% gewijzigd door Verwijderd op 04-05-2004 17:03 ]

[CaptBiele]

Verwijderd schreef op 04 mei 2004 @ 17:01:
NULL values zijn in sommige situaties erg nuttig en zelfs onvermijdelijk.

voorbeeld 1) Stel je wilt een bepaalde periode vastleggen met een begin en einddatum (b.v. mederwerker is in dient van... tot...). De begindatum is de datum van indiensttreding maar de einddatum is natuurlijk vaak nog onbekent. Wat vul je dan in voor de einddatum? Juist: NULL

voorbeeld 2) Een systeem met medische informatie per persoon (M/V), Bij een vrouw wordt o.a. bijgehouden hoeveel kinderen ze heeft gehad. Stel bij het invoeren van een nieuwe vrouwelijke patient is even niet bekent hoeveel kinderen zij heeft gehad. Wat vul je in? juist: NULL. Als je namelijk 0 (het cijder nul) zou invullen is het later niet meer mogelijk om onderscheid te maken tussen: Heeft deze vrouw 0 kinderen gehad of heb ik dit veld nog niet ingevuld omdat het nog niet bekent was.

edit:
typos

Je geeft nu specifieke voorbeelden. Hoe zit het met een simpel veld als een Fax nummer?

[Verwijderd]

CaptBiele schreef op 04 mei 2004 @ 17:04:
[...]

Je geeft nu specifieke voorbeelden. Hoe zit het met een simpel veld als een Fax nummer?

Dat ligt een beetje aan je applicatie maar voor zo'n eenvoudig veld zou ik zeggen, kies voor het gemak en maak het veld NOT NULL en geef een lege string als default waarde.

Mijn reactie was meer bedoelt om het nut van NULL values te benadrukken. Van alle bovenstaande replies kreeg ik een beetje de indruk dat NULL values alleen maar lastig worden gevonden.

[gorgi_19]

cameodski schreef op 04 mei 2004 @ 16:44:
[...]

Maar wat is dan het voordeel om geen lege string te gebruiken? Overigens hebben de meeste programmeertalen ook weinig plezier van null values.

Een voorbeeld?

Visual Basic .NET:

If recordset("location") Is System.DBNull.Value Then
     Me.txtProductName = LocalizedString("nolocation")

Else
     Me.txtProductName = recordset("location")
End if

Een beetje half pseudocode, maar geeft het wel aan. Een lege string kan een bewust ingevulde waarde zijn, die weergegeven moet worden. Een Null-waarde betekent dat deze niet bewust is ingegeven.

[CaptBiele]

Verwijderd schreef op 04 mei 2004 @ 17:14:
Dat ligt een beetje aan je applicatie maar voor zo'n eenvoudig veld zou ik zeggen, kies voor het gemak en maak het veld NOT NULL en geef een lege string als default waarde.

Ik heb het gevoel alsof ik nu iets heel noobish ga zeggen, maar ik moet het toch kwijt... wat heeft het voor zin om dat ding NOT NULL te declareren als je een DEFAULT waarde opgeeft? Dan kan dat veld toch nooooit NULL zijn?

[gorgi_19]

CaptBiele schreef op 04 mei 2004 @ 17:29:
[...]


Ik heb het gevoel alsof ik nu iets heel noobish ga zeggen, maar ik moet het toch kwijt... wat heeft het voor zin om dat ding NOT NULL te declareren als je een DEFAULT waarde opgeeft? Dan kan dat veld toch nooooit NULL zijn?

Dan hoef je hem niet te vullen (mag wel) met een Insert Statement en kan deze dus nooit een foutmelding opleveren.

[CaptBiele]

gorgi_19 schreef op 04 mei 2004 @ 17:33:
[...]

Dan hoef je hem niet te vullen (mag wel) met een Insert Statement en kan deze dus nooit een foutmelding opleveren.

[door in noob-mode]
maar door de declaratie van NOT NULL moet je nou juist wel dat veld invullen?!? Als ik die declaratie niet gebruik krijg ik toch helemaal geen foutmelding bij een INSERT statement.?!?
[einde noob-mode]

[cameodski]

Ik geloof dat het tijd wordt om weer eens te reageren

whoami schreef op 04 mei 2004 @ 16:45:
[...]

Hoezo?

Volgens mij weet je wel het een en ander van .NET, dus zal ik een .NET voorbeeld geven.
Stel je hebt een datum, die in de database NULL kan zijn. Hoe ga je dat in je applicatie invullen. In een DateTime type past geen NULL value. Kortom je hebt daar steeds een conversie slag nodig om met die NULL value om te gaan. Ik weet wel dat dat niet zo'n probleem is, maar er moet wel steeds rekening mee gehouden worden.

Verwijderd schreef op 04 mei 2004 @ 16:55:
[...]
Dit is wel een erg geforceerde manier om NULL values te vermijden. 1) wat is er mis met een relatie op een string of een code die uit CHARs bestaat? 2) Dus jij gaat extra records toevoegen die alleen nodig zijn om NULL values te vermijden en die je vervolgens ook nog in de user interface eruit moet filteren. 3) FK relaties werken prima als er keys zijn met een NULL value.

1) Als de string een beetje langer wordt, gaat je performance omlaag. Sowieso is het rekenen met getallen trouwens sneller. Verder hangt er veelal logica aan strings en kunnen deze string dus ook wijzigen en dan wordt het dus echt stukken trager.
2) In SQL Server heb je views waarin je alleen maar een simpele filter hoeft toe te voegen, dus zoveel moeite kost het niet.
3) Weer SQL Server. Stel ik heb de volgende tabellen:

code:

Main (MainID) en Related (RelatedID, MainID NULL)

In de tabel Related zitten wat records waar MainID niet is ingevuld, maar in de tabel Main zitten een aantal records die niet in Related voorkomen en ik voer dan de volgende query uit:

code:

select * from main where mainid not in (select mainid from related)

Dan krijg ik dus niets terug
Vervolgens voeg ik isnull toe:

code:

select * from main where mainid not in (select isnull (mainid, 0) from related)

En zowaar, nu krijg ik zomaar een stel records terug.

Hopelijk begrijp je waarom ik een grote hekel aan NULL values heb.

Verwijderd schreef op 04 mei 2004 @ 17:01:
NULL values zijn in sommige situaties erg nuttig en zelfs onvermijdelijk.

voorbeeld 1) Stel je wilt een bepaalde periode vastleggen met een begin en einddatum (b.v. mederwerker is in dient van... tot...). De begindatum is de datum van indiensttreding maar de einddatum is natuurlijk vaak nog onbekent. Wat vul je dan in voor de einddatum? Juist: NULL

voorbeeld 2) Een systeem met medische informatie per persoon (M/V), Bij een vrouw wordt o.a. bijgehouden hoeveel kinderen ze heeft gehad. Stel bij het invoeren van een nieuwe vrouwelijke patient is even niet bekent hoeveel kinderen zij heeft gehad. Wat vul je in? juist: NULL. Als je namelijk 0 (het cijder nul) zou invullen is het later niet meer mogelijk om onderscheid te maken tussen: Heeft deze vrouw 0 kinderen gehad of heb ik dit veld nog niet ingevuld omdat het nog niet bekent was.

edit:
typos

vb 1) En als je nu alle medewerkers wilt hebben die nog in dienst zijn, moet je dus extra controleren of die einddatum nu wel of niet null is.
Je zou als einddatum natuurlijk ook heel ver in de toekomst kunnen gaan zitten, maar mijn ervaring is idd dat bij datums een null value toch wel prettig is. Maar je moet wel heel erg goed opletten dat je bij queries niet de mist ingaat.
vb 2) Je kunt natuurlijk -1 gebruiken, maar in deze specifieke situatie is een null inderdaad wel handig?

gorgi_19 schreef op 04 mei 2004 @ 17:17:
[...]

Een voorbeeld?

Visual Basic .NET:

If recordset("location") Is System.DBNull.Value Then
     Me.txtProductName = LocalizedString("nolocation")

Else
     Me.txtProductName = recordset("location")
End if

Een beetje half pseudocode, maar geeft het wel aan. Een lege string kan een bewust ingevulde waarde zijn, die weergegeven moet worden. Een Null-waarde betekent dat deze niet bewust is ingegeven.

En als je dat nu vergeet te controleren? Crasht je app dan? Mijn ervaring is dat dat soort dingen erg gauw vergeten worden.
Maar vooral als je grote, complexe stored procedures/triggers/functions hebt, wordt het erg snel vergeten om rekening te houden met de null values.

CaptBiele schreef op 04 mei 2004 @ 17:29:
[...]
Ik heb het gevoel alsof ik nu iets heel noobish ga zeggen, maar ik moet het toch kwijt... wat heeft het voor zin om dat ding NOT NULL te declareren als je een DEFAULT waarde opgeeft? Dan kan dat veld toch nooooit NULL zijn?

Ik weet niet hoe dat in MySQL zit, maar kan dat eventueel ook met het datatype char te maken hebben?

[ Voor 6% gewijzigd door cameodski op 04-05-2004 17:40 ]

[CaptBiele]

cameodski: kan het code voorbeeld (Main/Related) wat jij gaf MSSQL specifiek zijn? Ik krijg het niet nagebootst in MySQL namelijk.... ik ga ff verder testen

[cameodski]

CaptBiele schreef op 04 mei 2004 @ 18:10:
cameodski: kan het code voorbeeld (Main/Related) wat jij gaf MSSQL specifiek zijn? Ik krijg het niet nagebootst in MySQL namelijk.... ik ga ff verder testen

Het zou kunnen.
Ik zit me alleen af te vragen of dit nu een bug is of dat het gewoon zo hoort. Lastig is het in ieder geval wel.

[CaptBiele]

maar op het moment dat je alles NOT NULL declareert eis je toch ook van de gebruiker dat deze alles invult?

offtopic:
ik ga pittuh... reageer morgen wel weer

[cameodski]

CaptBiele schreef op 04 mei 2004 @ 18:32:
maar op het moment dat je alles NOT NULL declareert eis je toch ook van de gebruiker dat deze alles invult?

Nee, dat hoef je niet perse door de gebruiker te laten doen. Je kunt door MySQL defaults laten invullen, maar dan moet je de niet gevulde kolommen, dus ook niet in je query hebben staan. Verder kun je het natuurlijk altijd in je applicatie doen.

En ik heb uiteraard niet gezegd dat je perse alles op NOT NULL moet zetten.
Je moet zo veel mogelijk op NOT NULL zetten en dan in het bijzonders de kolommen die je gebruikt om FK's te leggen, om te filteren en te groeperen.
Vaak hebben dergelijke kolommen indexen nodig, dus dat zou je eventueel als vuistregel kunnen gebruiken.

Als je overweegt om een kolom NULL of NOT NULL te maken, moet je eigenlijk precies andersom redeneren dan de meeste mensen doen. Een kolom is NOT NULL, tenzij je echt een goede reden hebt om het niet te doen.

[CaptBiele]

Ok. Ik ben wat wijzer geworden maar heb nog geen reden gezien om mijn tabel (zie 1e post) te wijzigen.

Dit staat in de MySQL docs van mijn versie 4.0.18

A DEFAULT value must be a constant; it cannot be a function or an expression. If no DEFAULT value is specified for a column, MySQL automatically assigns one, as follows. If the column may take NULL as a value, the default value is NULL. If the column is declared as NOT NULL, the default value depends on the column type:
For numeric types other than those declared with the AUTO_INCREMENT attribute, the default is 0. For an AUTO_INCREMENT column, the default value is the next value in the sequence.
For date and time types other than TIMESTAMP, the default is the appropriate zero value for the type. For the first TIMESTAMP column in a table, the default value is the current date and time. See section 11.2 Date and Time Types.
For string types other than ENUM, the default value is the empty string. For ENUM, the default is the first enumeration value.

Dus hiermee heeft zoiets als bij

code:

company_name CHAR(60) NOT NULL DEFAULT ''

het gebruik van DEFAULT geen toegevoegde waarde. Er kan geen NULL waarde worden ingevuld, en bij de rest word de DEFAULT waarde vervangen.
Bij INTEGERS geldt hetzelfde, bij ongeldige invoer wordt er een 0 ingevuld.

Nu ben ik alleen nog aan het twijfelen of ik nu een veld zoals een fax NOT NULL moet declareren..... het is nog een beetje grijs allemaal

[whoami]

cameodski schreef op 04 mei 2004 @ 16:44:
[...]
Gebruik jij dan string velden om relaties te leggen

Nope, ik gebruik zoveel mogelijk numerieke velden, maar het kan altijd voorkomen dat je een FK op een string veld hebt.

In MSSQL voorkom ik probleem van optionele FK's door in de gerelateerde table een record met ID = 0 toe te voegen, zodat de FK niet meer NULL hoeft te zijn.
Daardoor kan ik vervolgens een INNER JOIN gebruiken, wat ook weer beter is voor de performance. Het enige nadeel is, dat ik af en toe in de user interface het record met ID = 0 eruit moet filteren.

Hmmm, dat vind ik eerlijk gezegd ugly.

[whoami]

cameodski schreef op 04 mei 2004 @ 17:38:
Ik geloof dat het tijd wordt om weer eens te reageren

[...]

Volgens mij weet je wel het een en ander van .NET, dus zal ik een .NET voorbeeld geven.
Stel je hebt een datum, die in de database NULL kan zijn. Hoe ga je dat in je applicatie invullen. In een DateTime type past geen NULL value. Kortom je hebt daar steeds een conversie slag nodig om met die NULL value om te gaan. Ik weet wel dat dat niet zo'n probleem is, maar er moet wel steeds rekening mee gehouden worden.

Tja, hier heb je een vertaal slag nodig.

code:

if( dr["eendatum"] == DBNull.Value )
{
   theDate = DateTime.MaxValue;
}
else
{
   theDate = Convert.ToDateTime (dr["eendatum"];
}

Hier moet je dus een afspraak maken: DateTime.MaxValue (31/12/2999) == NULL id databank, maar als jij in je DB geen NULLs toelaat, dan moet je ook een dergelijke afspraak maken.
Ik vraag me dan zelfs af wat jij in 'eendatum' gaat opslaan, als deze leeg moet zijn.

[cameodski]

whoami schreef op 05 mei 2004 @ 08:23:
[...]
Hmmm, dat vind ik eerlijk gezegd ugly.

Perfect is het idd niet, maar om rare bugs en outer joins te voorkomen, doe je soms wat.

whoami schreef op 05 mei 2004 @ 08:30:
Tja, hier heb je een vertaal slag nodig.

code:

if( dr["eendatum"] == DBNull.Value )
{
   theDate = DateTime.MaxValue;
}
else
{
   theDate = Convert.ToDateTime (dr["eendatum"];
}

Hier moet je dus een afspraak maken: DateTime.MaxValue (31/12/2999) == NULL id databank, maar als jij in je DB geen NULLs toelaat, dan moet je ook een dergelijke afspraak maken.
Ik vraag me dan zelfs af wat jij in 'eendatum' gaat opslaan, als deze leeg moet zijn.

Je zou in de database idd dezelfde afspraak kunnen hanteren. Maar ik wilde alleen even een voorbeeldje geven om te laten zien dat null values in je applicatie ook niet erg handig zijn.
Verder worden datums heel vaak in filters gebruikt en levert een not null kolom gewoonweg een betere performance.

[ Voor 3% gewijzigd door cameodski op 05-05-2004 10:09 ]

[whoami]

cameodski schreef op 05 mei 2004 @ 10:09:
[...]

Perfect is het idd niet, maar om rare bugs en outer joins te voorkomen, doe je soms wat.

Outer joins zijn dan wel wat trager dan inner joins, maar slecht zijn ze niet.
Hoe ga jij in jouw voorbeeld bv (waar je een record maakt met PK 0 om aan de foreign-key constraint te voldoen) de records ophalen die enkel gerelateerde records hebben in de andere tabel?
Dan ga jij in je query nog een extra voorwaarde moeten opnemen in je WHERE.
Ik heb nog nooit gehad dat het gebruik van NULL value's bugs introduceerde.

en levert een not null kolom gewoonweg een betere performance.

Dat misschien wel, maar het verschil tussen een sloom en een performant systeem wordt niet op dit (detail) niveau gemaakt.

[GarBaGe]

CaptBiele schreef op 05 mei 2004 @ 07:42:
...Nu ben ik alleen nog aan het twijfelen of ik nu een veld zoals een fax NOT NULL moet declareren..... het is nog een beetje grijs allemaal

Jouw specifieke voorbeeld is vaak gekoppeld aan een applicatie met een simpele GUI met wat invoerveldjes voor een nieuw bedrijf oid....
Het geinige hiervan is, dat als je de inhoud van de invoerveldjes opvraagt om te bewaren in de DB, je in principe NOOIT een NULL kan krijgen, maar (indien niet ingevuld) een lege string... Dus je kan vrijwel al je velden NOT NULL maken...

BTW, de MySQL-docs zit vol met compromissen, want aan de ene kant zeggen ze dat je types moet nemen die zo dicht mogelijk liggen bij wat je nodig hebt (CHAR(10), TINYINT etc etc)... Aan de andere kant worden een hoop types "automatisch" opgeschaald in het geval van een Isam-table.
alle CHAR's worden automatisch geconverteerd naar een VARCHAR-veld
Als je een kolom NOT NULL specificeert, maar je geeft geen DEFAULT op, dan pakt ie er zelf eentje. etc etc

[CaptBiele]

GarBaGe schreef op 05 mei 2004 @ 10:27:
[...]

Jouw specifieke voorbeeld is vaak gekoppeld aan een applicatie met een simpele GUI met wat invoerveldjes voor een nieuw bedrijf oid....
Het geinige hiervan is, dat als je de inhoud van de invoerveldjes opvraagt om te bewaren in de DB, je in principe NOOIT een NULL kan krijgen, maar (indien niet ingevuld) een lege string... Dus je kan vrijwel al je velden NOT NULL maken...

Dat is inderdaad wel logisch. Misschien was dit het simpele ding wat ik over het hoofd zag

Maar dan denk ik dat ik alles NOT NULL declareer, en dan zonder DEFAULTS in te stellen. (ik gebruik geen andere waardes dan die MySQL hanteert).
Ik heb zo in ieder geval geen problemen met het checken van NULL waardes, alhoewel het gebruik zeker zinvol kan zijn. Alleen niet in mijn eenvoudige applicatie.

[CaptBiele]

Volgens mij heeft het gebruik van NOT NULL DEFAULT "" helemaal geen zin bij strings.
Ik kan me geen situatie bedenken waarbij de default waarde niet wordt overgenomen door de daadwerkelijke invoer.

Bij integers kan het wel nut hebben...