hoeveel mailadressen en tel.nrs
>> Ik zou alleen 2 email's gebruiken als je daar van plan bent gebruik van te maken
Ik kan me voorstellen dat er mensen zijn die graag hun mail op 2 e-mailadressen willen ontvangen. Bijv. een privé-adres en een zakelijk adres. Vandaar zou het misschien handig kunnen zijn.
@Ger
>> of je kan met een default value afdwingen dat het niets altijd hetzelfde is.
Ik begrijp niet wat je hiermee bedoelt. Kun je dat uitleggen?
Als je een kolom met een NOT NULL constraint een default value geeft, dan krijgt hij deze value indien hij weggelaten wordt bij een INSERT.
Je kunt niet zomaar zeggen een leeg veld krijgt de waarde 0. In sommige gevallen zal dat prima werken, maar ik kan me ook situaties voorstellen waarin dat niet werkt.
Vanuit dat oogpunt lijkt NULL me wel makkelijk, omdat je dan overal dezelfde (NULL)value hebt, als het veld niet is ingevuld. En niet de ene keer 0 de andere keer false en de andere keer 'none' of 'empty'.
Snap je wat ik bedoel?
Op jouw manier krijg je veel sneller vervuiling, want een kolom kan NULL, 0 of '' zijn, is maar net hoe de programmeur er tegen aan kijkt.
Ik zou in het geval van een extra emailadres, eerder al de emailadressen in een aparte tabel opslaan.
Als je over een tijdje besluit dat er twee extra emailadressen opgegeven kunnen worden ....
Ger van Steenderen op 10/04/2014 16:55:52:
Waar eindigt voor jou dan het normaliseren?Ik zou in het geval van een extra emailadres, eerder al de emailadressen in een aparte tabel opslaan.
Als je over een tijdje besluit dat er twee extra emailadressen opgegeven kunnen worden ....
Als je over een tijdje besluit dat er twee extra emailadressen opgegeven kunnen worden ....
Niet cynisch bedoeld (en dus ook zo niet lezen), maar ik vraag me wel vaker af waar je dan de grens moet trekken.
Nederland telt bijvoorbeeld amper duizend plaatsnamen. Plaatsnamen passen in elk geval met gemak in een aparte tabel met een SMALLINT als primair sleutel. Toch wil iedereen altijd maar de plaatsnaam opslaan in een VARCHAR.
Waar houdt normaliseren op en begint over-normaliseren?
Ik beschouw normaliseren als een middel niet als een doel.
Je kan jouw voorbeeld van plaatsnamen nog verder door trekken naar postcode, daaruit kunnen zowel de straatnaam als de plaatsnaam afgeleid worden.
Voor een ledenadministratie zal je zomaar niet een postcodetabel aanschaffen c.q aanleggen, maar voor de Yellow Pages is dat een heel ander verhaal.
Zo denk ik er ook over, THX!
Ik snap hoe jij er tegenaan kijkt en ook waarom. Ik ben wel benieuwd hoe dat in de praktijk dan werkt.
Stel je hebt een website waar bedrijven informatie over zichzelf op kunnen zetten. Het bedrijf kan via een formulier een aantal vragen invullen. Stel nu, een vraag is hoeveel medewerkers er in dienst zijn en een bedrijf wil dit niet vermelden. Hoe geef je dat dan aan in de database?
Met -1, je geeft dan een default waarde die in de invoer niet voor kan komen.
Kom ik nog even terug op mijn eerdere opmerking. Dan krijg je dus in het ene geval -1, in het andere geval 'empty', weer ergens anders een lege string ''. Wat is daar dan het voordeel van? Hoe ik het nu zie lijkt het me juist lastiger omdat je telkens moet gaan terugzoeken wat ook alweer die waarde was. In het geval van null hoeft dat niet.
Een paar voorbeeldjes:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
SELECT IF('' IS NULL, 'true', 'false')
=> false
SELECT 10 + NULL
=> NULL
SELECT 10 + 0
=> 10
=> false
SELECT 10 + NULL
=> NULL
SELECT 10 + 0
=> 10
Met een NOTT NULL constraint en een default waarde voorkom je dit soort dingen.
Bij die 2 onderste voorbeelden had ik nog niet stil gestaan. Dat is inderdaad wel een goede.
Het eerste voorbeeld snap ik niet. Wat wil dit zeggen:
IF('' IS NULL, 'true', 'false')
en dan met name het stukje '' IS NULL ?
Dat was bedoeld om het verschil tussen een lege string en NULL aan te geven.
Ah oké.