[SQL] Primary key within Primary key

[El_BingO]

Ik zit met een probleempje.
Ik ben aan het uitzoeken of het mogelijk is om een primary key in een primary key te zetten. Klinkt vaag maar ik zal het uitleggen:

code:

ID subID Naam
1  1     Koala
1  2     Calimero
2  1     Frietje kerst
2  2     Salibam
2  3     Irritroop
3  1     Hoedelie
3  2     Koenjap
etc...

Per primary key (ID) moet subID weer opnieuw beginnen met tellen. Kan dit ik dit in MS-SQL implementeren? Zo ja, hoe?

Als iemand een idee heeft over een benaming, dan mag dat ook, dan weet ik tenminste waar ik op moet zoeken.

[dusty]

via omwegen en met stored prcedures en triggers is het allemaal wel te doen, de vraag is alleen wil je dit wel ECHT, of is je doel wat je probeert te bereiken ook te doen door je database model aan te passen?

[Verwijderd]

Hoe kan je die ID nou een Primaire Sleutel maken? Die is niet uniek in je tabel!

[El_BingO]

Op maandag 08 juli 2002 14:50 schreef dusty het volgende:
via omwegen en met stored prcedures en triggers is het allemaal wel te doen, de vraag is alleen wil je dit wel ECHT, of is je doel wat je probeert te bereiken ook te doen door je database model aan te passen?

Er is dus geen mogelijkheid om dat binnen de tabeldefinitie te doen? Dus een function o.i.d.?

Op maandag 08 juli 2002 14:52 schreef HPE het volgende:
Hoe kan je die ID nou een Primaire Sleutel maken? Die is niet uniek in je tabel!

De combinatie moet uniek worden...

[.GoO]

Je kan gewoon 2 keys nemen en die samen uniek maken.. Het nut zie ik er alleen niet van in..

[Grum]

Normalize je db es joh

[El_BingO]

Op maandag 08 juli 2002 14:53 schreef devv05 het volgende:
Je kan gewoon 2 keys nemen en die samen uniek maken.. Het nut zie ik er alleen niet van in..

Het gaat meer om het feit dat de telling automatisch moet verlopen.

[Verwijderd]

Op maandag 08 juli 2002 14:52 schreef El_BingO het volgende:
De combinatie moet uniek worden...

Dat is al beter ja. En de oplossing ligt in Triggers, maar hoe precies zou ik niet weten.

[Grum]

HPE: Dat is al beter ja. En de oplossing ligt in Triggers, maar hoe precies zou ik niet weten.


Ik hoop dat je bedoelt in een goede normalisatie/database design ?

[.GoO]

Op maandag 08 juli 2002 14:54 schreef El_BingO het volgende:

[..]

Het gaat meer om het feit dat de telling automatisch moet verlopen.

Autonummering?? Maar ik zie nog steeds het nut niet.. En het klopt ook gewoon niet.. Vertel eens duidelijk wat je wilt want er is vast een betere oplossing..

[El_BingO]

Op maandag 08 juli 2002 14:56 schreef devv05 het volgende:

[..]

Autonummering?? Maar ik zie nog steeds het nut niet.. En het klopt ook gewoon niet.. Vertel eens duidelijk wat je wilt want er is vast een betere oplossing..

Het gaat niet om de autonummering, maar het gaat er om dat ie een nieuwe regel toevoegd aan de kolom ID. De combinatie is dus uniek, en de regels (subID) horen bij ID.

[dusty]

Wie niet horen wilt moet voelen, Ik weet de exacte oplossing, ik wist ook wat je bedoelde, ik weet verschillende manieren om je probleem op te lossen.

Maarja, Negeren kan iedereen, IK OOK, let maar op.

[Verwijderd]

Waarom zou je in een tabel, laten we zeggen produkttabel, een primaire sleutel aan willen maken die uit 2 kolommen bestaat en dan ook nog eens ID en SubID heetten?

[Verwijderd]

Ik begrijp je

Als je een koppeltabel zou gebruiken dan tekkel(of tackle) je dat probleem in een keer. Dan maak je het jezelf een stuk gemakkelijker en je bent beter aan het optimaliseren

[El_BingO]

Ok, ik zal een beter voorbeeld geven.

Als je een order hebt, krijgt die een order een uniek nummer. Op de order staan orderregels, die gekoppeld zijn aan een order. Er is dus een tabel order, en een tabel orderregels.

Om te zorgen dat de orderregels geen uniek nummer krijgen dat een veelvoud is van het aantal orders, dacht ik aan een systeem, waarbij de combinatie order/orderregel uniek is. Zonder dat orderregel telkens door gaat tellen, maar per order opnieuw begint.
Dit is de beargumentatie, het model klopt, het gaat hier alleen om schoonheid en efficientie.

P.S. Ik negeer niemand, ik wil alleen graag een oplossing, of eventueel een duwtje in de rug.

[Dido]

En wat is er dan op tegen om je orderregels door te laten tellen? Je weet immer bij welke order ze horen, en je hebt ook geen gecombineerde PK nodig...

[Verwijderd]

Om te zorgen dat de orderregels geen uniek nummer krijgen dat een veelvoud is van het aantal orders

Waarom zou dat niet mogen dan?

//edit

Wie niet horen wilt moet voelen, Ik weet de exacte oplossing, ik wist ook wat je bedoelde, ik weet verschillende manieren om je probleem op te lossen.
Maarja, Negeren kan iedereen, IK OOK, let maar op.

? Dusty?

[Verwijderd]

Tja ik denk dat er geen betere oplossing dan de huidige is. Orderregels/factuurregels enzo zijn de bekendste databasevoorbeelden en worden altijd op dezelfde manier gemaakt.

[El_BingO]

Op maandag 08 juli 2002 15:11 schreef Dido het volgende:
En wat is er dan op tegen om je orderregels door te laten tellen? Je weet immer bij welke order ze horen, en je hebt ook geen gecombineerde PK nodig...

Heb je gelijk in, maar als ik 10 miljoen orders heb met daarop 10 regels, dan heb ik dus een primary key die tot 100 miljoen gaat.
Op zich niets op tegen, maar ik dacht misschien kan het ook wel zoals ik dacht.

[Verwijderd]

Overigens is dit te doen met een combinatie van generators en triggers.

1 Generator gebruik je voor het 1e ID, de 2e generator voor het 2e ID. Dan maak je een trigger die kijkt of het 1e ID 'opgehoogd word' en indien zo de 2e generator 'terug naar af' zet.

Het zijn echter geen van beide never nooit niet primary keys omdat ze simpelweg niet uniek zijn.

//edit

Op zich niets op tegen, maar ik dacht misschien kan het ook wel zoals ik dacht.

Alles kan, maar ik zou er zeker niet aan beginnen. De handel hoeft maar 1 keer in de soep te lopen en je kunt je database wegknikkeren. Dit is ononderhoudbaar..

[Dido]

Op maandag 08 juli 2002 15:14 schreef El_BingO het volgende:
Heb je gelijk in, maar als ik 10 miljoen orders heb met daarop 10 regels, dan heb ik dus een primary key die tot 100 miljoen gaat.
Op zich niets op tegen, maar ik dacht misschien kan het ook wel zoals ik dacht.

Daar is idd weinig op tegen hoor, en 10 miljoen orders, dat zijn er heel wat. Maar goed, het systeem waar ik nu mee werk slaat dergelijke dingen op als 7 bytes packed decimal, dus kunnen we tot 9,999,999,999,999 keys. Dat zit voorlopig nog niet vol...
Bij het preenteren van je gegevenskun je natuurlijk altijd nog een regelnummer genereren dat wel per order begint vanaf regel 1, en je kunt zelfs wel zoeken op regel 9 van order 123846. En dat er dan in de tabel een regelnummer staat van 12756732 maakt niet zoveel uit, lijkt me...

[El_BingO]

Op maandag 08 juli 2002 15:22 schreef Dido iets overtuigends

Ok, ik doe het wel zoals altijd

[Creepy]

Op maandag 08 juli 2002 15:45 schreef El_BingO het volgende:

[..]

Ok, ik doe het wel zoals altijd

En mocht je nog wel een manier vinden om je nummering op jouw manier goed te krijgen: Wat doe je dan als 1 order 10 regels heeft, en je haalt regel 5 weg!. Alle andere orderregels (6 en hoger) aanpassen zodat de nummering weer klopt????

Laat een volgnummer zoals je dit toont op je scherm, NOOIT afhankelijk zijn van je DB! Ook in een autonummering veld kunnen gaten vallen. Dus de eerste 3 records zouden als PK best wel eens 1, 3 en 10 kunnen hebben i.p.v. 1,2 en 3.