[SQL] Ontwerp contactlijst

[Verwijderd]

Heey,

Ik wilde graag jullie mening horen over hoe ik het zou doen:

Ik heb 2 tabellen, 1 tabel met daarin een UserID, een UserName en nog wat andere info.
De andere tabel is een contactlijst, waar ik voor elk toegevoegd contact de volgende info over opsla: UserID (van de persoon zelf), ContactID (van de andere persoon), blocked (bool) en accepted (bool).

Dus nog een keer op een rijtje:

Users
- UserID
- UserName
- Password
- etc...

Contacts
- UserID
- ContactID
- Blocked
- Accepted

Blocked voor als je iemand blokeert, en accepted voor als iemand toegevoegd is, maar nog niet is geaccepteerd.

Is het zo het slimst? Ik zat namelijk ook te denken aan 1 entry voor een User, met daarop alle contacten geseperated met bijvoorbeeld een ;, maar dat is volgensmij langzaam... Plus is het moeilijker om zoiets als blokkeren in te bouwen.

Mijn vraag: hoe moet ik nu de indexes instellen? Moet ik nu een primary key instellen op UserID en een Index voor ContactID? Of 2 indexen gebruiken op UserID en ContactID?

[NMe]

1. Comma seperated values horen sowieso niet thuis in een relationeel databasemodel.
2. Geef je contactentabel een eigen id-veld. Samengestelde keys werken niet prettig.
3. Voeg de blocked en accepted velden samen in één statusveld. Afhankelijk van hoe het in je DBMS heet kun je een enumeratietype maken met 3 waarden: pending, accepted of blocked.
4. Wat voor DBMS gebruik je eigenlijk? Dat is wel relevant voor je indexenvraag, aangezien sommige DBMS'en van PK's en FK's automatisch een index maken, en sommige niet.

[Verwijderd]

Ik gebruik MSSQL en daarbij de Visual Studio reeks.

Het heten allemaal daar Keys naar mijn idee... En je moet die (als ik het goed begrijp) 2 relaties opzetten door 2 relaties te adden als je rechtermuisknop gebruikt in Visual Studio, maar dat kan ik nog verder uitzoeken... (vooralsnog werkt het)

Maar dat van een ID is inderdaad misschien wel handig.


Ook heb ik in MSSQL gezien dat je gebruik kunt maken van een uniqueidentifier (of UID), is dat veel handiger als een integer die constant groter word (auto increment) of juist niet? Want zoals ik het nu zie, moet je die UID zelf genereren.. en dan bestaat de kans dat hij dubbel voor komt

[ Voor 30% gewijzigd door Verwijderd op 31-05-2006 20:31 ]

[NMe]

Als er geen verdere eisen aan je ID's gesteld worden (wat de Belastingdienst wel eens vereist bij zaken als factuurnummers, geloof ik) kun je gewoon gebruiken wat je zelf wil, als het maar uniek is. En dan lijkt een autoincrement integer me het makkelijkst werken.

Je zal in elk geval in je database aan moeten geven dat Contacts.UserID een foreign key is die verwijst naar Users.UserID, en hetzelfde geldt voor Contacts.ContactID. Overigens kun je daar ook nog eens een UNIQUE restrictie op leggen; een combinatie van die twee ID's mag maar één keer voorkomen.