[DB] Uniek veld met niet unieke waarden

[Jan_V]

Voor m'n werk wil ik in m'n eigen tijd eigenlijk een issue-logger bouwen, een kleine web applicatie waar klanten, ontwikkelaars, beheerders, etc. de bugs en opmerkingen kwijt kunnen.
Nu heb ik hier vanochtend in de auto over nagedacht hoe ik dit in de database wil gaan oplossen.
M'n idee is als volgt:
Er zitten meerdere klanten in het systeem met ieder hun eigen ID. Er kunnen in de loop der tijd meer klanten bij komen. Deze klanten worden in een klanten tabel opgeslagen met daarin dus hun auto-id, naam en nog wat andere gegevens.
Verder zou er nog een product tabel kunnen komen. Ieder product heeft ook weer z'n eigen ID, naam en andere gegevens.
Deze twee tabellen zijn behoorlijk simpel.
Nu komt er een derde tabel, de Issue tabel. Hierin moet een primary key staan (ID), een relatie naar de klant en een relatie naar het product. Uiteraard ook nog met informatie van het issue.
Hoe ik me de issue tabel voorstel is als volgt

IssueID

KlantID

ProductID

Melding

Opgelost

etc...

Het IssueID is het referentiepunt als er met een klant wordt gesproken, zodat we beide weten waar we over spreken.
Persoonlijk vind ik het niet mooi dat dit een auto-id veld wordt, want dan kan het voorkomen dat IssueID 1 bij klant 1 hoort, IssueID 2 bij klant 2 en IssueID 3 bij klant 1.
Klant 1 heeft dan de issue's 1 en 3. Dit is niet echt mooi, want zo ontstaan er gaten in de telling. Ik zou dus graag zien dat Klant 1 altijd opvolgende nummers heeft, dus 1, 2, 3, 4, 5, 6 en klant 2 ook dezelfde nummers kan hebben, maar dan voor andere issues.
Hieruit blijkt dat m'n eerste idee niet kan en dat de tabel er zo uit zal moeten komen te zien denk ik:

ID

IssueID

KlantID

ProductID

Melding

Opgelost

etc...

IssueID is dan niet meer uniek en gewoon een INT.

M'n vraag hierbij is, hoe zorg ik er voor dat het IssueID voor iedere klant uniek is.

De meest logische oplossing is om in de business laag het laatste IssueID van de betreffende klant op te halen en dit IssueID met 1 op te hogen. Dit vind ik eigenlijk een houtje-touwtje oplossing en vroeg me dus af of er betere methoden hiervoor zijn te bedenken.
Een andere oplossing is om iedere klant een eigen Issue-tabel te geven, maar dat vind ik een nog slechtere oplossing, aangezien je dan continu DB aanpassingen moet doen wanneer je een nieuwe klant in het systeem invoert.

Heeft iemand hier een beter idee voor dan ik zojuist heb geschetst in m'n business-laag voorbeeld?

Oh ja, de omgeving waar ik mee werk is SQL Server 2005 en .Net 3.5.

[RobIII]

Jan_V schreef op vrijdag 04 april 2008 @ 19:31:
Dit is niet echt mooi, want zo ontstaan er gaten in de telling.

Dan denk ik altijd... tjemig, maak je eens druk om zaken die er wél toe doen
Als dat je grootste probleem is dan ... dan... euh.
Wat boeit het nou dat er gaten in zitten? Het gaat toch om de functionaliteit? Dat je iemand kunt bellen en zeggen: het gaat over issue 239279. Dan weet je beide dat je het over dezelfde issue hebt. Maar het zal toch worst wezen als er een 'gat' in de nummering valt?

Er is vanalles op te verzinnen, van houwtje-touwtje tot superelegante tussenlagen en blablabla, maar persoonlijk zou ik dan liever wat meer tijd steken in een goed functionerende GUI, of nog wat extra puntjes op de i zetten in de helpfiles, of wat meer commentaar in de code... de vuilnis buiten zetten en eens kleppen met de receptioniste. En als ik me dan écht strontverveel misschien eens nadenken over gaten in mijn nummering. Om dan tot de conclusie te komen dat het niet boeit

...of krijg je ook mooi opeenvolgende ordernummers van Bol.com (om maar eens wat te noemen)

[ Voor 4% gewijzigd door RobIII op 04-04-2008 21:11 ]

[EfBe]

Dit gaat je niet lukken, want nummers assign je VOOR de commit van de transactie. Als de transactie terugrolt, moet je dus ook je nummers 'terugrollen' want je hebt ze niet gebruikt. Echter, de kans bestaat dat er al een andere transactie geweest is die al nummers heeft geclaimd en dus dat je je nummers niet meer kunt terugrollen. Het levert iig kans op dat je een nummer 2 keer gebruikt.

Verder is het onzinnig om te willen dat je opeenvolgende nummers hebt. Ik ben het geheel eens met RobIII, je moet je energie besteden aan dingen die er werkelijk toe doen.

[JaQ]

Uiteraard ben ik me er ter dege van bewust dat zelf maken altijd leuker is, maar is dit niet typisch een voorbeeld waarbij de make or buy decision in jouw nadeel uitvalt?

Er zijn vele mensen die een enorme hoeveelheid tijd hebben gestopt in het nadenken over issue/bug-trackers, deze geschreven hebben en daarna ook nog eens geopensourced (werkwoord van de week ) hebben. De afhandeling van issues/bugs binnen jouw werkgever zal toch niet fundamenteel verschillen van de werkwijze van andere bedrijven/projecten/oplosgroepen/whatever (en vaak is de "levensloop" van een bug configureerbaar).

Als ik jouw werkgever was en je ging op mijn kosten dit zitten ontwikkelen, vermoed ik dat ik je vriendelijk zou verzoeken bugs/issues op te gaan lossen in iets wat ik kan verkopen aan een klant.

edit:
mmm... ik lees net dat je dit in je eigen tijd wilt gaan doen... Misschien het datamodel van een paar bugtrackers bekijken? (valt allicht nog wat leuks uit te halen).

[ Voor 9% gewijzigd door JaQ op 05-04-2008 14:44 ]