View Full Version : SQL Auto Increment
Ergebnisse 1 - 10 von ungefähr 6.390.000.000 für i
Es wurden keine mit Ihrer Suchanfrage - . - übereinstimmenden Dokumente gefunden.
Vorschläge: * Probieren Sie andere Suchbegriffe.
no comment
D*B
Schön, wie dieser Thread abgedriftet ist!
Mein Vorschlag, um den Bekanntheitsgrad noch einmal richtig voranzubringen: Das "i" (ich meine den unteren Strich) weglassen und nur noch den Punkt verwenden. Jeder Punkt gilt! Das wäre doch auch für Google eine schöne neue Aufgabe ... (und wieder drei Punkte)
Um wieder zum Thema zurückzukommen:
Diverse Frameworks für Datenbankmodelle zur angeblich schnelleren Entwicklung von Business Objekten mit Datenhaltung, also Objekt-Hierarchie versus relationale DB, arbeiten fast ausschließlich mit SingleKeyes, 32/64-Bit am besten 128-Bit GUID's!
D.h, DB-Modelle wie "Mandant, Auftrags-Nr, Auftrags-Position" als Schlüssel werden gar nicht unterstützt.
Man muss also mit Identities arbeiten.
Ein nachträgliches Aufsetzen einer neuen Framework-Applikation auf bestehenden DB's wird somit zielgerichtet verhindert.
Man kommt also nicht umhin, neben seiner Applikation gleich auch noch das DB-Modell mit anzupassen.
Insofern sind Identities für zukunftige Entwicklungen wohl durchaus normal, wenn man nicht bei der alten zeilenweisen Programmierung verbleiben will ;).
... der Punkt ist doch nicht ob man einen Primary Key hat und ob der einen semantischen Inhalt hat, sondern ob man sich den von der Datenbank generieren lässt, um ihn anschließend erst mal zu ermitteln, weil man ihn als Foreign Key für andere zu schreibende Tabellen benötigt - da steht doch jede Logik Kopf.
D*B
Um wieder zum Thema zurückzukommen:
Diverse Frameworks für Datenbankmodelle zur angeblich schnelleren Entwicklung von Business Objekten mit Datenhaltung, also Objekt-Hierarchie versus relationale DB, arbeiten fast ausschließlich mit SingleKeyes, 32/64-Bit am besten 128-Bit GUID's!
D.h, DB-Modelle wie "Mandant, Auftrags-Nr, Auftrags-Position" als Schlüssel werden gar nicht unterstützt.
Man muss also mit Identities arbeiten.
Ein nachträgliches Aufsetzen einer neuen Framework-Applikation auf bestehenden DB's wird somit zielgerichtet verhindert.
Man kommt also nicht umhin, neben seiner Applikation gleich auch noch das DB-Modell mit anzupassen.
Insofern sind Identities für zukunftige Entwicklungen wohl durchaus normal, wenn man nicht bei der alten zeilenweisen Programmierung verbleiben will ;).
andreaspr@aon.at
29-01-10, 07:03
... der Punkt ist doch nicht ob man einen Primary Key hat und ob der einen semantischen Inhalt hat, sondern ob man sich den von der Datenbank generieren lässt, um ihn anschließend erst mal zu ermitteln, weil man ihn als Foreign Key für andere zu schreibende Tabellen benötigt - da steht doch jede Logik Kopf.
D*B
finde diese off-topic beiträge recht interessant :-)
verstehe grad nicht, was da gemeint wurde.
wenn 2 tabellen miteinander per FK verknüpt werden, muss immer zuerst die ID ermittelt werden bevor sie referenziert wird.
da ist es ja egal, ob der key vom programm oder der DB generiert wird.
... bei normalisierten Daten umfasst ein insert aus Programmsicht mehrere inserts in die Datenbank, bei denen man oft die soeben geschriebenen Schlüssel für andere Tabellen als Foreign Key benötigt.
D*B
finde diese off-topic beiträge recht interessant :-)
verstehe grad nicht, was da gemeint wurde.
wenn 2 tabellen miteinander per FK verknüpt werden, muss immer zuerst die ID ermittelt werden bevor sie referenziert wird.
da ist es ja egal, ob der key vom programm oder der DB generiert wird.
andreaspr@aon.at
29-01-10, 07:24
ich verstehe da nur noch immer nicht das problem?
ist ja doch ganz normal.
Ich kann das Problem eigentlich auch nicht nachvollziehen.
Arbeitet man mit Identity Columns und fügt einen einzelnen Satz mit SQL oder native I/O ein, kann man der eingefügten Identity-Wert mit dem SQL Befehl Identity_Val_Local ermitteln.
Dabei ist es unerheblich, wie der Satz erzeugt wurde (SQL oder Native I/O). Das der Job und innerhalb des Jobs das Job-Level wird berückichtigt, d.h. auch wenn durch einen anderen Job oder einen Trigger ein weiterer Datensatz hinzugefügt wurde, wird der Wert des vorhergehenen Inserts oder Writes ermittelt.
Bei Sequences ermittelt man den Wert zuerst und schreibt dann.
Werden bei einem SQL Insert mehrere Sätze eingefügt, kann man die soeben eingefügten Datensätze (ab 6.1) mit allen (generierten) Werten wie folgt ermitteln. Das Insert-Statement wird innerhalb eines Select-Statements ausgeführt.
z.B.
'
Select HdrId, OrderNo
From Final Table(Insert OrderHdr(OrderNo, CustNo, DelTerms,
DelDate, OrderType)
Select IFORDN, IFCUST, IFDELT,
Date(Digits(IFDELT concat '000000',
IFORDT)
From Interface
Where IFSTAT = ' ')
Order By Input Sequence
Birgitta
... alles viel komplizierter als vorher getNextKey(Dateiname) aufzurufen und den Key zu belegen und last not least sind diese ganzen Features nicht ANSI SQL und damit rate ich davon ab!
Wer sich lieber an DB2/400 bindet, mag das tun.
D*B
Ich kann das Problem eigentlich auch nicht nachvollziehen.
Arbeitet man mit Identity Columns und fügt einen einzelnen Satz mit SQL oder native I/O ein, kann man der eingefügten Identity-Wert mit dem SQL Befehl Identity_Val_Local ermitteln.
Dabei ist es unerheblich, wie der Satz erzeugt wurde (SQL oder Native I/O). Das der Job und innerhalb des Jobs das Job-Level wird berückichtigt, d.h. auch wenn durch einen anderen Job oder einen Trigger ein weiterer Datensatz hinzugefügt wurde, wird der Wert des vorhergehenen Inserts oder Writes ermittelt.
Bei Sequences ermittelt man den Wert zuerst und schreibt dann.
Werden bei einem SQL Insert mehrere Sätze eingefügt, kann man die soeben eingefügten Datensätze (ab 6.1) mit allen (generierten) Werten wie folgt ermitteln. Das Insert-Statement wird innerhalb eines Select-Statements ausgeführt.
z.B.
'
Select HdrId, OrderNo
From Final Table(Insert OrderHdr(OrderNo, CustNo, DelTerms,
DelDate, OrderType)
Select IFORDN, IFCUST, IFDELT,
Date(Digits(IFDELT concat '000000',
IFORDT)
From Interface
Where IFSTAT = ' ')
Order By Input Sequence
Birgitta
Was nützen mir die Features von V6, wenn ich z.T. noch mit V5R2 arbeiten muss.
NEXT VALUE gab es da allerdings auch schon und das Problem der Foreign Keys gibt es da auch schon.
Sequences und Identities sind ja auch ganz nett erhöhen aber nun mal den Programmier- und Wartungsaufwand. Fehlerquellen sind da schon vorprogrammiert.
In properitären Anwendungen wurden ja damals schon Tabellen mit Zählschlüsseln verwaltet, für die man nun nachträglich auch noch Dieters getnextkey() entwicklen kann um somit Masseninserts (insert ... select) problemlos realisieren zu können.
Was mir bei den Identities und Sequences nicht so gut gefällt ist die Cache-Funktion, die mir Nr'n verbrät und die ich gezielt abschalten muss (zu Lasten der Performance), der Default ist 20.
andreaspr@aon.at
29-01-10, 08:33
ich behaupte dass weder die eine methode noch die andere kompliziert sei.
die frage ist vielmehr eine geschmackssache.
und was das ANSI SQL betrifft:
ab 6.1 gibt es zumindest die möglichkeit vom OS das SQL auf ANSI SQL prüfen zu lassen.
ich kenne aber sowieso keine (größere) datenbank die nicht features hat, welche nicht ANSI SQL sind. was meiner meinung egal ist, da man nie auf die idee kommen würde/sollte zb:
die datenbank eines Lagerverwaltungssystems von DB2 auf oracle umzustellen.
und zu sequences und identities:
ich weis nicht wie damit sonst noch programmiert wird, aber einen mehraufwand habe ich bis jetzt noch nie gehabt.