logischerwijs is dit de soort relatie die ik nodig heb. Dus dan krijg ik in de tabel account:
account_settings_id
account_details_id
account_information_id
Vanuit account wil ik weten wat er bij hoort, maar ik zal nooit 'settings' opvragen en dan kijken welk account erbij hoort.
Het is eigenlijk best logisch, maar normaal werk ik niet zo.
Suggesties / Opmerkingen?
One to One wil meestal zeggen dat beide tabellen gekoppeld worden op de primary key.
Dus waarom account_settings een AI id moet hebben is mij geheel onduidelijk.
Je zou kunnen zeggen dat je een 1:1-relatie gebruikt als er niet altijd een volwaardige 1:1-relatie is. De redenen daarvoor kunnen ook buiten de data zelf liggen, en dan vaak in de techniek van de dataopslag of het gebruik van de data.
Stel, je hebt een winkel in kleding en schoenen voor het hele gezin. Eén van de maten die je wilt registreren, is de boordmaat van overhemden. Die wordt echter alleen gebruikt voor bepaalde typen herenoverhemden. Je kunt dan overwegen om de boordmaat niet ook voor alle kinderen en vrouwen vast te leggen, maar uitsluitend voor de heren die een overhemd kochten.
Technische redenen zijn er ook. Je kunt bijvoorbeeld het maandsalaris van personeel 1:1 onderbrengen in een aparte tabel vanwege de databaserechten, zodat alleen geselecteerde gebruikers (of het "domein" van hun specifieke applicaties) daartoe toegang hebben.
Verder is er nog de performance. Vooral als je BLOB- of TEXT-kolommen hebt die niet altijd gevuld zijn, kan een splitsing in twee tabellen met een 1:1-relatie een database sneller maken. Veelgebruikte data plaats je in een kleine tabel met (liefst) vaste kolomgrootten en zelden gebruikte data hang je daaraan in een tweede tabel.
> als er niet altijd een volwaardige 1:1-relatie is
Ik ben dan al snel geneigd te spreken over een 0:1-relatie... ;-)
Een ander argument om te splitsen kan bijvoorbeeld zijn dat je gebruik wilt maken van specifieke functionaliteit in een storage engine. Zo kun je bijvoorbeeld je data in principe opslaan in een InnoDB-tabel vanwege de mogelijkheid tot transacties of foreign keys. Wil je over bepaalde velden echter een geospatial index, dan kun je die onderbrengen in een MyISAM-tabel.
