Relationele database structuur

[TheCrius]

Beste medetweakers,

op het moment ben ik bezig met een soort van analyse tool voor vergaderingen.
Een agenda bestaat uit verschillende onderwerpen en criteria. Deze wordt gehouden op bepaalde momenten in de week. Het zijn standaard overleggen waar verschillende punten worden besproken.
Hier zijn personen aanwezig met verschillende functies.
Wat ik graag wil, is een systeem dat output geeft: hoe een overleg is verlopen, wat een onderwerp heeft gescored, en wat verschillende criteria scores zijn. Mogelijk in de vorm van een grafiek, met een norm of een trendlijn. Resultaten wil ik graag uit de database halen met gemiddeldes per moment of sjabloon.
De volgende opzet heb ik gemaakt:

http://castilio.nl/screen1.PNG

Een moment hoort bij een sjabloon. Hier zal evt. nog een tussen worden gelegd. Vanuit een backend zou het mogelijk moeten worden om een nieuw sjabloon aan te maken met nieuwe of bestaande criteria en deze aan een moment te koppelen.
Ik ben benieuwd wat jullie mening hiervan is en of jullie hier nog tips en of opmerkingen over hebben.

Edit:

Een lijst kan er als volgt uit gaan zien:

Sjabloon: Vergadering verkoopafdeling (sjabloon)
Onderwerpen: Voorbereiding, uitvoering, rondvraag (onderwerp)
Vragen onder voorbereiding(criterium):
- de voorzitter opent de vergadering juist;
- etc.
vice versa.
Ieder sjabloon kan dus uniek zijn. Met onderwerpen en onderliggende criteria.

Momenten kunnen zijn per afdeling.
ID | Parent_id | Naam
1, 0, Zwijndrecht
2, 1, Verkoop
3, 1, Inkoop
4, 2, Verkoopploeg 1
5, 2, Verkoopploeg 2

[ Voor 29% gewijzigd door TheCrius op 05-10-2011 13:21 ]

[NMe]

Waarom die 1:1-relatie tussen OverallResultaten en Aanwezigen? Waarom bestaat die Aanwezigen-tabel überhaupt? Koppel gewoon direct een persoon.

Verder alleen een aantal algemene opmerkingen:

• Je tabelnamen zijn meervoudig. De (bij mijn weten) internationaal geaccepteerde standaard is een enkelvoudige naam.
• Je naming scheme is niet consistent. Je tabelnamen zijn camelcased maar je veldnamen zijn allemaal in onderkast en hebben underscores of in sommige gevallen zelfs spaties. Ik zou dat gelijktrekken.

[TheNephilim]

Inderdaad, probeer de naam-conventies van je tabellen etc gelijk te houden. Achteraf is het heel lastig als je wel weet hoe de tabel ongeveer heet, maar niet meerweet of je meervoud/enkelvoud gebruikt hebt of wel of niet underscore of camelcasing.

@ NME: Dat hoor ik vaker, waarom een 1:1 relatie naar die of deze tabel. Maar als je nou bijv. de tabel `user` hebt, dan kan daar zoveel informatie in moeten dat het misschien handig is om bijvoorbeeld settings of iets dergelijke op te slaan in de tabel `user_settings`. Dan houd je de `user` tabel overzichtelijk heb ik zo het idee. Of is dat geen goede practice?

[Janoz]

Dat je denkt dat er misschien teveel informatie in staat is nooit een valide reden om een 1op1 koppeling te introduceren. Een tabel hoort door een computer gelezen te worden. Het is dus onzin om deze te optimaliseren voor mensen (het overzichtelijk maken).

@TS

- Een database over vergaderingen, maar geen enkele tabel die "vergaderingen" heet. Dat is volgens mij wat die 'overall' tabel moet voorstellen toch?

- Waarom heeft een moment een parent? Dat haal ik niet uit je verhaal

- Waarom heb je momenten, maar zit er ook een datum in de overall

- Wat is de functie van Sjabloon

- Ik vind de koppelingen tussen Agenda_koppel, criteria, onderwerp en uitlsag erg vreemd. Zoals ik het nu zie zit daar een circulaire dependecy in. (uitlsg lijkt hetzelfde als Agenda_Koppel.

[ Voor 50% gewijzigd door Janoz op 05-10-2011 12:10 ]

[RobIII]

NMe schreef op woensdag 05 oktober 2011 @ 11:33:
Verder alleen een aantal algemene opmerkingen:

• Je tabelnamen zijn meervoudig. De (bij mijn weten) internationaal geaccepteerde standaard is een enkelvoudige naam.

Eensch _{wegens gewenning}, daar niet van, maar dat is weer eens een mooi gevalletje van zo'n 'religieuze discussie'. Er is namelijk voor beiden iets te zeggen. Veel ORM's (waaronder bijvoorbeeld EF4) zullen bij een Model-First of Code-First approach zelfs by default (maar uit te schakelen) aan pluralization (en singularisation by DB-First approach) doen (en ja, dat werkt best goed, en ja, dat is door een eigen Pluralization service te implementen ook in andere talen dan Engels te doen). Doordat zaken als ORM's en andere tooling dit soort dingen voor me gaan doen ben ik tegenwoordig steeds meer geneigd dat lekker zo te laten. Who cares. Deze "enkelvoud" regel was juist omdat veel ORM's dan een (betere) mapping konden maken. Maar ik heb 't altijd krom gevonden dat een tabel met klanten "customer" moest heten en niet "customers".

Beiden kampen hebben echter een punt; zie hier en hier en hier en hier en ... bijvoorbeeld argumenten van beiden kampen.

En leuke alternatieve kijk hierop is synonyms gebruiken waar mogelijk; al heb ik dat in de praktijk nog nooit gebruikt en ik vermoed (op gut feel) dat 't nog wel eens heel verwarrend kan gaan werken.

[ Voor 37% gewijzigd door RobIII op 05-10-2011 12:20 ]

[Janoz]

* Janoz is trouwens meer van het meervoud kamp. Er zitten immers meerdere items in zo'n tabel. 1 row uit zo'n tabel is vervolgens enkelvoud.

Maar verder helemaal niet bedoeld om ook hier die religieuze discussie te starten hoor

[mace]

Is er functioneel gezien verschil?

Ik bedoel, customer of customers, maar je kan net zogoed tbl_hoipipeloi01 doen en dan select * from tbl_hoipipeloi01 AS customer WHERE etc...

toch?

[TheCrius]

Bedankt voor de reactie jongens. Ik heb zojuist de benaming aangepast. Dit ziet er denk ik beter uit? http://castilio.nl/work2.PNG.

NMe schreef op woensdag 05 oktober 2011 @ 11:33:
Waarom die 1:1-relatie tussen OverallResultaten en Aanwezigen? Waarom bestaat die Aanwezigen-tabel überhaupt? Koppel gewoon direct een persoon.

1:1 was een foutje, scherp gezien. Het is zo dat een moment bestaat uit meerdere personen. Dan is het denk ik verplicht om een tussentabel te gebruiken?

mace schreef op woensdag 05 oktober 2011 @ 12:40:
Is er functioneel gezien verschil?

Ik bedoel, customer of customers, maar je kan net zogoed tbl_hoipipeloi01 doen en dan select * from tbl_hoipipeloi01 AS customer WHERE etc...

toch?

Volgens mij is er geen functioneel verschil. Maar ben het er mee eens dat het beter allemaal consistent kan zijn. Je vindt het later gemakkelijker terug.

- Een database over vergaderingen, maar geen enkele tabel die "vergaderingen" heet. Dat is volgens mij wat die 'overall' tabel moet voorstellen toch?

- Waarom heeft een moment een parent? Dat haal ik niet uit je verhaal

- Waarom heb je momenten, maar zit er ook een datum in de overall

- Wat is de functie van Sjabloon

- Ik vind de koppelingen tussen Agenda_koppel, criteria, onderwerp en uitlsag erg vreemd. Zoals ik het nu zie zit daar een circulaire dependecy in. (uitlsg lijkt hetzelfde als Agenda_Koppel.

Ik zal proberen het doel van de applicatie beter te omschrijven. De sjablonen zijn zeg maar de beoordelingslijsten voor de vergaderingen. Deze sjablonen kunnen als volgt worden gezien:

Sjabloon: Vergadering verkoopafdeling (sjabloon)
Onderwerpen: Voorbereiding, uitvoering, rondvraag (onderwerp)
Vragen onder voorbereiding(criterium):
- de voorzitter opent de vergadering juist;
- etc.
vice versa.
Ieder sjabloon kan dus uniek zijn. Met onderwerpen en onderliggende criteria.

Momenten kunnen zijn per afdeling.
ID | Parent_id | Naam
1, 0, Zwijndrecht
2, 1, Verkoop
3, 1, Inkoop
4, 2, Verkoopploeg 1
5, 2, Verkoopploeg 2
5, 1, Inkoopploeg 1

Een sjabloon hoort zeg bij een moment maar ook bij een resultaat. Misschien is het handiger om deze te koppelen aan een sjabloon? De datum in resultaat (nieuwe afbeelding) is de datum dat het resultaat is ingevoerd. Wat ik uiteindelijk graag uit het systeem wil trekken, is een lijst van resultaten (gemiddelden) van zowel onderwerpen als scores op criteria, voor bijvoorbeeld de verkoopafdeling op een gespecificeerde periode (per moment).

[ Voor 54% gewijzigd door TheCrius op 05-10-2011 13:28 ]

[NMe]

Bernardo schreef op woensdag 05 oktober 2011 @ 11:45:
@ NME: Dat hoor ik vaker, waarom een 1:1 relatie naar die of deze tabel. Maar als je nou bijv. de tabel `user` hebt, dan kan daar zoveel informatie in moeten dat het misschien handig is om bijvoorbeeld settings of iets dergelijke op te slaan in de tabel `user_settings`. Dan houd je de `user` tabel overzichtelijk heb ik zo het idee. Of is dat geen goede practice?

Janoz heeft hem al beantwoord, maar er zijn maar een paar situaties waarin een 1:1-relatie handig is. De duidelijkste is wanneer je een tabel hebt waarin je twee types "dingen" opslaat, bijvoorbeeld een personentabel die zowel klanten als werknemers bevat. Voor werknemers heb je meer informatie nodig dan voor klanten, en dan kan het zinnig zijn om voor werknemers de werknemer-only velden naar een aparte tabel te trekken om zo voor de meest voorkomende personen (klanten) niet voor elk record heel veel nullwaardes op te hoeven nemen.

[TheNephilim]

NMe schreef op woensdag 05 oktober 2011 @ 13:02:
[...]

Janoz heeft hem al beantwoord, maar er zijn maar een paar situaties waarin een 1:1-relatie handig is. De duidelijkste is wanneer je een tabel hebt waarin je twee types "dingen" opslaat, bijvoorbeeld een personentabel die zowel klanten als werknemers bevat. Voor werknemers heb je meer informatie nodig dan voor klanten, en dan kan het zinnig zijn om voor werknemers de werknemer-only velden naar een aparte tabel te trekken om zo voor de meest voorkomende personen (klanten) niet voor elk record heel veel nullwaardes op te hoeven nemen.

Oké dat is waar, de meeste situaties waarin ik het gedaan heb, hebben betrekking op informatie die niet altijd aanwezig is zoals het voorbeeld dat je noemt.

Op een project dat ik geschreven heb ik 1 `user` tabel met nog 44 andere `user_...` tabellen. Wat ik nodig heb op een bepaald punt join ik en de rest laat ik liggen. Om even wat voorbeelden te noemen; `user_avatar`, `user_console_settings`, `user_privacy_settings`, `user_credits`. Nou zitten er tussen die tabellen ook een boel 1:N relaties. Bijv `user_friends`, je kunt natuurlijk meerdere vrienden hebben.

Maar dat moet ik nog maar eens herzien dus als ik dit zo lees. Als ik het goed begrijp moet ik onderscheid gaan maken in data die altijd aanwezig is en data die soms aanwezig is.

[RobIII]

Bernardo schreef op woensdag 05 oktober 2011 @ 14:39:
Als ik het goed begrijp moet ik onderscheid gaan maken in data die altijd aanwezig is en data die soms aanwezig is.

Ik denk dat je je beter kunt gaan inlezen in normaliseren

[Janoz]

NMe schreef op woensdag 05 oktober 2011 @ 13:02:
[...]

Janoz heeft hem al beantwoord, maar er zijn maar een paar situaties waarin een 1:1-relatie handig is. De duidelijkste is wanneer je een tabel hebt waarin je twee types "dingen" opslaat, bijvoorbeeld een personentabel die zowel klanten als werknemers bevat. Voor werknemers heb je meer informatie nodig dan voor klanten, en dan kan het zinnig zijn om voor werknemers de werknemer-only velden naar een aparte tabel te trekken om zo voor de meest voorkomende personen (klanten) niet voor elk record heel veel nullwaardes op te hoeven nemen.

Maar in dat geval heb je ook niet een 1 op 1 relatie maar een 1 op 0..1 relatie.

[NMe]

Janoz schreef op woensdag 05 oktober 2011 @ 16:05:
[...]

Maar in dat geval heb je ook niet een 1 op 1 relatie maar een 1 op 0..1 relatie.

True.

[moozzuzz]

Bernardo schreef op woensdag 05 oktober 2011 @ 14:39:
Maar dat moet ik nog maar eens herzien dus als ik dit zo lees. Als ik het goed begrijp moet ik onderscheid gaan maken in data die altijd aanwezig is en data die soms aanwezig is.

Een join is afaik altijd duurder dan een "pure" select.

On topic: "momenten" blijken dus hiearchische structuren te zijn... * moozzuzz suggests renaming to "teams" or "hierarchy".

[TheCrius]

Hierarchy is inderdaad een goede benaming hiervoor, bedankt Moozzuzz. Zou het verstandig zijn om deze aan het resultaat te knopen en aan de het sjabloon? Zodat er zeg maar consistent gekozen kan worden voor een sjabloon die specifiek voor een moment aangemaakt is?

[NMe]

Hiërarchie is juist geen goede naam, want die naam zegt niks over wat voor data de tabel bevat, alleen dat het een set hiërarchische data is.

[RobIII]

NMe schreef op woensdag 05 oktober 2011 @ 17:48:
Hiërarchie is juist geen goede naam, want die naam zegt niks over wat voor data de tabel bevat, alleen dat het een set hiërarchische data is.

Seconded. Hiërarchie van WAT zou mijn eerste vraag zijn als ik dit zag. Véél te algemeen.

[Wolfboy]

Janoz schreef op woensdag 05 oktober 2011 @ 12:11:
* Janoz is trouwens meer van het meervoud kamp. Er zitten immers meerdere items in zo'n tabel. 1 row uit zo'n tabel is vervolgens enkelvoud.

Maar verder helemaal niet bedoeld om ook hier die religieuze discussie te starten hoor

Zolang het consistent is maakt het me persoonlijk weinig uit, maar mijn voorkeur gaat in principe uit naar enkelvoud omdat je bij het gebruik in principe 1 object hebt.

Om even een voorbeeld te geven van een stored procedure:

SQL:

CREATE FUNCTION get_user(user_id integer) RETURNS user AS $$
DECLARE
    some_user user;
BEGIN
    SELECT *
    INTO some_user
    FROM user
    WHERE id = user_id;
END;
$$ LANGUAGE plpgsql;

Geen geweldig voorbeeld, maar het laat wel zien dat een record (het type) altijd enkelvoud is. De tabel zelf bevat meerdere records, maar dat maakt een record niet opeens een meervoudig iets.

[RobIII]

SQL:

select sum(total) from invoices where ...
--v.s.
select sum(total) from invoice where ...

--en hier maakt 't al helemaal weinig uit:
select u.username, u.displayname, u.signature, ...
from `users` u
where ...
--v.s.
select u.username, u.displayname, u.signature, ...
from `user` u
where ...

Dan vind ik, persoonlijk, meervoud weer duidelijker. Maar goed, potato, potato, tomato, tomato. Ik hanteer atm. ook nog (zoals ik al zei, maar uit gewenning) enkelvoud. Maar ik ga wel naar meervoud 'overstappen' bij een volgend project. Either way: als 't, zoals je zegt, maar consistent is.

Wolfboy schreef op donderdag 06 oktober 2011 @ 00:55:
Geen geweldig voorbeeld, maar het laat wel zien dat een record (het type) altijd enkelvoud is. De tabel zelf bevat meerdere records, maar dat maakt een record niet opeens een meervoudig iets.

Nee, het maakt een record niet een meervoudig iets, maar een tabel (zeg: container) vol records is dat wel En hoe label jij je schoenendoos op zolder? Schoen? Of schoenen?
Daarbij werk je in SQL vaker met een set (tuple) dan met een enkel record; heel SQL is gebaseerd op tuples en tuple (relational) algebra / Sets.

[ Voor 94% gewijzigd door RobIII op 06-10-2011 01:10 ]

[TheCrius]

RobIII schreef op woensdag 05 oktober 2011 @ 17:52:
[...]

Seconded. Hiërarchie van WAT zou mijn eerste vraag zijn als ik dit zag. Véél te algemeen.

Prima, een iets specifieker, een hiërarchie van situaties waarop kan worden beoordeeld.
http://www.castilio.nl/work3.PNG heb het aangepast en ook het sjabloon gekoppeld aan een situatie. Elk moment zou zo theoretisch aan een situatie gehangen kunnen worden denk ik. Dus sjabloon Vergadering Leeuwarden met onderwerpen en onderliggende criteria zit vast aan de situatie Leeuwarden.

Hier nog een leuk verhaal over singular vs plural http://ronaldbradford.com...lar-or-plural-2008-09-02/.