sql - problem mit auto_increment - Seite 2

kikakater · 24.08.2002, 22:16

Mit Autoincrement hat man eben ein "Unheil" im Lauf, deshalb darf es eben nicht so laufen, wie es für Dich angenehm wäre.

Ein manuell versorgtes Feld ist da das einzige Mittel zum Zweck.

RaistlinMajere · 24.08.2002, 22:21

sowas hab ich eh schon für diesen zweck geschrieben, nur habe ich mich diesmal gefragt, ob ich mir das nicht einfacher hätte machen können. offensichtlich nicht.

käptn · 25.08.2002, 00:59

Zitat:

Original geschrieben von MrWolf
blöde frage:
wo gibts denn das mysql-manual in einer deutschen version. die englische stört zwar nicht, aber auf deutsch ists trotzdem bequemer.

lg

Speziell zu diesem Thema:
http://www.mysql.de/documentation/my...ml#Table_types

HTH

James · 31.08.2002, 02:55

frage wo is das problem die id kann einem doch egal sein wenn ich das ganze ausgeb weiss ich doch ob es die X zeile is egal welche id ich hab

RaistlinMajere · 31.08.2002, 03:10

Zitat:

Original geschrieben von James
frage wo is das problem die id kann einem doch egal sein wenn ich das ganze ausgeb weiss ich doch ob es die X zeile is egal welche id ich hab

verstehe ich dich richtig und hinterfragst du denn sinn einer id-vergabe?

mcs_ · 31.08.2002, 09:53

Zitat:

Original geschrieben von James
frage wo is das problem die id kann einem doch egal sein wenn ich das ganze ausgeb weiss ich doch ob es die X zeile is egal welche id ich hab

hm, die id ist ja dazu da, um einen datensatz eindeutig zu identifizieren. an ihr hängt sozusagen der rest, über sie kannst du zumeist überhaupt erst an die daten ran. kurz gesagt, die id ist wichtig.

bild ich mir halt ein ...

RaistlinMajere · 31.08.2002, 12:52

Zitat:

Original geschrieben von fluffster

hm, die id ist ja dazu da, um einen datensatz eindeutig zu identifizieren. an ihr hängt sozusagen der rest, über sie kannst du zumeist überhaupt erst an die daten ran. kurz gesagt, die id ist wichtig.

bild ich mir halt ein ...

nicht für alle anwendungen, aber für sehr viele auf jeden fall.

käptn · 31.08.2002, 13:09

Ohne eindeutiger Identifikationsmöglichkeit von Datensätzen ist das Ausgeben aller Daten zu einem Foreign-Key kein Problem.
Spätestens beim Löschen - noch viel mehr beim Ändern - von Daten stößt du auf ein wesentliches Problem - der eindeutigen Identifikation der zu ändernden/löschenden Daten.

~

pc.net · 31.08.2002, 13:22

Zitat:

Original geschrieben von RaistlinMajere
verstehe ich dich richtig und hinterfragst du denn sinn einer id-vergabe?

ich glaube, james hinterfragt nicht den sinn der id, sondern den sinn einer unbedingt durchgehenden durchzählung ...

mir persönlich is es auch egal, ob bei den id's eine lücke entstanden ist, weil ein (oder mehrere) datensätze gelöscht wurden ...

bei immensen datenmengen is es doch egal, ob auf den datensatz mit der id 68456315656431, der datensatz mit der id 68456315656438 folgt ... hauptsache, es sind die richtigen daten vorhanden! weiters kann man so (auch ohne zusätzliches journaling) feststellen, ob gelöscht wurde oder nicht ...

kikakater · 31.08.2002, 17:45

Nein, nicht durchgängige Nummern - infolge einiger wieder gelöschter Datensätze - zu verwenden ist schlichtweg Pflicht. Besser noch als IDs sind Timestamps als ID in genügend großer Auflösung, z.B. einer Millisekunde. Damit habe ich den Zeitpunkt der Anlage (Creation Date) und eine eindeutige Nummer. Falls eine fortlaufende Nummer vonnöten ist, kann man diese zusätzlich oder statt dessen verwenden.

24.08.2002, 22:21	#12
RaistlinMajere Inventar Registriert seit: 06.04.2001 Alter: 45 Beiträge: 2.343	sowas hab ich eh schon für diesen zweck geschrieben, nur habe ich mich diesmal gefragt, ob ich mir das nicht einfacher hätte machen können. offensichtlich nicht. ____________________________________ "Life is like a box of rockets," said the Marine. "You never know what you´re gonna ret." Then he pulled the trigger of his BFG9000.

31.08.2002, 02:55	#14
James Meisteroptiker Registriert seit: 19.05.2000 Ort: Salzburg Alter: 44 Beiträge: 1.495	frage wo is das problem die id kann einem doch egal sein wenn ich das ganze ausgeb weiss ich doch ob es die X zeile is egal welche id ich hab ____________________________________ ©Sliver Productions http://www.sol.at/past/ http://www.lunchgen.com http://optik.dyns.cx http://sliver.hypermart.net/script/

31.08.2002, 13:09	#18
käptn Inventar Registriert seit: 04.11.2001 Alter: 45 Beiträge: 2.150	Ohne eindeutiger Identifikationsmöglichkeit von Datensätzen ist das Ausgeben aller Daten zu einem Foreign-Key kein Problem. Spätestens beim Löschen - noch viel mehr beim Ändern - von Daten stößt du auf ein wesentliches Problem - der eindeutigen Identifikation der zu ändernden/löschenden Daten. ~ ____________________________________ LOL - Mein erstes Post im Programmier Forum MACINTOSH - Most Applications Crash, If Not The Operating System Hangs

24.08.2002, 22:16	#11
kikakater Inventar Registriert seit: 24.01.2001 Beiträge: 5.631	Mit Autoincrement hat man eben ein "Unheil" im Lauf, deshalb darf es eben nicht so laufen, wie es für Dich angenehm wäre. Ein manuell versorgtes Feld ist da das einzige Mittel zum Zweck.

31.08.2002, 17:45	#20
kikakater Inventar Registriert seit: 24.01.2001 Beiträge: 5.631	Nein, nicht durchgängige Nummern - infolge einiger wieder gelöschter Datensätze - zu verwenden ist schlichtweg Pflicht. Besser noch als IDs sind Timestamps als ID in genügend großer Auflösung, z.B. einer Millisekunde. Damit habe ich den Zeitpunkt der Anlage (Creation Date) und eine eindeutige Nummer. Falls eine fortlaufende Nummer vonnöten ist, kann man diese zusätzlich oder statt dessen verwenden.

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)