Naamgeving koppeltabellen en bijbehorende objecten

[Hmail]

Note: Dit is een eindopdracht voor mijn opleiding, dus ik ben niet op zoek naar een kant en klaar antwoord, maar een richting die ik kan gebruiken voor de opzet van mijn applicatie.

Waar ik mee zit is het volgende:
In een project management tool die ik aan het ontwerpen ben moet de mogelijkheid zitten om een soort 'generieke formulieren' te maken. Een voorbeeld daarvan zou een formulier met klantgegevens kunnen zijn. Dat formulier kan dan (automatisch) gekoppeld worden aan een project. Als voor dat project klantgegevens nodig zijn kunnen deze in dat formulier ingevuld worden.
Er is dus een n-n relatie tussen het formulier en het project. Het meest logische lijkt me dan gebruik te maken van een koppeltabel. Maar hoe doe ik dat goed?

Mijn idee voor de database is nu als volgt:

code:

[formulier]
title (string)
automatic_assign (boolean)

[koppeling formulier-project] (dit moet een betere naam hebben, maar wat?)
FK naar formulier
FK naar project
changed_by (FK naar user)
date
version

[formulier veld]
FK naar formulier
type (enum('text', 'checkbox', 'radiobutton', 'etc'))
name (string)

[formulier veld waarde]
FK naar koppeling formulier-project
FK naar veld
value (string)

Ik ben al even bezig geweest met het tekenen van een ERD, en hoewel dit niet echt mijn expertise is zou dit deel van de ERD moeten overeenkomen met wat ik wil, wellicht dat dat e.e.a wat duidelijker maakt.


Mijn vraag heeft dus voornamelijk te maken met de naamgeving. Uiteraard wil ik, als ik de applicatie ga ontwikkelen gebruik maken van engelse naamgeving. En de tabel Formulier veld waarde kan gewoon FormFieldValue o.i.d gaan heten. Maar hoe geef ik duidelijk het verschil tussen een Formulier en de koppeling Formulier-Project aan?

Ik hoop dat jullie (ook op dit belachelijke uur) begrijpen wat ik bedoel. Anders geef ik graag toelichting. Alvast bedankt!

[BtM909]

Doe je het formulier aan een project of het project aan een formulier? ProjectForms dus

Er zijn (wijze) mensen die beweren dat je naamgeving voor tabellen plural en voor kolommen singular moet zijn

[ Voor 41% gewijzigd door BtM909 op 22-11-2012 23:43 ]

[Hmail]

Hoe zou je dat regelen in de code? Wat zouden dan de namen van de classes zijn? Ook ProjectForm? Of moet ik afstappen van het idee dat een database-tabel in principe gerelateerd is aan een class in de code?

De hele enkelvoud/meervoud issue is stamt daar ook van af..

[ Voor 4% gewijzigd door Hmail op 22-11-2012 23:52 ]

[Woy]

BtM909 schreef op donderdag 22 november 2012 @ 23:41:
Er zijn (wijze) mensen die beweren dat je naamgeving voor tabellen plural en voor kolommen singular moet zijn

Er zijn ook (wijze) mensen die beweren dat tabellen ook singular moeten zijn

[Hydra]

Hmail schreef op donderdag 22 november 2012 @ 23:52:
Hoe zou je dat regelen in de code? Wat zouden dan de namen van de classes zijn? Ook ProjectForm? Of moet ik afstappen van het idee dat een database-tabel in principe gerelateerd is aan een class in de code?

Dat sowieso.

De hele enkelvoud/meervoud issue is stamt daar ook van af..

Je moet in je code klasses hebben die logisch zijn en een logische uniforme naamgeving hebben. Deze hoeft absoluut niet overeen te komen met de tabelnamen als dat vanuit een code-cleanliness oogpunt geen zin heeft. In je code zal een project over het algemeen gewoon meerdere formulieren hebben (lijkt me), tenzij je vanuit een formulier om een of andere reden bij het project moet kunnen komen (lijkt mij persoonlijk wat vreemd maargoed).

Het koppelen van classes (je business layer) aan je datalaag gebeurt in je DAL (via een ORM als Hibernate bijvoorbeeld) en daar zit ook die vertaling naar je tabellen en kolommen. In je code zul je dan bijvoorbeeld in de Project class een getForms() (geeft een list terug) of getForm(String id) hebben.

Woy schreef op vrijdag 23 november 2012 @ 09:57:
Er zijn ook (wijze) mensen die beweren dat tabellen ook singular moeten zijn

Deze persoon vindt "user.id" logischer dan "users.id" omdat het een ID van een enkele user is.

[ Voor 11% gewijzigd door Hydra op 23-11-2012 09:59 ]

[telefoontoestel]

In mijn opleiding deden wij databases ontwerpen met het programma Casetalk. Ik moet zeggen dat het behoorlijk goed werkt, maar wel tijd intensief is. Kijk er eens naar zou ik zeggen.

Verder lijkt mij de naam ProjectFormulier een geldige naam voor je koppel tabel. En waarom heb je een directe relatie tussen de koppeltabel en het afgeleide veld formulier veld waarde.

De volgende diagram heb ik uit jouw info weten te halen. Ik ga er ook vanuit dat je meerdere een project meer formulieren mag hebben, maar een formulier maar aan een project gekoppeld kan zijn.

[ Voor 21% gewijzigd door telefoontoestel op 24-11-2012 00:07 ]

[Hmail]

Bedankt voor de tips!
Ik denk dat ik teveel heb vastgezeten aan het idee dat in principe objecten gelijk staan aan tabel rijen. Dus een Project heeft dezelfde properties als de kolommen van de tabel Projects. Voornamelijk bij de koppeling ProjectForm gaat dat dus de mist in, en ik zal dus moeten afstappen van dat idee. Dat betekent dus ook iets dieper nadenken over de DAL. Hydra, bedankt voor je tips op dat gebied, ik ga me daar iets beter over inlezen.

[BtM909]

Woy schreef op vrijdag 23 november 2012 @ 09:57:
[...]

Er zijn ook (wijze) mensen die beweren dat tabellen ook singular moeten zijn

Ik had gehoopt dat TS daardoor die kreten door Google ging gooien en erachter kwam dat het helemaal niet zo zwart wit is (oftewel de helft roept a en de andere helft b)

[Kwistnix]

Om over lower case vs. upper case en underscores vs. CamelCase nog maar te zwijgen.
Het consistent toepassen van een naamgevingsconventie is inderdaad veel belangrijker dan naamgevingsconventie zelf.

[Jory]

BtM909 schreef op donderdag 22 november 2012 @ 23:41:
Doe je het formulier aan een project of het project aan een formulier? ProjectForms dus

Maar 'ProjectForms' zegt enkel dat het projecten aan formulieren koppelt (of andersom) - het zegt niet wat die relatie betekend.
Hoewel het voor dit geval wellicht niet geld, is het heel goed mogelijk dat er meerdere soorten relaties bestaan tussen projecten en formulieren. (En wat niet is kan nog komen.)

In de meeste UML applicaties kun je bij een relatie een label toevoegen, in dit geval zou 'requires' denk ik een mooie zijn (want een bepaald project 'vereist' dat een formulier ingevuld wordt, als ik het goed begrijp) - daaruit zou ik een koppeltabel 'project_requires_form' afleiden.

Mocht je vervolgens ooit in de situatie komen dat een formulier 'de oorzaak' van een project is, dan heb je bij 'ProjectForms' de keuze om een tabel 'FormProjects' te maken met alle verwarring van dien. Bij 'project_requires_form' is de tegenhanger dan 'form_leads_to_project', wat wel direct duidelijk is.
Een derde optie is een veld toevoegen aan de koppeltabel om het soort relatie te beschrijven, maar daar wordt je ook niet gelukkig van.
Goed, formulieren die tot projecten leiden zijn wellicht niet iets wat voor deze applicatie ooit relavant gaat worden, maar je begrijpt het idee.