[DB Layout] Indeling primary keys*

[Verwijderd]

even een vraagje hoop dat ik hier goed zit en iemand mij kan helpen. Ik ben bezig met een informatie systeem in Delphi. Ik wil een applicatie maken waar ik mijn gedownloaden series in kan beheren. Hier in wil ik mijn series - seizoenen - afleveringen in bij houden. Welke ik al heb, nog moet hebben, welke ik moet vervangen i.v.m kwaliteit. etc etc.

Nu heb ik een klein db Layout opzetje gemaakt alleen betwijfel ik of het goed is:

Tabel = Serie (PK = Serie Naam)
Tabel = Seizoen (PK = ??)
Tabel = Aflevering(PK = ??)
Tabel = Categorie (Info bij Serie)
Tabel = Rip (Soort rip als extra info bij Aflevering)

Hier bij ga ik er van uit dat 1 Serie 1-* Seizoenen heeft en een Seizoen 1-* Afleveringen heeft.
Hoe kan ik nu verschillende soorten Series in voeren zonder dat ik in conflict kom met aflevering nummer en seizoen nummer.

Bijv: Serie SG-1 heeft Seizoen 1 met Aflevering 1
Maae: Serie Lost heeft ook Seizoen 1 met Aflevering 1

Ik kan dus bij Aflevering en bij Seizoen Seizoen_NR en Aflevering_NR niet als primaire key gebruiken.

Hoe kan ik dit het beste onder vangen. want ik zal ze wel moeten kunne koppelen Als ik een autonummering gebruik dan zou het wel werken maar dan heeft SG-1 Seizoen 1 Autonummering 1
maar Lost Seizoen 1 Autonummering 11 omdat SG-1 al 10 seizoenen heeft.

hoop dat iemand 1 mijn tekst snapt en 2 mij kan helpen

[Upsal]

Ik denk dat je bij die tabellen 'aflevering' en 'seizoen' een primary key moet gebruiken over meerdere kolommen, en hier evt. foreign key constrains op leggen die verwijzen naar de andere tabellen.

[mulder]

Serie + Seizoen + Volgnummer als PK, Volgnummer door code of een trigger genereren.

[Verwijderd]

Upsal schreef op woensdag 12 april 2006 @ 16:20:
Ik denk dat je bij die tabellen afleveringen en seizoen een primary key moet gebruiken over meerdere kolommen, en hier evt. foreign key constrains op leggen die verwijzen naar de andere tabellen.

dubbele key ?

Tabel = Serie (PK = AutoIncrement)
Tabel = Seizoen( Dubbele key van Serie_Naam + Seizoens nummer)

dat maakt de pk van seizoen uniek

maar hoe pak ik dan de tabel aflevering aan?

[whoami]

Ik ben niet zo te vinden voor natural primary keys... Een primary key is imo gewoon een administratief gegeven in een DB, en kan best iets zijn waar je geen betekenis aan geeft (een identity bv).
Op die manier kan je ook probleemloos je gegevens wijzigen, zonder dat dit gevolgen heeft voor foreign keys; iets wat met natural keys wel eens een probleem kan zijn.
(Stel dat je een pk legt op serie-naam; de volgende dag zie je dat je een tik-fout gemaakt hebt. je wil dat veranderen; dat wil dan ook zeggen dat je in al je gerelateerde tabellen, de foreign key ook moet gaan aanpassen).

Los van het feit dat een index (en een PK) op een string veld minder efficient is dan een PK op een integer veld.

[Upsal]

Dit bedoelde ik :-/

Tabel = Serie (PK = AutoIncrement SerieID)
Tabel = Seizoen (PK = SerieID, SeizoenID) (PK van 2 kolommen lang)
Tabel = Aflevering(PK = SerieID, SeizoenID, AfleveringID) (PK van 3 kolommen lang)

Maar die AutoIncrement methode waarbij er ID's 'verzonnen' worden kan ook (zoals whoami zegt).

@whoami: je kunt in sommige DB's ook gebruik maken van CASCADE UPDATE, zodat het later veranderen van de namen kan..

[ Voor 36% gewijzigd door Upsal op 12-04-2006 16:37 ]

[whoami]

Upsal schreef op woensdag 12 april 2006 @ 16:33:

@whoami: je kunt in sommige DB's ook gebruik maken van CASCADE UPDATE, zodat het later veranderen van de namen kan..

Dat weet ik, maar dan heb je natuurlijk weer meer UPDATE's die moeten uitgevoerd worden (meer read/writes, voor een simpele update)

[Verwijderd]

Upsal schreef op woensdag 12 april 2006 @ 16:33:
Tabel = Serie (PK = AutoIncrement SerieID)
Tabel = Seizoen (PK = SerieID, SeizoenID) (PK van 2 kolommen lang)
Tabel = Aflevering(PK = SerieID, SeizoenID, AfleveringID) (PK van 3 kolommen lang)

maar hoe kan ik nu weten als ik eennieuwe aflevering in voer bij welk serie en seizoen hij hoordt want ik en toch niet alle id's uit mijn hoofd?

[ Voor 3% gewijzigd door whoami op 12-04-2006 17:10 ]

[whoami]

Dat zal jij zelf toch -als gebruiker- moeten specifieren bij het ingeven .

Door dat de gebruiker dat aangeeft, weet je toch wat de PK is van de geselecteerde serie/seizoen ?

[Verwijderd]

code:

Sg-1
      Seizoen 1
                   Aflevering1
                   Aflevering2
                   Aflevering3
                   Aflevering4
                   Aflevering5
                   Aflevering6
      Seizoen 2
                   Aflevering1
                   Aflevering2
                   Aflevering3
                   Aflevering4
                   Aflevering5
                   Aflevering6

hoe krijg ik dan deze layout als ik met ID's ga werken

[ Voor 3% gewijzigd door Verwijderd op 12-04-2006 17:15 ]

[whoami]

Je haalt gewoon de gegevens op mbhv SQL zoals je dat anders zou doen (behalve het feit dat je queries een stuk eenvoudiger worden door met id's te werken ipv natural keys), en je Delphi programma moet er gewoon voor zorgen dat de opgehaalde gegevens in een mooie layout komen te staan.

* whoami ziet het probleem niet ?
Hoe zou je die layout verkrijgen als je gebruik maakt van natural keys, en waarom zou dat plots een probleem zijn als je gebruik maakt van surrogate keys ?

[ Voor 26% gewijzigd door whoami op 12-04-2006 17:19 ]

[Creepy]

Gezien de antwoorden die nu al gegeven zijn snap ik je vraag nu niet.
De relatie tussen Serie en Seizoen is 1:n. De relatie tussen Seizoen en Aflevering is ook 1:n.

Een 1:n relatie in een Database vastleggen is basisfunctionaliteit die in nagenoeg elke tutorial wordt behandeld. Dus wat is je probleem nu precies?

edit: whoami

[ Voor 10% gewijzigd door Creepy op 12-04-2006 17:22 ]

[SinergyX]

1 hoofdtabel:
Autoinc_ID | Serie_ID | seizoen | aflevering | Afl_naam | hebik_ja/nee

1 subtabel (heb je achteraf niet zo probleem met typo's in serie naam):
Serie_ID | naam

klaar?

[Verwijderd]

ik bedoel eigenlijk te zeggen

als ik 1 aflevering toevoeg wil ik een serie en een bijhoorden seizoen selecteren als ik met ID's als key werk dan krijg ik toch een lijst met id's en weet dan toch niet welke id waar voor staat?

of zie ik dat verkeerd

[Bergen]

Hoppa, gewoon elke tabel een id als primary key. Let op dat seizoenen soms ook namen hebben, dus dan valt de optie van inline-nummering al af. Wat die rip-info betreft, is dat info die bij een specifieke aflevering hoort? Want dan kan dat gewoon in de afleveringentabel worden opgeslagen.

Verwijderd schreef op woensdag 12 april 2006 @ 17:43:
ik bedoel eigenlijk te zeggen

als ik 1 aflevering toevoeg wil ik een serie en een bijhoorden seizoen selecteren als ik met ID's als key werk dan krijg ik toch een lijst met id's en weet dan toch niet welke id waar voor staat?

of zie ik dat verkeerd

Ja, dat zie je verkeerd. Zodra je een aflevering toevoegt, doe je eerst onder andere een select * from categorieen, dan heb je id's en namen. Zodra je in de invoerpagina een categorie hebt geselecteerd moet je applicatie weten welk id daarbij hoort.

[ Voor 86% gewijzigd door Bergen op 12-04-2006 18:20 . Reden: classes gefixt ]

[Verwijderd]

Overbodig

[ Voor 104% gewijzigd door Verwijderd op 12-04-2006 19:10 ]

[Bergen]

Verwijderd schreef op woensdag 12 april 2006 @ 18:18:
Rip bevat: TV-Rip / HDTV-Rip / DVD-Rip en elke aflevering heeft een ander type

hier zie je de tabellen met de kolommen deze kolommen wil ik gebruiken

[afbeelding]

let even niet op de PK

Ja, dat werkt dus niet. Bij afleveringen gebruik je nu Aflevering_NR als primary key. Dan kan elk afleveringnummer maar 1x in de tabel voorkomen. Kan natuurlijk niet. (Tenzij je maar 1 serie met 1 seizoen wilt opslaan. ) Bij seizoenen 't zelfde verhaal overigens.

[ Voor 5% gewijzigd door Bergen op 12-04-2006 18:24 ]

[Verwijderd]

Bergen schreef op woensdag 12 april 2006 @ 18:24:
[...]
Ja, dat werkt dus niet. Bij afleveringen gebruik je nu Aflevering_NR als primary key. Dan kan elk afleveringnummer maar 1x in de tabel voorkomen. Kan natuurlijk niet. (Tenzij je maar 1 serie met 1 seizoen wilt opslaan. ) Bij seizoenen 't zelfde verhaal overigens.

zoals ik al zei let even niet op de pk die ik nu heb want zo klopt het niet

[Bergen]

Nee idd. Gewoon elke tabel z'n eigen id als primary key, dan ben je van 't hele probleem af.

[Verwijderd]

Bergen schreef op woensdag 12 april 2006 @ 18:28:
Nee idd. Gewoon elke tabel z'n eigen id als primary key, dan ben je van 't hele probleem af.

tabelnaam_ID : AutoInc op elke tabel is voldoende dan?

[Bergen]

Yep. Hou 't simpel trouwens, dus niet 'tabelnaam_ID' maar gewoon 'id', zoals in mijn bovenstaande overzicht. Daar worden je queries e.d. veel overzichtelijker door.

[edit]
Inderdaad, verdiepen in nominalisaties is geen slecht plan. Dat zou iedereen moeten doen die met databases werkt.

[ Voor 92% gewijzigd door Bergen op 12-04-2006 18:32 ]

[NMe]

Die primary keys zijn juist essentiëel voor het kunnen oplossen van dit probleem en dienen gewoon meteen te kloppen?

Heb je enig idee wat databasenormalisatie inhoudt? Zo ja, dan draai je je hand niet om voor dit probleem. Zo nee, dan doe je er goed aan om er nu wat over te gaan lezen.

[Verwijderd]

-NMe- schreef op woensdag 12 april 2006 @ 18:31:
Die primary keys zijn juist essentiëel voor het kunnen oplossen van dit probleem en dienen gewoon meteen te kloppen?

Heb je enig idee wat databasenormalisatie inhoudt? Zo ja, dan draai je je hand niet om voor dit probleem. Zo nee, dan doe je er goed aan om er nu wat over te gaan lezen.

jah ik kan normaliseren, ik botste alleen tegen wat dingen aan vandaar dat ik hier binnen viel. ik wil namelijk geen fouten maken in het programma. Zoals je kunt zien in deze post zie je mensen verschillende oplossingen geven. ik wilde geen gebruik maken van dubbele keys dit heeft voorheen wel eens problemen gegeven

[NMe]

Dubbele keys? Als in een compound key (2 of meer velden die samen een primary key vormen)? [rml]whoami in "[ DB Layout] Indeling primary keys*"[/rml] zei het al; dat is dus niet echt nodig. Veel mensen geven de voorkeur aan een enkelvoudige PK met daarin een auto incremented ID.

[Verwijderd]

-NMe- schreef op woensdag 12 april 2006 @ 19:07:
Dubbele keys? Als in een compound key (2 of meer velden die samen een primary key vormen)? [rml]whoami in "[ DB Layout] Indeling primary keys*"[/rml] zei het al; dat is dus niet echt nodig. Veel mensen geven de voorkeur aan een enkelvoudige PK met daarin een auto incremented ID.

ik heb nu dit, dus zo moet het dan goed zijn?

[NMe]

Die tabellen met maar één veld vind ik vreemd. Als je toch maar één ding hebt om op te slaan en deze tabellen elk maar bij één andere tabel kunnen horen, waarom heb je die tabellen dan nodig? Als je ze wil houden/uitbreiden: voeg dan ook in deze tabellen een ID toe waarmee je de andere tabellen koppelt. En wat doet Seizoen_Naam in de Serie-tabel?

[Verwijderd]

rip en categorie genre zijn lijsten die ik niet meer edit en dmv een picklistje selecteer in de tabellen aflevering en Serie

Seizoens naam hoord er ook niet thuis goed op gemerkt ik ben hier echt al te lang mee bezig dat ik zelf al niet meer zie wat ik doe.

[NMe]

Je maakt er wat betreft opslaggrootte geen winst op als je niet een ID-veld toevoegt in die twee tabellen. Daarnaast ben ik het met whoami eens:

whoami schreef op woensdag 12 april 2006 @ 16:29:
Ik ben niet zo te vinden voor natural primary keys...

Gebruik dus liever ID's.