Database ontwerp keuze

[rickjehh]

Hallo medetweakers,

Ik ben bezig met een databaseontwerp voor een webapplicatie die ik ga maken met ASP.NET en C#. De database wordt een SQL Server 2005 database. Stel je even de volgende situatie voor: Een monteur gaat op bezoek bij een klant om een luchtverwarmer te repareren. Eenmaal aangekomen bij de klant moet de monteur een aantal zaken op een Service Rapport invullen: Klantgegevens, tijd van aankomst, tijd van vertrek, type luchtverwarmer/toestel, verbruikte materialen en gedane werkzaamheden. Nu zijn er de volgende dingen waar ik aan moet denken:

• Per Service Rapport dient de monteur maximaal 3 toestellen toe te kunnen voegen.
• Per toestel dient de monteur maximaal 3 gebruikte materialen en gedane werkzaamheden toe te kunnen voegen.
• Materialen, toestellen en werkzaamheden staan in een aparte entiteit voorgedefinieerd.

Ik heb op dit moment de entiteit Rapport met daarin klantgegevens, tijd van aankomst en tijd van vertrek. Nu is mijn vraag, hoe ga ik er in mijn databaseontwerp voor zorgen dat ik per toestel 3 verbruikte materialen en gedane werkzaamheden kan toevoegen?

Op dit moment heb ik daarvoor een entiteit RapportInformatie met daarin id, rapport_id, toestel, materiaal en werkzaamheid. Tevens heb ik een check constraint voor rapport_id gemaakt waarin staat dat rapport_id maximaal 3 keer voor mag komen in de entiteit RapportInformatie, dus dat probleem is opgelost. Echter weet ik niet hoe ik ervoor kan zorgen dat er per toestel meerdere materialen en werkzaamheden toegevoegd kunnen worden. Hoe zouden jullie dit probleem aanpakken?

[Hydra]

Niet. Dit soort beperkingen los je in je applicatie op. In een goed genormaliseerd model zal je een koppeltabel met 3 rows voor de materialen hebben, en dat soort limieten leg je m.i. vast in je applicatie.

Als je met een oplossing met kolommen als `materiaal1, materiaal2, materiaal3` komt, ga ik je slaan

[rickjehh]

Hydra schreef op woensdag 10 december 2008 @ 14:28:
Niet. Dit soort beperkingen los je in je applicatie op. In een goed genormaliseerd model zal je een koppeltabel met 3 rows voor de materialen hebben, en dat soort limieten leg je m.i. vast in je applicatie.

Als je met een oplossing met kolommen als `materiaal1, materiaal2, materiaal3` komt, ga ik je slaan

Nee dat was ook niet mijn bedoeling. Maar als ik het goed begrijp zou jij het oplossen door een extra tabel aan te maken die met een foreign key gekoppeld is aan het toestel van de tabel RapportInformatie?

[Hydra]

rickjehh schreef op woensdag 10 december 2008 @ 14:51:
Nee dat was ook niet mijn bedoeling. Maar als ik het goed begrijp zou jij het oplossen door een extra tabel aan te maken die met een foreign key gekoppeld is aan het toestel van de tabel RapportInformatie?

Ja, gewoon een koppeltabel. Welke items daar precies in moeten kun je m.i. prima bepalen. Gaat mij erom dat dergelijke aantallen niet door de DB zelf beperkt worden. Sowieso dienen beperkingen in de DB zelf alleen als garantie van de dataintegriteit. De applicatie zal dit altijd zelf ook nog moeten checken, zoveel mogelijk client-side.

[rickjehh]

Hydra schreef op woensdag 10 december 2008 @ 14:53:
Ja, gewoon een koppeltabel. Welke items daar precies in moeten kun je m.i. prima bepalen. Gaat mij erom dat dergelijke aantallen niet door de DB zelf beperkt worden. Sowieso dienen beperkingen in de DB zelf alleen als garantie van de dataintegriteit. De applicatie zal dit altijd zelf ook nog moeten checken, zoveel mogelijk client-side.

Dat klopt, het ging mij ook meer om hoe ik het in het ontwerp moest toepassen. Het beperken van het aantal toe te voegen records kan ik prima client-side regelen, dat gaat me wel lukken. Ik zat alleen met dat probleem in mijn maag hoe ik database technisch voor elkaar kon krijgen om per RapportInformatie rij een toestel te krijgen die zelf weer 3 materialen kan bevatten.

[pedorus]

Ik zou eens nagaan waar die maximaal 3 vandaan komt. Ik kan me goed voorstellen dat dat niet echt klopt met de werkelijkheid...

[Verwijderd]

Als dat gewoon in de opdracht gesteld wordt maakt dat toch niet uit en als je het, zoals Hydra voorsteld, opzet met behulp van koppeltabellen kun je later nog naar hartelust dingen toevoegen, zonder dat je je datamodel om hoeft te gooien.

[rickjehh]

pedorus schreef op woensdag 10 december 2008 @ 15:48:
Ik zou eens nagaan waar die maximaal 3 vandaan komt. Ik kan me goed voorstellen dat dat niet echt klopt met de werkelijkheid...

Zoals Sintax het al zegt, dat is mij gewoon opgedragen. Per toestel moeten er maximaal 3 materialen toegevoegd kunnen worden. Mocht dit niet genoeg zijn dan kan de monteur altijd in het veld "opmerkingen" nog toevoegen welke extra materialen hij verbruikt heeft. Ik heb het inmiddels opgelost met twee koppeltabellen, 1 voor de materialen en 1 voor de werkzaamheden. Deze twee tabellen hangen aan de tabel RapportInformatie.

[RobIII]

rickjehh schreef op donderdag 11 december 2008 @ 08:58:
Per toestel moeten er maximaal 3 materialen toegevoegd kunnen worden.

Ik zou dat nog eens héél goed onderzoeken; er zal wel door iemand zijn gezegd "mwo, meestal niet meer dan 3" en dat is vertaald naar "maximaal 3" in de specs. En dat terwijl die limitiatie die nu in de specs staat er voor no-reason is. De opdrachtgever denkt daarbij jou werk te sparen en dus goedkoper uit te zijn terwijl het je feitelijk alleen maar meer werk kost die 'max 3' beperking in te bouwen. Die fout zie je praktisch altijd.

rickjehh schreef op donderdag 11 december 2008 @ 08:58:
Mocht dit niet genoeg zijn dan kan de monteur altijd in het veld "opmerkingen" nog toevoegen welke extra materialen hij verbruikt heeft.

Dat is nou nét het laatste wat je wil; dat ze je applicatie linksom en rechtsom moeten gaan misbruiken om hun zaakjes geregeld te krijgen. En over 6 maanden mag jij een update gaan maken omdat het niet lekker werkt zoals ze willen en dan maar zien hoe je uit alle misbruikte veldjes de rommel terugconverteert. Nee, dit is een disaster waiting to happen

[ Voor 10% gewijzigd door RobIII op 11-12-2008 10:20 ]

[Verwijderd]

RobIII schreef op donderdag 11 december 2008 @ 10:19:
[...]

Ik zou dat nog eens héél goed onderzoeken; er zal wel door iemand zijn gezegd "mwo, meestal niet meer dan 3" en dat is vertaald naar "maximaal 3" in de specs. En dat terwijl die limitiatie die nu in de specs staat er voor no-reason is. De opdrachtgever denkt daarbij jou werk te sparen en dus goedkoper uit te zijn terwijl het je feitelijk alleen maar meer werk kost die 'max 3' beperking in te bouwen. Die fout zie je praktisch altijd.

Het hele probleem bestaat alleen maar als je met kolommen als `item_1`, `item_2` en `item_3` werkt. Door het netjes uit te normaliseren is er toch al helemaal geen sprake van deze problematiek, of zie ik dat nou verkeerd?

RobIII schreef op donderdag 11 december 2008 @ 10:19:


Dat is nou nét het laatste wat je wil; dat ze je applicatie linksom en rechtsom moeten gaan misbruiken om hun zaakjes geregeld te krijgen. En over 6 maanden mag jij een update gaan maken omdat het niet lekker werkt zoals ze willen en dan maar zien hoe je uit alle misbruikte veldjes de rommel terugconverteert. Nee, dit is een disaster waiting to happen

Inderdaad, zeer vervelend, dat is hier ook dagelijkse kost (database systeem met 25 jaar oude roots). Geen pretje, met SUBSTRINGs en dat soort dingen waarden uit een veld halen

[ Voor 30% gewijzigd door Verwijderd op 11-12-2008 11:54 ]

[rickjehh]

RobIII schreef op donderdag 11 december 2008 @ 10:19:
Ik zou dat nog eens héél goed onderzoeken; er zal wel door iemand zijn gezegd "mwo, meestal niet meer dan 3" en dat is vertaald naar "maximaal 3" in de specs. En dat terwijl die limitiatie die nu in de specs staat er voor no-reason is. De opdrachtgever denkt daarbij jou werk te sparen en dus goedkoper uit te zijn terwijl het je feitelijk alleen maar meer werk kost die 'max 3' beperking in te bouwen. Die fout zie je praktisch altijd.

Nee dat hoef ik niet te onderzoeken, hij wil gewoon per toestel drie materialen toevoegen en dat kan op de manier zoals ik het nu geregeld heb. Mocht het meer worden, dan kan ik die beperking zo weer verwijderen met de manier zoals ik het nu opgebouwd heb met die twee koppeltabellen. Mochten het er 5 worden, pas ik dat in de code ff aan en ik ben klaar.

Dat is nou nét het laatste wat je wil; dat ze je applicatie linksom en rechtsom moeten gaan misbruiken om hun zaakjes geregeld te krijgen. En over 6 maanden mag jij een update gaan maken omdat het niet lekker werkt zoals ze willen en dan maar zien hoe je uit alle misbruikte veldjes de rommel terugconverteert. Nee, dit is een disaster waiting to happen

Hier moet ik je wel enigszins gelijk geven. Maar zoals ik hierboven al heb gezegd, mocht het ooit voorkomen dat er meer materialen toegevoegd moeten worden is dat eenvoudig aan te passen. Ik hoef daarvoor echt mijn hele databasemodel niet op de schop te nemen omdat ik die koppeltabellen gemaakt heb. Het is dan een kwestie van even een kleine aanpassing in de code en het werkt.

[rickjehh]

Verwijderd schreef op donderdag 11 december 2008 @ 11:53:
Het hele probleem bestaat alleen maar als je met kolommen als `item_1`, `item_2` en `item_3` werkt. Door het netjes uit te normaliseren is er toch al helemaal geen sprake van deze problematiek, of zie ik dat nou verkeerd?

Klopt, van dit probleem heb ik nu geen last omdat ik het nu met twee extra tabellen heb opgebouwd. Nu kan je eigenlijk naar hartenlust zoveel materialen toevoegen als je zou willen, mocht dit nodig zijn.