Many to many

[Cornelis]

Bij het analyseren van een database die aangepast moet worden (zie ander onderwerp) kom ik het volgende tegen:

 

Heel veel many to many relaties die volgens mij niet many to many moeten zijn, ik heb zelf altijd als uitgangspunt dat relaties altijd one to many moeten worden (tabel toevoegen etc.) tenzij er een hele goede reden voor is om dit anders te doen.

 

Maar ik kom hier in deze database zoveel eigenaardigheden tegen dat ik af en toe flink aan mezelf begin te twijfelen...

Hoe zien jullie dit (ik bedoel de many to many relatie)?

[Rony Rabijns]

Dat kom je toch heel vaak tegen :

 

een artikel kan op meerdere offertes staan

een offerte kan meerdere artikels hebben

 

een telefoonboek heeft meerdere nummers

een nummer kan in meerdere telefoonboeken staan

 

een bedrijf heeft leveranciers als klant

een leverancier heeft meerdere bedrijven als klant

 

en ga zo maar door.

 

Ik denk dat er meer many-to-many-relaties zijn dan one-to-many-relaties.

[Joris Aarts]

Als je bedoelt dat je in het diagram vaak kraaiepootjes aan de twee kanten van een relatie tegenkomt, dan heb je waarschijnlijk gelijk en schort er wat aan de velddefinities. Primary keys zijn dan niet gedefinieerd als 'uniek' of 'automatisch volgnummer' wat mogelijk kan leiden tot dubbele ID velden en da's miserie

Het kan ook zijn dat het een super-advanced ding is waarin gebruik wordt gemaakt van multikeys. Of het kan zijn dat er geknoeid is en dat men heeft geprobeerd om een 1-to-many te upgraden naar een many-to-many door stiekem af en toe een multikey in de key fields te proppen. In de meeste gevallen is een tussentabel een betere oplossing, wat jij ook suggereert.

In een slecht database-ontwerp moet je meestal tabellen toevoegen omdat vermeende 1-to-many relaties eigenlijk many-to-many's zouden moeten zijn.

[Cornelis]

Joris dat is inderdaad wat ik bedoel, dubbele kraaienpootjes.

Hoe weet ik of het een geavanceerd gebruik van multikeys betreft of een design gebrek?

 

Ik probeer:

In een multikey wordt er toch meer dan 1 waarde aan een veld toegekend (met returns ertussen?)?

Deze functie wordt toch gebruikt om ergens anders in een calculated field bepaalde formules mogelijk te maken?

 

In de database waar ik het over heb lijken de waardes die in de velden ingevoerd dienen te worden niet van het soort waarbij er meer mogelijkheden ingevoerd kunnen worden (er is bijv. een veld met naam contactpersoon of een met naam bedrijf of een met ID nummer)

[Joris Aarts]

In een multikey wordt er toch meer dan 1 waarde aan een veld toegekend (met returns ertussen?)?

Yep.

In de database waar ik het over heb lijken de waardes die in de velden ingevoerd dienen te worden niet van het soort waarbij er meer mogelijkheden ingevoerd kunnen worden (er is bijv. een veld met naam contactpersoon of een met naam bedrijf of een met ID nummer)

OK, dan zijn de velddefinities waarschijnlijk nogal slordig gemaakt en is er bijvoorbeeld geen controle of de primary keys wel ingevuld en uniek zijn. Dat kan op lange termijn voor problemen zorgen.

[Cornelis]

Kan het iets te maken hebben met het feit dat de database ooit met de oudere versies van FM is opgebouwd?

Ik kan dit niet goed inschatten want ik ken de versies van voor FM7 niet goed.

 

Als het inderdaad bekende dingen zijn uit oudere versies, dan zullen er wel meer herleidbare 'slordigheden' in de database zitten.

[Joris Aarts]

Kan het iets te maken hebben met het feit dat de database ooit met de oudere versies van FM is opgebouwd?

Nee, eigenlijk niet. In oudere versies (vanaf 3 ben ik zeker) kon je al de nodige controles op je velden zetten.

[Cornelis]

Dan vrees ik dat de database in de basis gewoon niet goed ontworpen is.

Het lukt niet om aanpassingen te doen d.m.v. 'lapwerk' want alternatieve oplossingen lopen steeds vast op simpele relaties die onhandig in elkaar zitten.

 

Ik zit wel te denken, is het misschien goed als er iemand even naar zou willen kijken, voor de zekerheid, mijn conclusie is nu wel heel negatief.