mikrocontroller.net

Forum: PC-Programmierung MySQL: Spalte mit lückenloser fortlaufender Nummerierung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Emil (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich möchte Zeilen in eine Datenbank einfügen:

insert into rechnungen set name='emil maier', betrag=23
insert into rechnungen set name='tom schmidt', betrag=42
insert into rechnungen set name='kenny blubb', betrag=1
usw.

Jetzt gibt es noch die Spalte "rechnungsnummer". Die soll bei 1 starten 
und dann lückenlos(!) fortlaufend nummeriert sein. Wie muss ich den 
insert-Query abändern, um die rechnungsnummer entsprechend zu setzen? 
Ich will eigentlich nicht zwei abfragen mit select und max machen 
müssen...

von sid (Gast)


Bewertung
1 lesenswert
nicht lesenswert
-> rechnungsnummer AUTOINCREMENT (AI Häkchen in phpmyadmin )
und NICHT beim Insert befehl angeben, dann zählt myswl stumpfsinnin hoch 
(bei eins beginnend)

von sid (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wenn Du die rechnungsnummer nach dem insert haben willst brauchst Du
nur LAST_INSERT_ID()  abzufragen (die wird automatisch als 
'erfolgsmeldung' übergeben und steckt schon im query -result quasi..
Aber obacht: bei multiinsert immer nur die letzte!

von Emil (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
So weit war ich auch schon, aber auto_increment garantiert keine 
lückenlose Nummerierung...
Ich kriege so ständig Lücken in den IDs. Am Script liegt's nicht. Ich 
kann auch in phpMyAdmin per Hand einzelne inserts einklimpern und das 
Problem tritt auf.

von svensson (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Falls mit einer Programmiersprache gearbeitet wird: einfach vorher die 
höchste vorhandene ID abfragen und dann insert mit x+1 .

von Emil (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zwischendrin lösche ich natürlich keine Zeile. Nur, falls die Frage 
kommen sollte.

von Emil (Gast)


Bewertung
0 lesenswert
nicht lesenswert
So eine Grundfunktion muss doch aber vorhanden sein.

von Daniel F. (df311)


Bewertung
0 lesenswert
nicht lesenswert
Emil schrieb:
> So weit war ich auch schon, aber auto_increment garantiert keine
> lückenlose Nummerierung...
> Ich kriege so ständig Lücken in den IDs. Am Script liegt's nicht. Ich
> kann auch in phpMyAdmin per Hand einzelne inserts einklimpern und das
> Problem tritt auf.

hmm, das wäre mir noch nie untergekommen.

zeig mal ein minimalbeispiel und sag ein paar (mehr 
versions)informationen

von SQuirreL (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nutz doch einfach eine Sequence.

von olibert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Emil schrieb:
> auto_increment garantiert keine lückenlose Nummerierung

Das kann nicht sein. Auto-Increment funktioniert einwandfrei.
Wo definierst du auto_increment ?

von sid (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Emil schrieb:
> So weit war ich auch schon, aber auto_increment garantiert keine
> lückenlose Nummerierung...

DOCH!

ein table truncate setzt nur nicht die auto increment value zurück.
das musst du beim testen händisch machen falls Du das brauchst.

Du darfst NIEMALS eine rechnungsnummer manuell angeben bei einem insert,
und du darfst niemals ein replace machen
das ist das einzige was Du Dir merken musst.

replace löscht die alte ID und erstellt eine Neue.
(dazu braucht es stattdessen ein on duplicate key update)

beim insert die ID 'setzen' erzeugt entweder einen Fehler (ID vorhanden)
oder überspringt alle Nummern bis zur gesetzten ID und erhöht dann die
auto increment value.

wenn Du das beachtest ist auto inccrement exakt das was Du suchst.
Du musst halt nur aufpassen, daß Du dir das nicht mit schlechtem SQL 
Code selber versaust.
(was ich fürchte hier der Fall sein wird)

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
svensson schrieb:
> Falls mit einer Programmiersprache gearbeitet wird: einfach vorher die
> höchste vorhandene ID abfragen und dann insert mit x+1 .

Und wenn mehrere Clients das parallel machen?

von Clemens L. (c_l)


Bewertung
0 lesenswert
nicht lesenswert
AUTO_INCREMENT ist auf Skalierbarkeit optimiert, und garantiert deshalb 
nicht fortlaufende Nummern, insbesondere bei fehlgeschlagenen 
Transaktionen.

Für deine Anforderung brauchst du einen Zähler in einer separaten 
Tabelle (und SET TRANSACTION ISOLATION LEVEL SERIALIZABLE).

von SQuirreL (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dann sollte das hoffentlich in einer Transaktion stattfinden und die 
Table gelocked sein.

von SQuirreL (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Auto-Increment dekrementiert sich bei einem Rollback der Transaktion 
nicht.

Unhübsch, mit einem Index auf der Spalte sollte aber sowas gehen:

insert into rechnungen set name='emil maier', betrag=23

INSERT INTO rechnungen
SET name='Berta Fisch',
    betrag=23,
    rechnungs_nr = (SELECT IFNULL( MAX( rechnungs_nr ) , 0 ) + 1 FROM 
rechnungen r))

von SQuirreL (Gast)


Bewertung
0 lesenswert
nicht lesenswert
SQuirreL schrieb:

> insert into rechnungen set name='emil maier', betrag=23
>

Das natürlich nicht, sondern der untere Teil, das sich per MAX den 
höchsten Wert holt

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Emil schrieb:
> lückenlos

Streiche diese unnötige Anforderung, dann wird alles einfacher.

von imonbln (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich persönlich würde ungern eine Fortlaufende Rechnungsnummer den Kunden 
mitteilen wollen. Das ermöglicht jeden der das "German Tank Problem" 
(https://de.wikipedia.org/wiki/German_tank_problem) kennt und mehr als 
einmal bei mir Kauft abzuschätzen wie viel Rechnungen ich schreibe.

von DPA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich glaub auch, du solltest den Quatsch lassen. Eine Durchnumerierung 
und eine ID sind grundlegend verschiedene Dinge. Bei Dingen wie einer 
Rechnungsnummer macht es eventuell sogar sinn, diese zu Randomisieren, 
denn es ist nicht unbedingt wünschenswert, dass wer auch immer die 
Sieht, weiss, wie viele andere Rechnungen es schon gab, oder was die 
vorherige Rechnungsnummer war. "Hey, ich würde gerne meine Bestellungen 
100, 99, 98, ... stornieren. Meine Kontonummer hat sich auch noch 
geändert, ist jetzt XYZ.". Es gibt auch keinen legitimen Einsatzzweck 
für lückenlose Rechnungsnummern.

von Michael B. (laberkopp)


Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Emil schrieb:
>> lückenlos
>
> Streiche diese unnötige Anforderung, dann wird alles einfacher.

Leider gesetzliche Forderung.

Rechnungen müssen lückenlos numeriert sein (nicht unbedingt numerisch 
aufsteigend, auch MD5 hashes von aufsteigenden Nummern wären ok).

Oder es muss ein Storno zu einer nicht mehr verwendeten Rechnungsnummer 
mit Grund vorliegen.

von Emil (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Habe vom Hoster erfahren, dass es MariaDB ist und nicht MySQL. Das 
Problem existiert aber bei beiden:
http://codership.blogspot.com/2009/02/managing-auto-increments-with-multi.html

Daher die Frage: Wie macht man es richtig?

von Emil (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Michael B. schrieb:
> Rechnungen müssen lückenlos numeriert sein (nicht unbedingt numerisch
> aufsteigend, auch MD5 hashes von aufsteigenden Nummern wären ok).

"Rechnungsnummern müssen nicht aufeinanderfolgend, aber einmalig sein."
https://www.rechnungswesen-info.de/rechnungen_rechnungsnummer.html

"Fortlaufende Rechnungsnummer? Eine einmalig vergebene Nummer genügt!"
https://www.akademie.de/wissen/fortlaufende-rechnungsnummer

von Achim H. (anymouse)


Bewertung
0 lesenswert
nicht lesenswert
SQuirreL schrieb:
> INSERT INTO rechnungen
> SET name='Berta Fisch',
>     betrag=23,
>     rechnungs_nr = (SELECT IFNULL( MAX( rechnungs_nr ) , 0 ) + 1 FROM
> rechnungen r))

Wird auf MySQL (und MariaDB) nicht funktionieren:

"The target table of the INSERT statement may appear in the FROM clause 
of the SELECT part of the query. However, you cannot insert into a table 
and select from the same table in a subquery."

Ich fürchte, um 2 Queries und einigem Aufwand zur Fehlerverarbeitung bei 
parallelen Inserts wird man nicht herumkommen.


Das Problem ist aber auch nicht trivial.

von Emil (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ok, aber angenommen, es sollte trotzdem lückenlos sein. Es ist schwer, 
im Netz eine Lösung zu finden, da überall der Quatsch mit AUTO_INCREMENT 
behauptet wird.

von Software (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:
> Bernd K. schrieb:
>> Emil schrieb:
>>> lückenlos
>>
>> Streiche diese unnötige Anforderung, dann wird alles einfacher.
>
> Leider gesetzliche Forderung.

Stumpfsinn, wie AK schon gepostet hat, noch zusätzlich:

https://www.haufe.de/finance/buchfuehrung-kontierung/fortlaufende-nummerierung-von-rechnungen-ausnahmen_186_387400.html

Und bei den hier diskutierten Lösungen rollen sich einem die Zehennägel 
auf. Businesslogik an technische Spezifika der eingesetzten DB zu 
koppeln, brrr.
Rechnungsnummer mit AUTOINCREMENT, hoffentlich ist das nur Übung und 
nicht produktiv.

von Software (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Emil schrieb:
> Ok, aber angenommen, es sollte trotzdem lückenlos sein. Es ist
> schwer,
> im Netz eine Lösung zu finden, da überall der Quatsch mit AUTO_INCREMENT
> behauptet wird.

Das ist Applikationslogik, das muss deine Applikation lösen:
- "Fortlaufend"-Logik, Nummernschema
- Prüfung was nach dieser logik das letzte gespeicherte Maximum ist, 
Bestimmung der Nachfolge

und dabei Randbedingungen betrachten wie:

- Nebenläufigkeit
- Transaktionssicherheit etcpp.

Und für die Punkte jeweils entscheiden, wo im Applikationsstack man das 
unterbringt.

von Michael B. (laberkopp)


Bewertung
0 lesenswert
nicht lesenswert
Software schrieb:
> Stumpfsinn, wie AK schon gepostet hat

Ein Trottel kommt halt selten alleine.

Dein Artikel schreibst selbst 'fortlaufende Numerierung'.

Das Finanzamt möchte wissen, ob du eine Rechnung kassiert aber nicht 
verbucht hast.

Das muss aus der Numerierung hervor gehen.

Es muss also erkennbar sein, wenn eine Rechnung (im laufenden Jahr) 
fehlt.

Die Numerierung muss aber nich so sein, daß auch ein Kunde erkennt wie 
viele Geschäfte du schon gemacht hast, sie kann also verwürfelt sein. 
Hauptsache das Finanzamt erfährt, die der Fortlauf ist.

Und nein, eine Transaktions-Rollback ist kein Rechnersystemabsturz der 
als Ausnahme (wenn man ihn dokumentiert) erlaubt wäre "am 25.11. hatten 
wir einen Aussetzer, die letzte vergebene Rechnugsnummer war 456, die 
nächste 500"

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:
> Ein Trottel kommt halt selten alleine.
>
> Dein Artikel schreibst selbst 'fortlaufende Numerierung'.

Hast Du überhaupt gelesen was A.K. verlinkt hat:

"Eine lückenlose Abfolge der ausgestellten Rechnungsnummern ist nicht 
zwingend." - Umsatzsteueranwendungserlass 2010

Damit ist alles gesagt. Der Gersetzgeber war im ersten Anlauf zu dumm 
(wie üblich) um präzise zu formulieren, er hat "eindeutig" gemeint und 
"fortlaufend" geschrieben, was soll man sonst auch von ansonsten 
arbeitslosen Anwälten erwarten die in die Politik gingen weil sie zu 
dumm waren eine andere brötchengebende Beschäftigung zu finden.

In diesem Erlass wurde dieser schwachsinnige Schreibfehler dann 
offensichtlich korrigiert und richtiggestellt. Friede, Freude, 
Eierkuchen.

: Bearbeitet durch User
von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Der Gersetzgeber war im ersten Anlauf zu *dumm*
> (wie üblich) um präzise zu formulieren,

Sachte. Das Umsatzsteuergesetz ist älter als die elektronische 
Rechnungsverarbeitung. Damals waren sequentielle Nummernkreise für das 
FA sicherlich praktischer. Vielleicht stand das ja sogar schon in der 
ersten Fassung von 1918 so drin.

: Bearbeitet durch User
von Tom Müller (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Krass. Ich bin auch immer davon ausgegangen, dass AUTO_INCREMENT immer 
nur um 1 erhöht wird. Wieder etwas gelernt.

von Bill G. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tom Müller schrieb:
> Krass. Ich bin auch immer davon ausgegangen, dass AUTO_INCREMENT immer
> nur um 1 erhöht wird. Wieder etwas gelernt.

Das ist konfigurierbar, man kann beliebige Schrittweiten konfigurieren. 
Dass der aktuelle Wert bei einem Rollback nicht zurückgesetzt wird wurde 
ja schon angesprochen. Oft holt sich der SQL-Server auch gleich einen 
ganzen Block. Hatte den Fall mal bei einem Kunden, wo deshalb nach jedem 
Serverneustart eine Lücke von rund 1000 war.

Hinzu kommt, dass man fortlaufende Rechnungsnummern ja auch gerne 
gemeinsam mit dem Jahr sieht. Also beim Jahreswechsel wird wieder mit 1 
begonnen. Da ist's dann sowieso Essig mit der Identity.

von MaWin (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Damit ist alles gesagt. Der Gersetzgeber war im ersten Anlauf zu dumm
> (wie üblich) um präzise zu formulieren, er hat "eindeutig" gemeint und
> "fortlaufend" geschrieben,

Nur die Bürger sind halt immer noch dümmer.

Es geht nicht um eindeutig, sondern darum dass das FA Lücken erkennen 
kann.

Das wird nicht erreicht wenn man Nummern in wahlfrei wechselndem Abstand 
vergibt.

Man dürfte aber z.B. Stellen vertauschen

0010
0020
0030
  :
0090
0001
0011
  :
0091
0002

wenn dem FA diese Methode darlegt.
Oder eben 2 Nummernkreise haben
A01, E01, E02, E03, A02, A03, E04, A04...

Aber das wird Brrnd nie verstehen.

von Jemand (Gast)


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Es geht nicht um eindeutig, sondern darum dass das FA Lücken erkennen
> kann.
>
> Das wird nicht erreicht wenn man Nummern in wahlfrei wechselndem Abstand
> vergibt.
>
> Man dürfte aber z.B. Stellen vertauschen

Wenn eine intern fortlaufende Nummer mit einem Block-Cipher 
verschlüssele und Base32 o. Ä. kodiere und so meine Rechnungs- oder 
Seriennummern erhalte, kann man nun wirklich nicht von wahlfrei reden, 
ich bezweifle aber, dass die damit klarkommen würden ;p

von 1+1=3 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit einer Referenztabelle wo man immer ein bestimmtes 
Kontingent an aufsteigenden Nummern vorhält. Die Nummern werden dabei 
natürlich nicht mit auto_increment erzeugt. In der Rechnungstabelle lege 
ich dann einen Fremdschlüssel auf diese Tabelle. Vielleicht vergleichbar 
mit einer Lookup-Tabelle.


Das Argument „braucht es doch nicht, weil…“ merk ich mir. Wenn mein Chef 
wieder auf der Matte steht, probiere ich mal, ob ich damit durchkomme. 
Ob das Problem real ist oder nicht, spielt doch eigentlich für die 
Problemlösung keine Rolle. Viele von uns werden doch mit so etwas jeden 
Tag gequält. Ob es Sinn macht oder nicht, spielt dabei meist keine 
Rolle.

Grüße...

von Emil (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich finde krass, dass das Internet(R) eigentlich flächendeckend 
behauptet, man solle in dem Fall AUTO_INCREMENT verwenden. xD

Meine Lösung sieht jetzt so aus (aus dem Kopf grob umrissen):

lock tables rechnungen write
select max(rechnungsnummer) as max_rechnungsnummer from rechnungen

Überprüfen, ob ein Wert zurückgeliefert wurde, dann um 1 erhöhen etc.

insert into rechnungen set rechnungsnummer=[...alle Daten...]
unlock tables

Nicht schön und ggf. langsam, was mich aber nicht stört. Dass die DB das 
nicht von sich aus mit einer fertigen Operation kann, ist allerdings ein 
Armutszeugnis.

von Aufpasser (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Software schrieb:
> Stumpfsinn, wie AK schon gepostet hat, noch zusätzlich:
>
> 
https://www.haufe.de/finance/buchfuehrung-kontierung/fortlaufende-nummerierung-von-rechnungen-ausnahmen_186_387400.html

Schon komisch, Finanzgerichte und die Oberfinanzdirektion Koblenz sehen 
das ganz anders...

Vielleicht ist der "Haufe Verlag" keine verlässliche Quelle für die 
rechtliche Bewertungen von Vorschriften?


Davon abgesehen, ist es durchaus kritisch zu sehen, die Geschäftslogik 
der Rechnungsnummern einem Implementierungsdetail der Datenbank 
anzuvertrauen...

von Ergo70 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
“Dass die DB das nicht von sich aus mit einer fertigen Operation kann, 
ist allerdings ein Armutszeugnis.“

Nein. Sondern Zeugnis dessen, dass die Designer dieser Systeme sich 
etwas dabei gedacht haben. Spiel das doch einfach mal z.B. für drei 
parallele Transaktionen durch, von denen die erste und dritte nicht 
COMMITen. Und jetzt?

von Emil (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gäbe es eine Funktion, die lückenlose IDs ermöglichte, ginge das eben 
nicht parallel. Wie das im Hintergrund funktioniert, ist doch für den 
Endbenutzer völlig latte. Das ist wie, wenn man z.B. die Funktion AVG() 
oder so weglassen würde. Könnte man machen, aber es ist inconvenient. 
Und eine fehlende Funktion wie die o.g. ist es eben auch.
Dass das ein reales Problem ist, zeigt doch schon die erste Antwort. Die 
allermeisten Leute gehen davon aus, dass es mit AUTO_INCREMENT ginge!

von ergo70 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
"Gäbe es eine Funktion, die lückenlose IDs ermöglichte, ginge das eben
nicht parallel."

Genau. Und das will niemand in einem skalierbaren Datenbankserver haben.

Ziele sind Zuverlässigkeit, Skalierbarkeit und ein stabiles 
transaktionales Verhalten, aber nicht jede denkbare Geschäftslogik a 
priori zu implementieren. Im Licht der Skalierbarkeit sind Locks ein 
manchmal leider notwendiges Übel, das es zu minimieren gilt. Mal 
abgesehen davon, dass eine solche Funktion auch nicht gut mit caching 
zusammenspielt.

Auto increment, Sequences etc. erfüllen die schwache Uhrenbedingung und 
das reicht. Geschäftslogik kann man dann oben draufsetzen, wenn man sie 
halt unbedingt braucht. Das Leute davon ausgehen, das AUTO INCREMENT 
lückenlos monoton hochzählt ist nicht das Problem der Datenbank, sondern 
vielleicht der Dokumentation, oder der Leute die sie nicht lesen.

Hier mal das Beispiel von PostgreSQL:

"Sequences are based on bigint arithmetic, so the range cannot exceed 
the range of an eight-byte integer (-9223372036854775808 to 
9223372036854775807).

Because nextval and setval calls are never rolled back, sequence objects 
cannot be used if “gapless” assignment of sequence numbers is needed. It 
is possible to build gapless assignment by using exclusive locking of a 
table containing a counter; but this solution is much more expensive 
than sequence objects, especially if many transactions need sequence 
numbers concurrently.

Unexpected results might be obtained if a cache setting greater than one 
is used for a sequence object that will be used concurrently by multiple 
sessions. Each session will allocate and cache successive sequence 
values during one access to the sequence object and increase the 
sequence object's last_value accordingly. Then, the next cache-1 uses of 
nextval within that session simply return the preallocated values 
without touching the sequence object. So, any numbers allocated but not 
used within a session will be lost when that session ends, resulting in 
“holes” in the sequence.

Furthermore, although multiple sessions are guaranteed to allocate 
distinct sequence values, the values might be generated out of sequence 
when all the sessions are considered. For example, with a cache setting 
of 10, session A might reserve values 1..10 and return nextval=1, then 
session B might reserve values 11..20 and return nextval=11 before 
session A has generated nextval=2. Thus, with a cache setting of one it 
is safe to assume that nextval values are generated sequentially; with a 
cache setting greater than one you should only assume that the nextval 
values are all distinct, not that they are generated purely 
sequentially. Also, last_value will reflect the latest value reserved by 
any session, whether or not it has yet been returned by nextval.

Another consideration is that a setval executed on such a sequence will 
not be noticed by other sessions until they have used up any 
preallocated values they have cached."

Da steht nicht nur, WIE sich eine Sequence verhält, sondern sogar WARUM.

von ergo70 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich korrigiere mich: Sogar die schwache Uhrenbedingung wird nur ohne 
caching erfüllt.

von sid (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:
> Das Finanzamt möchte wissen, ob du eine Rechnung kassiert aber nicht
> verbucht hast.
>
> Das muss aus der Numerierung hervor gehen.

Das stimmt..
aber das heisst nicht, dass sie fortlaufend sein müssen!
Ich zähl zB immer jahr monat lfdnr.. das macht das manuelle auffinden 
leichter...
Rechnungsnummer kann auch 201911004 sein
und dann in dreierschritten zählen wenn Du lustig bist,
Du musst es nur darlegen dem FA ggü.

Und falls mal eine Nummer wegbricht wird die nummer eben als storniert 
markiert und die NULL Rechnung bleibt im System... auch kein Akt.

Und ja, es ist ein Problem wenn dutzende Clients auf derselben Datenbank 
rumhacken,
dann kann es (mangels table lock) zu fehlern beim insert kommen,
falls zwei inserts denselben unique content haben
man kann aber die Werte ins error log schreiben;
falls das FA meckert.. hat man das errorlog und kann damit die fehlenden 
Nummern dokumentieren (inkl Zeitstempel)

Im Grunde aber.. bei sauberem SQL Aufrufen bleibt's dabei
AutoIncrement ist 100% zuverlässig
sonst würden die wenigsten Webseiten überhaupt funktionieren.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Emil schrieb:

> Nicht schön und ggf. langsam, was mich aber nicht stört. Dass die DB das
> nicht von sich aus mit einer fertigen Operation kann, ist allerdings ein
> Armutszeugnis.

Nein.

Die Autoincrement-Implementierung praktisch aller erwähnenswerten 
Datenbanken hat prinzipiell exakt dasselbe Verhalten. Konkurrierende 
Zugriffe können dazu führen, dass Lücken entstehen.

Und wenn die Entwickler aller erwähnenswerten Datenbanken zu dem 
Ergebnis gekommen sind, dass das die sinnvollste Implementierung ist, 
dann gibt es hier nur einen, der sich ein Armutszeugnis ausstellen 
lassen muss. Der, der nicht begreift, warum das so sein muss und warum 
das überaus sinnvoll ist...

von Bill G. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Emil schrieb:
> Ich finde krass, dass das Internet(R) eigentlich flächendeckend
> behauptet, man solle in dem Fall AUTO_INCREMENT verwenden. xD

Dem ist nicht so, du hast dein Problem wohl vereinfacht formuliert und 
dafür eine einfachere Lösung präsentiert bekommen.

> Meine Lösung sieht jetzt so aus (aus dem Kopf grob umrissen):
>
> [...]
>
> Nicht schön und ggf. langsam, was mich aber nicht stört. Dass die DB das
> nicht von sich aus mit einer fertigen Operation kann, ist allerdings ein
> Armutszeugnis.

Also die Quick'n'dirty Variante.

Relationale Datenbanken sind eben primär für die Arbeit auf Datenmengen 
gedacht, nicht zur Abbildung von Geschäftslogik. Daher ist es schon in 
Ordnung, dass diese Funktionalität nicht auf der Ebene verfügbar ist, 
auch wenn das auf den ersten Blick komisch erscheint.

sid schrieb:
> Im Grunde aber.. bei sauberem SQL Aufrufen bleibt's dabei
> AutoIncrement ist 100% zuverlässig
> sonst würden die wenigsten Webseiten überhaupt funktionieren.

Auto Increment macht zuverlässig das, wofür es gedacht ist. Lückenlose 
Nummernvergabe aber nicht, selbst bei "sauberem SQL". Die wenigsten 
Webseiten benötigen das.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.