ID bei neuem Datensatz automatisch hochzählen

[Luca Haas]

Hi Leute,
wie es im Titel schon steht versuche ich mich gerade daran, die ID einer Datenbank-Tabelle mit jedem neuen Datensatz um eins hochzuzählen.
Im Internet habe ich dazu nicht allzu viel gefunden, lediglich, dass ich mit SELECT MAX(ID) den höchsten Wert für ID herausfinden kann und diesen dann mit +1 erhöhe, allerding verstehe ich nicht wirklich wie ich das machen soll.

[Mokus]

Das hört sich sehr nach ner Identity spalte an,

vielleicht hilft die dir.

https://docs.microsoft.com/de-de/sql...ntity-property

@EDIT
und dann herauszufinden welche zuletzt eingefügt wurde, kann man sich das per SELECT SCOPE_IDENTITY() auslesen.

[mkinzler]

Wäre auch gefährlich. Ich würde das durch das DBMS erledigen lassen. Bei MSSQL gibt es dafür den Feldtyp COUNTER

[Luca Haas]

Mmh okay, ich habe ich jetzt ein wenig in Auto_Increment eingelesen und versuche es mal damit.
Erfüllt zwar nicht 100% seinen Zweck, aber kommt doch sehr nah an das gewollte Ergebnis ran.

[Mokus]

"Erfüllt zwar nicht 100% seinen Zweck"

zu begin wolltest du eine möglichkeit es immer um X hochzuzählen, das wäre genau das.

& was erwartest du ? ;)

[Luca Haas]

Jetzt habe ich nämlich das Problem, dass ich die ID nicht mehr ändern kann. Da ich einen Wert gelöscht habe, sehen meine ID´s nun so aus "1, 2, 3, 5, 6" und ich kann es leider nicht mehr rückgängig machen.

Oder gibt es doch eine Möglichkeit die "fehlenden" ID´s einzusetzen ?

[Mokus]

https://docs.microsoft.com/de-de/sql...t-transact-sql

also es gibt die möglichkeit identity insert übersteuern, aber dann müsste man sich die nächste halt von hand ermitteln.
Und ob du dir da ein gefallen mit auto inc. spalten tust, bezweifel ich.
Dabei hilft dir dann aber auch max(Spalte) + 1 ja auch nicht ...


falls du nachher keine antwort hast schau ich nochmal ob ich da noch ein SQL finde, was sowas ermittelt, das hört sich nämlich nach einem bekannten Problem an.

[mkinzler]

Das Auffüllen kann in bestimmten Fällen Sinn machen. Es gibt aber auch viele Szenarien, in welchen es zu Problemen führen kann.

[jobo]

Wofür möchtest Du die ID benutzen?
Wenn es um einen Primärschlüssel geht: Der benötigt keine "nahtlose", aufsteigende Folge von Zahlen, nicht mal Zahlen, nur Eindeutigkeit.
Wenn es tatsächlich um eine nahtlose, aufsteigende Zahlenfolge geht, musst Du relativ viel aufwand treiben, falls mit der Nutzung bspw. einer Sequenz und folgender Löschung auch Lücken gefüllt werden müssen. max(id) reicht dann offensichtlich nicht mehr.

[haentschman]

Moin...:P

Zitat:

Da ich einen Wert gelöscht habe, sehen meine ID´s nun so aus "1, 2, 3, 5, 6" und ich kann es leider nicht mehr rückgängig machen.

Du brauchst eine Kombination aus beidem. :thumb:

1: Die ID aus der IDENTIY > die macht den Datensatz global eindeutig
2: Die ID aus dem "dass ich mit SELECT MAX(ID) den höchsten Wert für ID herausfinden kann + 1" und einem Update von dem entsprechenen Datensatz.

-> 2 Felder sind die Lösung.

[Mokus]

ps.
vielleicht hilft das ja schon ?

http://www.delphipraxis.net/85745-da...ds-finden.html

[Uwe Raabe]

Wenn das AutoInc-Feld als TFDAutoIncField angelegt ist (sollte bei automatischer Erkennung der Fall sein), dann kannst du über IdentityInsert den Wert vorgeben.

[Luca Haas]

Zitat:

Zitat von jobo (Beitrag 1385022)

Wofür möchtest Du die ID benutzen?

Also es geht um keinen Primärschlüssel, ich möchte damit quasi das n einer 1:n Beziehung darstellen.

[DeddyH]

Bei 1:n zeigen n Datensätze auf einen. Üblicherweise wird das durch einen Primärschlüssel auf der "1"-Seite und einen Fremdschlüssel auf der "n"-Seite realisiert. Dabei ist es aber völlig unerheblich, welchen Wert der Primärschlüssel hat und ob dort vielleicht Lücken vorliegen. Also nochmal für Doofe wie mich: wozu genau benötigst Du den Wert und wieso soll man ihn nachträglich ändern können?

[nahpets]

Dabei muss n weder eine Zahl, noch lückenlos sein, sondern höchstens nur irgendwas, was man aufsteigend soritieren kann, sofern n auch als Sortierkriterium dienen soll.

Die Ergebnisreihenfolge bei 'ner aufsteigenden Sortierung der ID ändert sich ja nicht, wenn die 4 fehlt.

Und wenn der nächste Satz einfach die erste freie ID bekommt, dürfte die ID kaum als (sinnvolles) Sortierkriterium dienen können. Es bedeutet dann ja nur: Ist nach ID sortiert, aber z. B. nicht in der Reihenfolge des Einfügens in die Datenbank ...

Ohne genaue Beschreibung der Notwendigkeit, halt' ich das für 'ne unnütze Spielerei ohne irgendeinen Mehrwert.

AutoInc-Werte sind nunmal dazu da, dass ein neuer Satz eine neue Nummer am Ende des genutzten Nummernkreises erhält. Sie ist nicht für irgendwelche sonstigen fachlichen Sachen geeignet, jedenfalls dann nicht, wenn man den Wert anschließend beliebig ändern kann.

So 'ne ID soll die Eindeutigkeit sichern, was bei wiederholter Verwendung aber wohl kaum dauerhaft sicher und fehlerfrei zu garantieren ist.

[jobo]

Zitat:

Zitat von Luca Haas (Beitrag 1385027)

Zitat:

Zitat von jobo (Beitrag 1385022)

Wofür möchtest Du die ID benutzen?

Also es geht um keinen Primärschlüssel, ich möchte damit quasi das n einer 1:n Beziehung darstellen.

Du kannst auch 1:n Beziehungen vollkommen ohne die von Dir genannten Kriterien "aufsteigend", "lückenfrei" usw. erstellen.
1:n sagt, zu einem bestimmten (genau bestimmbaren) Datensatz in einer Tabelle A, gibt es in einer anderen Tabelle B n Datensätze, die genau zu dem einen in Tabelle A gehören. Dies wird dadurch realisiert, dass die n Datensätze der Tabelle B in einer bestimmten Spalte den identischen Wert aus Tabelle A führen.

Es ist sozusagen State of the Art, diese Werte als ID/ Primärschlüssel und Fremdschlüssel zu bezeichnen.

Damit Entwickler und alle, die es wissen sollten, das leicht erkennen, gibt es zu diesen Begriffen auch analoge Sprachkonstrukte in SQL. Die ermöglichen die explizite Definition von Primary und Foreign Keys (Primär / Fremdschlüssel), was es wiederum dem Datenbanksystem erlaubt, diese Vorgaben zu überwachen und deren Einhaltung zu garantieren(!).

Alternativ kannst Du komplett ohne diese Begriffe und Definitionen und ihre Kenntnis arbeiten, nur durch die Anwendung von SQL Mengenoperationen. Damit verschenkst Du erhebliche Teile der Datenbankfunktionalität.

Oder noch mal andersrum:
Wenn Du selber fachlich keinen Bedarf an der Lückenlosigkeit der Zahlen hast, den hat auch niemand anders. Jedenfalls nicht die Datenbank und auch nicht eine 1:n Beziehung. Vergiss es einfach.

[Neumann]

Bei einigen unserer Kunden hat der beschriebene und auch nicht einfach zu vermeidende Umstand dass per Autoinc erzeugte Werte nicht unbedingt lückenlos sind, schon zu Misstrauen bei Betriebsprüfungen durch das Finanzamt geführt. Dabei ging es nicht um Rechnungsnummern, wo ich das noch verstehen könnte, sondern um Datensatz-IDs von Buchungen.

Die beste Lösung für dieses Problem ist einfach: Man macht diese Werte, die der Anwender ja eigentlich weder zu sehen noch zu bearbeiten hat einfach unsichtbar.

[p80286]

Da die ID eine Verwaltungsinformation der DB ist, hat sie ausserhalb der selbigen keinen Informationswert. Es sei denn, Du möchtest die Eintragung von Daten in einer zeitlichen Abfolge betrachten (Debugging). Was auch nur möglich ist wenn die ID über autoinc generiert wird.
Wenn Du zb. 5 neue Datensätze generierst und diese per rollback verwirfst, hast Du schon eine Lücke von 5 Werten.
Auch wenn es schon gesagt wurde, die ID dient einzig der eindeutigen Identifizierung des Datensatzes. Welchen Wert sie hat, ist vollkommen unerheblich.

Gruß
K-H

[bnreimer42]

Ich bin immer wieder verwundert, wie viele Gedanken man sich über die IDs machen kann.

Selbstverständlich sind die IDs reine technische Schlüssel und dürfen keine Semantik haben! Sonst ist das DB-Design "defekt".

Insbesondere darf man die IDs nie als Rechnungsnummer oder Aktenzeichen oder soetwas ähnliches benutzen. Dazu muss man eine eigenes Feld verwenden!

Daraus ergibt sich, dass IDs immer über AutoInc-Mechanismen (Oder bei Firebird Trigger mit gen_id()-Aufruf) erstellt werden sollten.

Ich mache mir auch keine Gedanken mehr, ob eine Tabelle ein ID-Feld benötigt: Es schadet nicht, wenn jede Tabelle eines hat und es hilft in jedem Fall, wenn man exakt einen Datensatz ansprechen will, z.b. beim Bearbeiten.


Einzig valide Frage ist, wie kommt man - um z.B. eine Fremdschlüsselbeziehung zu einem neuen Datensatz anzulegen, an den letzten ID-Wert und das geht prinzipiell immer erst, wenn der Datensatz in der DB gespeichert ist.

Bei u.a. Firebird gibt es dazu das wunderbare RETURNING-Konstrukt um bei einem Insert gleich Werte (z.B. die des ID-Feldes) zurückzubekommen.

Für FireDAC gibt es die schöne Doku-Seite http://docwiki.embarcadero.com/RADSt...lder_(FireDAC), die dazu alles zusammenfasst.

[Luca Haas]

Okay ich sehe grade, dass ich am Freitag ganz schön großen Mist geschrieben habe :oops:
Also ich haben 2 Tabellen, eine in der nur eine ID und eine "Aufgabe" steht, in der anderen Tabelle habe ich dann die jeweilige ID der Aufgabe, sowie alle Arbeitsschritte mit einer Position.
Diese Position hätte ich am liebsten durchgehend, mit der ID habe ich kein Problem

Falls jemand meinen Aufbau nicht verstanden hat, habe ich einen Screenshot angehangen