[Databases] Niet gebruikte FK's 0 of NULL?

[Michali]

We hebben hier een situatie waarin 2 tabellen gekoppeld zijn met 2 andere tabellen. Omdat er naast de FK's in de koppeltabel ook nog enkele andere velden zijn, gebruiken we nu 1 koppeltabel met 4 FK's. Bij ieder record worden 2 FK's niet gebruikt.

De vraag is nu of niet gebruikte FK's de waarde 0 of NULL te geven. Dit kan op 2 manieren bekeken worden:

1. NULL betekent dat de waarde onbekend is. Van de niet gebruikte FK's weet je dat ze leeg zijn. Ze krijgen daarom de waarde 0 (oftewel 'leeg').

2. Van de niet gebruikte FK's ontbreken de waardes, ze hebben geen waarde. Ze krijgen daarom de waarde NULL.

Wat lijkt jullie de beste optie en waarom?

[mkleinman]

Ik zou zelf de waarde NULL gebruiken, een 0 impliceert namelijk een waarde en, dus, een mogelijke koppeling met een andere tabel.

[mulder]

Ja ik zie NULL ook als 'Not set'

[Pathogen]

geen verwijzing = geen verwijzing
0 is een verwijzing naar iets wat niet bestaat, NULL is geen verwijzing

Waarom worden er bij ieder record 2 FK's niet gebruikt? Dat alleen al lijkt me wat inefficient?

[mkleinman]

Thrackan schreef op vrijdag 10 september 2010 @ 11:42:
geen verwijzing = geen verwijzing
0 is een verwijzing naar iets wat niet bestaat, NULL is geen verwijzing

Waarom worden er bij ieder record 2 FK's niet gebruikt? Dat alleen al lijkt me wat inefficient?

Die relaties heb ik wel eens vaker gezien. Een soort OF,OF relatie. OF de ene moet gevuld zijn OF de andere. Volgens mij was in Oracle Designer (ER/D Diagrammer ) de juiste benaming hiervoor een ARCH. Maar ik moet zeggen dat het voor mij even geleden is dat ik met zo'n constructie te maken heb gehad..

[RobIII]

Thrackan schreef op vrijdag 10 september 2010 @ 11:42:
Waarom worden er bij ieder record 2 FK's niet gebruikt? Dat alleen al lijkt me wat inefficient?

Waarom

Voor wat betreft de TS: Gewoon NULL gebruiken. Je zult anders in de refererende tabel een record met ID 0 moeten maken (id: 0, name: unknown, title: none -> dat soort flauwekul) wil je überhaupt je FK's kunnen gebruiken.

.oisyn schreef op vrijdag 10 september 2010 @ 11:46:
Bij een fatsoenlijke database kun je 0 niet eens gebruiken, of je moet dummy records met 0 als sleutel aan gaan maken in de gerefereerde tabellen.

Precies. Niet doen dus. Geen referentie = NULL. Een waarde als 0 of 999999 of whatever impliceert wél een referentie.

[ Voor 66% gewijzigd door RobIII op 10-09-2010 11:52 ]

[.oisyn]

Bij een fatsoenlijke database kun je 0 niet eens gebruiken, of je moet dummy records met 0 als sleutel aan gaan maken in de gerefereerde tabellen.

[Pathogen]

RobIII schreef op vrijdag 10 september 2010 @ 11:45:
[...]

Waarom

Gewoon een vermoeden dat het de moeite waard zou kunnen zijn er eens goed naar te kijken, meer niet.

[Wolfboy]

.oisyn schreef op vrijdag 10 september 2010 @ 11:46:
Bij een fatsoenlijke database kun je 0 niet eens gebruiken, of je moet dummy records met 0 als sleutel aan gaan maken in de gerefereerde tabellen.

Inderdaad.

Als je een foreign key constraint aanmaakt dan zal die 0 record ook moeten bestaan. Aangezien je dat (neem ik dan aan) niet wil, kan je dus beter NULL gebruiken.

[Michali]

.oisyn schreef op vrijdag 10 september 2010 @ 11:46:
Bij een fatsoenlijke database kun je 0 niet eens gebruiken, of je moet dummy records met 0 als sleutel aan gaan maken in de gerefereerde tabellen.

Dat is wel een goed punt. We gebruiken overigens idd. MySQL

[cariolive23]

0 is een waarde, NULL is het ontbreken van een bekende waarde. Dus hoe jij een waarde wilt opgeven die verwijst naar een record wat helemaal niet bestaat, geen idee, maar een FK is er juist om dit soort fouten te voorkomen.

Weet je heel erg zeker dat je een engine van MySQL gebruikt die foreign keys ondersteunt? Of gebruik je iets waarbij de foutmelding keurig onder het tapijt is geveegd en jij _denkt_ dat er een FK is maar die in werkelijkheid helemaal niet bestaat? Alleen innoDB is bruikbaar, let daar op.

En dummyrecords zijn voor dummies en dit is een bron van bugs.

[Michali]

Met FK bedoel ik het concept FK, dus een veld die verwijst naar de PK. Het wordt verder niet afgedwongen door de engine.

[RobIII]

Michali schreef op vrijdag 10 september 2010 @ 13:13:
Met FK bedoel ik het concept FK, dus een veld die verwijst naar de PK. Het wordt verder niet afgedwongen door de engine.

Mja, of je dat dan nog FK wil noemen valt te bediscussiëren

[cariolive23]

Noem het dan FFK: Fake Foreign Key

Wanneer jij wilt dat jouw database je voor de gek houdt, ga vooral zo door, maar waarom zou je dat in hemelsnaam doen? Je gebruikt een relationele database of je gebruikt geen relationele database. Maar een RDBMS met fake foreign keys, dat raakt echt kant noch wal. Misschien is een NoSQL-database dan een betere oplossing voor jou, zelfs die hebben een betere oplossing dan FFK's, het zijn gewoon "losse" documenten die niets met FK's te maken hebben.

Je begaat een grote blunder met FFK's.

[JaQ]

.oisyn schreef op vrijdag 10 september 2010 @ 11:46:
Bij een fatsoenlijke database kun je 0 niet eens gebruiken, of je moet dummy records met 0 als sleutel aan gaan maken in de gerefereerde tabellen.

Om nog maar even te zwijgen wat de gevolgen voor de optimizer zijn (wat ik een veel groter probleem vind).

[hellfighter87]

Misschien maar ff onderzoek doen naar MySQL en relaties. daarmee kan je leuke dingen doen die je sowieso een hoop werk uit handen nemen

En zoals hierboven al gezecht. als je je relaties op orde hebt zou je 0 niet eens in moeten kunnen vullen tenzij daar daadwerkelijk een waarde aanhangt en de tabel waar je naar verwijst.

NULL = not set = de beste oplossing in mijn ogen.

[ Voor 47% gewijzigd door hellfighter87 op 10-09-2010 13:53 ]

[Hydra]

cariolive23 schreef op vrijdag 10 september 2010 @ 13:00:
0 is een waarde, NULL is het ontbreken van een bekende waarde.

Dat. Er is wat mij betreft geen discussie over mogelijk zelfs. 0 gebruiken als "no value" is net zo 'sane' als -1, 1, 42, 12345 of 31337.