Database inrichting
Ik heb een vraagje hoe ik mijn database het beste kan inrichten.
Ik heb zelf bedacht dat dit mij dit het beste leek:
Table name: Contracts
Kolommen: Contract_ID PRIMARY AI, Contract_type PRIMARY
Table name: MailAddresses
Kolommen: Contract_type PRIMARY, Contract_mailaddress
Table name: Alle contract types
Kolommen: Contract_ID PRIMARY AI, Contract_type PRIMARY, en alle verdere nodige kolommen.
Table contracts bestaat zodat Contract_ID en Contract_type gekoppeld zijn met elkaar. (Of is dit overbodig?)
Vervolgens bestaat MailAddresses zodat er aan ieder type contract een mailadres te koppelen is.
En in de laatste tabellen staan alle gegevens van de contracten zelf. Deze heb ik in verschillende tabellen gezet omdat er verschillende kolommen per contract type zijn.
Iemand nog tips, of op- of aanmerkingen?
Alvast bedankt!
Met vriendelijke groet,
Peter Klaessens
contract_types:
# contract_type_id (PK)
* contract_type_description
contracts:
# contract_id (PK)
* contract_type_id (FK)
o contractor_email_address
Ward van der Put op 03/03/2017 12:13:14:
Ik zou eerder zoiets verwachten:
contract_types:
# contract_type_id (PK)
* contract_type_description
contracts:
# contract_id (PK)
* contract_type_id (FK)
o contractor_email_address
contract_types:
# contract_type_id (PK)
* contract_type_description
contracts:
# contract_id (PK)
* contract_type_id (FK)
o contractor_email_address
Ieder contract type hoeft maar 1 emailadres te krijgen. Ik vond het overbodig om in ieder record opnieuw het emailadres te herhalen. Dat is de reden waarom ik daar een aparte tabel van heb gemaakt.
Kan je mij een korte uitleg geven wat de #, * en het rondje inhouden?
Overigens moet het Contract_type in tabel Contracts in mijn geval wel een foreign key zijn, toch? (Foutje die ik nu inzie)
Gewijzigd op 03/03/2017 12:24:56 door Peter Klaessen
# is een sleutel;
* een verplicht gegeven;
o een optioneel gegeven.
Ward van der Put op 03/03/2017 12:29:00:
Je gebruikt de term type anders dan ik die zou gebruiken. Je zou verwachten je een handvol contracttypen hebt en honderden of duizenden contracten van één type. Je zou ook verwachten dat je per contractant een e-mailadres hebt, maar jij hebt kennelijk per type/soort contract maar één e-mailadres.
# is een sleutel;
* een verplicht gegeven;
o een optioneel gegeven.
# is een sleutel;
* een verplicht gegeven;
o een optioneel gegeven.
Allereerst bedankt voor reacties.
Misschien moet ik het toch op jou manier doen voor een eventuele latere aanpassing waarin elk contract toch een eigen email krijgt.
Ik heb inderdaad een handvol contracttypen. +/- 10. Ik ga in ieder record een email plaatsen.
Alleen ik weet nog niet zo goed hoe ik mijn database het beste kan inrichten. Ik verwacht dat alle contracten dezelfde velden krijgen. Verder wil ik wel per contract type permissies toepassen. Ik denk dat ik dmv php deze permissies ook op 1 tabel kan instellen. Zou het dan slim zijn om alles in 1 tabel te doen?
Als volgt:
contracts
#contract_id
contract_type
contract_name
...
Code (php)
1
een tabel een relatie heeft naar meerdere records uit een andere tabel.
Bovenstaande klinkt misschien ingewikkeld maar dat valt mee als je het in de praktijk brengt. voorbeeldje:
één gebruiker kan MEERDERE contracten hebben. Dit wordt dus een User tabel en een Contract tabel. In de contract tabel komt een FK naar de user van wie dit contract is. Dit noemen we een one-to-many relatie
Soms komt het ook voor dat meerdere records van tabel A een relaie hebben met meerdere records van tabel B.
Bijvoorbeeld een tabel Article en een tabel Category waarbij je wilt dat een categorie meerdere artikelen laat zien maar ook dat een artikel in meerdere categorieën geplaatst kan worden.
We noemen dit een Many-to-many relatie. Hierbij heb je drie tabellen nodig:
- Product
- Category
- products_categories (koppeltabel)
De koppeltabel krijgt twee FK kolommen: product_id en category_id.
Meerdere op elkaar lijkende items in één tabel
Je hebt meerdere contract types zeg je maar deze lijken qua opslag erg op elkaar.
Je kunt ze dan in één tabel opslaan. Voeg een extra kolom toe aan de tabel waarin je voor ieder type een unieke naam opslaat. We noemen dat een "discriminator column". Je applicatie ziet aan deze kolom over welk type contract het gaat en weet vervolgens welke kolommen in de tabel van toepassing zijn voor het huidige type. Als je OOP programmeert kun je dit ook heel mooi opvangen met afgeleide classen van één hoofd class.
Gewijzigd op 07/03/2017 14:55:47 door Frank Nietbelangrijk