Primary Key - Jahresabhängig?

[Dunlop]

Ich benötige einen Primary Key, der aus 2 Teilen besteht, und zwar sollte der so aussehen:

08359
08360
08361
09001
usw.

und zwar sind die ersten zwei Stellen die aktuelle Jahreszahl und die letzten 3 Stellen eine, am besten automatisch, fortlaufende Zahl. Soweit nicht so schwierig - könnte ja 2 Keys definieren - aber wenn ich nun einen Jahreswechsel habe, müssen die letzten 3 Zahlen wieder bei 0 beginnen.
In die Tables wird mit PHP geschrieben, ich möchte vermeiden, den Key selbstständig zu erhöhen, da ich bei paralleler Nutzung der Datenbank eventuell fehlerhafte Einträge bekommen könnte.
Vielleicht denke ich auch einfach nur zu kompliziert?

[dbwizard]

Ich benötige einen Primary Key, der aus 2 Teilen besteht, und zwar sollte der so aussehen:

08359
08360
08361
09001
usw.

und zwar sind die ersten zwei Stellen die aktuelle Jahreszahl und die letzten 3 Stellen eine, am besten automatisch, fortlaufende Zahl. Soweit nicht so schwierig - könnte ja 2 Keys definieren - aber wenn ich nun einen Jahreswechsel habe, müssen die letzten 3 Zahlen wieder bei 0 beginnen.
In die Tables wird mit PHP geschrieben, ich möchte vermeiden, den Key selbstständig zu erhöhen, da ich bei paralleler Nutzung der Datenbank eventuell fehlerhafte Einträge bekommen könnte.
Vielleicht denke ich auch einfach nur zu kompliziert?

Machdas nicht. Verwende einen techninsche PK (fortlaufenden Nummer) und definiere deinen "Spezialschlüssel" als zusätzliches Attribut, wenn du es unbedingt verwenden willst:

-Dein Primary Key ist per definition nicht unique (2-stellige Jahreszahlen ??)
-Du wirst in einer Multiuser-Umgebungen keine sauberen "Fortlaufenden" zahlen bekommen.


Gruss

[Bernhard Geyer]

-Dein Primary Key ist per definition nicht unique (2-stellige Jahreszahlen ??)

Good old Style aus den 70er Jahren. "Die SW wird doch niemals bis zum Jahre 2000 laufen ..:"

-Du wirst in einer Multiuser-Umgebungen keine sauberen "Fortlaufenden" zahlen bekommen.

Die bestimmung der nächsten neuen laufenden Nummer ist sinnvoll nur auf DB-Ebene durch z.B. eine SP's zu lösen.

[dbwizard]

Good old Style aus den 70er Jahren. "Die SW wird doch niemals bis zum Jahre 2000 laufen ..:"


Die bestimmung der nächsten neuen laufenden Nummer ist sinnvoll nur auf DB-Ebene durch z.B. eine SP's zu lösen.

- Aber nicht durch das einfache selektieren der höchsten vorkommenden ID in der Tabelle, das ist nicht transkationssicher

[Dunlop]

Besteht die Möglichkeit, einen PK der selbsterhöhend ist, auf einen bestimmten Wert zu setzen?
Als Beispiel:
der PK ist am Jahresende 2008 mit der Nummer 08653. Im nächsten Jahr (2009) setze ich den PK dann einfach auf 09000 und überspringe einfach die letzten 346 Schlüssel.

[dimitri]

Hi,

ein PK ist ein rein technischer Sclüssel und hat keinerlei fachliche Bedeutung zu haben. Jede Anforderung die so lautet wie Deine widerspricht dieser Anforderung.

Wenn Du ein bestimmtest fachliches Merkmal haben möchtest, dann leg dafür auch eine extra Spalte an und verwendet für den PK eine AutoInc feld, eine Guid etc.

Dim

[hwoess]

Abgesehen davon, ob das mit dem Jahr sinnvoll ist oder nicht, ist es natürlich technisch (mit kleiner Einschränkung) machbar. Da ein IDENTITY immer numerisch ist, gibt es keine führenden Nullen, es wäre in diesem Fall also besser, immer das gesamte Jahr zu verwenden.
Damit bei Jahreswechsel der nächste Record mit 200900001 startet, machst du einfach ein:
DBCC CHECKIDENT ("meineTabelle", RESEED, 200900000);

(siehe http://msdn.microsoft.com/de-de/library/ms176057.aspx)

bye,
Helmut

[Dunlop]

Danke,

das ist eigentlich genau das, was ich brauche.
Eine kurze Frage habe ich dennoch: lösche ich einen Datensatz am Ende, dann wird die letzte, gelöschte Nummer leider nicht wieder verwendet, sondern eine neue angelegt, obwohl die letzte Nummer nicht mehr existiert. Gibts dafür irgend einen workaround, dass beim Eintragen automatisch auch die letzte Numemr vergeben wird?

[dimitri]

Nein gibt es nicht und in einer Multiuserumgebung wäre/ist das auch nicht möglich.

Dim