[MySQL] Variabel aantal checkboxen vertalen naar db design

[BarthezZ]

Dit is een probleempje waar ik al een aantal keer tegenaan ben gelopen en waarbij ik eigenlijk op zoek ben naar een "best practice" oplossing. Ik probeer de situatie even te schetsen aan de hand van een (hopelijk duidelijk) voorbeeld.

Men maakt bijvoorbeeld een nieuws systeem, zoals iets wat t.net heeft. Nieuws is in verschillende categorieën van de website en er moet de mogelijkheid zijn om nieuws zichtbaar te hebben in meerdere categorieën van de website. Nu zou je dit dus in de front end simpel kunnen selecteren met een aantal checkboxes van waar het wel en niet weergeven moet worden. Maar hoe wil je dit in de back-end en het database design afhandelen.


Ik heb een aantal mogelijkheden bedacht en ik vroeg mij af wat de aangeraade manier is en vooral Waarom.


[list=1]
• Koppeltabel met het newsid en de categorie.

Voordelen:
[list]
• Robuust
• Makkelijk mogelijk toevoegen extra categorieën
• Snel in samenwerking met indexen

Nadelen:
[list]
• "groot"
• Een extra tabel met losse informatie


• Boolean Categorie velden in news tabel.

Voordelen:
[list]
• Erg simpel toepasbaar
• Geen joins nodig bij ophalen

Nadelen:
[list]
• Flawed by design (tabel verandering noodzakelijk voor extra categorieën)
• ?? eerste weegt genoeg om het eigenlijk geen optie te laten zijn


• Één Categorie veld in news tabel met (bijv) serialzed boolean velden.

Voordelen:
[list]
• Een veld nodig in nieuws tabel, geen extra joins
• Makkelijk mogelijk extra categorieën toevoegen

Nadelen:

• Extra logica nodig om de juiste waardes te selecteren
• Mogelijk noodzakelijk "te veel" velden op te halen en daaruit de juiste te selecteren

[ Voor 0% gewijzigd door BarthezZ op 11-04-2008 22:23 . Reden: Kleine topi fixes ]

[Black Hawk]

Ik zou voor optie 1 gaan. Wat jij als nadeel ziet, namelijk dat je een losse tabel hebt vindt ik juist een voordeel. Je koppelt de info (hier: een nieuws-item) los van de te tonen locatie.

[Creepy]

Klinkt als dat je een standaard N:M relatie hebt en dus optie 1 wilt. "Groot" is geen nadeel net als dat 1 extra tabel ook geen nadeel is. Een extra tabel waarmee je beide tabellen koppelt is echt standaard normalisatie werk.

[BarthezZ]

Ok wat ik dus al dacht eigenlijk. Dus het komt vaker voor dat er in totaal een stuk of 15~20 koppeltabellen kunnen zijn over een gehele site?
Ik vond het zelf relatief zo'n rotzooi worden omdat er redelijk wat situaties zijn waar dit voorkomt.

[Hobbles]

15 tot 20 koppel tabellen zijn geen uitzondering wanneer het om een uitgebreid datamodel gaat hoor. Optie 1 is the way to go. Pas als je echt tegen performance problemen gaat aanlopen (wat niet snel gebeurt hiermee) zou je misschien een andere oplossing kunnen overwegen.

[Boss]

Als het aantal mogelijkheden beperkt is kan je er ook voor kiezen om de gegevens in een integer oid op te slaan. Door een integer binair te representeren (een serie van 8 enen en nullen) kan je 8 booleans kwijt in een integer veld.

Dan moet je alleen wel ergens goed vastleggen welke waarde waarmee overeenkomt.

[Kayshin]

Wat heet "groot" in dit geval? Zoals ik dit nu zie zul je niet zo heel erg snel aan de honderdduizenden of meer komen

Optie 1 all the way

[Swaptor]

@Boss: Helaas is jouw oplossing oof 'flawed by design', en echt lekker makkelijk beheersbaar is het ook niet. Probeer eens een extra bool toe te voegen

N:M-relaties altijd oplossen met een koppeltabel, normalisatie FTW!