[mysql] db ontwerp

[Verwijderd]

Ik heb een MySql database draaien die een aantal activiteiten voor me bijhoudt.

Het ontwerp ziet er ongeveer als volgt uit:

Tabel Activiteit
------------------
Id Int(10) autoincrement, primary key
Description mediumtext

Tabel Logboek
------------------
Id Int(10) autoincrement, primary key
Activiteit Int(10)
Starttijd Timestamp(14)
Stoptijd Timestamp(14)

Het is zo vrij eenvoudig om van 1 activiteit de duur uit te rekenen (in 1 query). Het probleem is echter dat er data kan ontstaan die inconstitent is.

Zo kan er bijvoorbeeld een activiteit van 12:00 tot 13:00 en een activiteit van 12:30 en 13:30 in de database staan. En dit kan niet omdat ik nog steeds niet kan multitasken

Mij is altijd voorgehouden dat een db ontwerp niet klopt als je inconstitente data kunt krijgen. Dus ben ik op zoek gegaan naar een ander ontwerp. Hierbij kwam ik tot de conclusie dat het onnodig is om de Stoptijd op te slaan. Een nieuwe starttijd is immers de stoptijd van de vorige.

Alleen dan lukt het me niet om een tijdsduur van een project te berekenen zonder gebruik te maken van extra queries.

De vraag is dus: Hoe kan ik mijn ontwerp zo aanpassen dat ik geen "foute" data in de db kan krijgen, maar wel de lengte van een activiteit kan uitrekenen.

Of kan ik bij mijn nieuwe ontwerp wel de lengte uitrekenen (in 1 query)?

[Uiligheid]

volgens dit ontwerp kan 1 activiteit ook meerder logboeken hebben, klopt dat dan wel? Is het niet andersom?

[whoami]

Je kan er natuurlijk ook voor zorgen dat er een check gebeurt als je een nieuwe activiteit toevoegd; je controleert dan iedere keer als je een nieuwe activiteit toevoegt dat er geen overlappingen zijn oid.

[kvdveer]

je kunt dit niet helemaal afdwingen. Je kunt echter wel voorkomen dat er een duur van 12:30 to 11:10 in je db komt, door niet een starttijd en een eindtijd op te slaan, maar een starttijd en een duur, waarbij duur unsigned is.

[drm]

delighteddennis: e.e.a.

Ik vindt dat 2^e ontwerp eerder slechter dan beter dan 't eerste, eigenlijk. Een ontwerp waarin data van het ene record in 1 tabel afhankelijk is van een ander record in diezelfde tabel is volgens mij gebaseerd op een verkeerd model...

[Verwijderd]

volgens dit ontwerp kan 1 activiteit ook meerder logboeken hebben, klopt dat dan wel? Is het niet andersom?

Volgens mij ben ik dat niet met je eens. Er staat toch geen verwijzing naar een logboek in de tabel Activiteit?

Je kan er natuurlijk ook voor zorgen dat er een check gebeurt als je een nieuwe activiteit toevoegd; je controleert dan iedere keer als je een nieuwe activiteit toevoegt dat er geen overlappingen zijn oid.

Inderdaad is het mogelijk om deze checks uit te voeren. Dis deel wat ik laat zien is echter onderdeel van een veel groter en complexer geheel. Alle extra controles en correcties kosten tijd waardoor het systeem trager wordt en de serverlast dus groter wordt. Om deze rede wil ik proberen om met zo min mogelijk controles en correcties toch een 99,9% betrouwbaar systeem te hebben.

je kunt dit niet helemaal afdwingen. Je kunt echter wel voorkomen dat er een duur van 12:30 to 11:10 in je db komt, door niet een starttijd en een eindtijd op te slaan, maar een starttijd en een duur, waarbij duur unsigned is.

Maar dan hou ik het probleem dat er projecten kunnen overlappen.

Ik vindt dat 2e ontwerp eerder slechter dan beter dan 't eerste, eigenlijk. Een ontwerp waarin data van het ene record in 1 tabel afhankelijk is van een ander record in diezelfde tabel is volgens mij gebaseerd op een verkeerd model...

Bedoel je hiermee dat je voor ontwerp 1, of voor een nog ander ontwerp zou gaan?

[drm]

Ik bedoel dat je niet bang moet zijn om constraints op je database te leggen. Hetzij door het DBMS zelf, hetzij door de software die de database aanstuurt. Het is onzin om te denken dat je ontwerp verkeerd is, als de database de mogelijkheid biedt dit soort dingen niet goed in te vullen. Het feit dat 2 activiteiten kunnen overlappen is geen inconsistentie in die zin, maar misschien verkeerde data in een opzich goede database.

En ik zou het liefst gaan voor de oplossing van kvdveer, nl. een tijdsduur kiezen ipv een start- en stoptijd.