Mailinglisten-Archive |
> Zeitlich und raeumlich eindeutige Schluessel werden haeufig benoetigt.
Was meinst Du mit "zeitlich" und "räumlich"?
> Dummerweise hat mysql dort zwei Einschraenkungen:
> - - wird ein Satz eingefuegt, geloescht und wieder einer eingefuegt, bekommt
> dieser den Schluesselwert des vorig geloeschten Schluessel. :-( Das heisst, alle
Der neue Schlüssel ist max() der Schlüsselspalte plus 1, Du suchst also
nicht dieerste freie Lücke, sondern den größten Wert, was über den
(AFAIK für auto_increments notwendigen) PRIMARY KEY sehr einfach ist. (
Wenn man probehalber einn Satz anlegt, löscht und einen neuen generiert,
sieht das Verhalten wie beschrieben aus ;-) )
> Referenzen auf den alten geloeschten Satz zeigen jetzt auf den neuen :-(. Diese
> Referenzen lassen sich beim Loeschen nicht implizit mitentfernen, da mysql
> keine Fremdschluesselbeziehungen kennt :-(
Genauer, MySQL biete keine relationale Integrität mit DELETE_CASCADE.
Die mußt Du selber garantieren, und wenn Du es zuläßt (bei bekannter
Einschränkung), daß nach dem Löschen Referenzen auf nicht mehr
vorhandene IDs auftauchen, die dann möglicherweise falsch referenzieren,
machst _Du_ vom MySQL-Standpunkt aus etwas falsch.
In diesem Zusammenhang ist es ja _nur gut_, daß auto_increment den
max()+1-Wert nimmt, weil wenn durch DELETES Löcher entstehen, die
möglicherweise falsch referenziert werden, die falsche Referenz nur
auftritt, wenn eine ID erneut vergeben wird, d.h. wenn Du den Datensatz
mit der höchsten ID löschst. Auf den ersten Blick sieht es so aus, als
fielen solche Loch-Refernenzen in JOINS unter den Tisch, erfreulich :-)
> Das soll bald behoben werden, der Schluessel ist dann zeitlich eindeutig, aber
Was ist "das"? Du meinst, daß IDs (pro Tabelle) nur ein einziges Mal
überhaupt vergeben werden können? Wenn ich nicht irre, war das früher
schon so, und wurde dann mal auf "max()+1" geändert, weil die Leute
Angst hatten, Ihre IDs gingen zu schnell stiften ;-) Zeitlich eindeutig
= auf alle Zeit eindeutig? Wofür ist dieses Kriterium notwendig?
> immer noch nicht raeumlich eindeuig (Wenn ein Satz migriert, z.B von der
> Tabelle der Kunden zu denen der Lieferanten, ist sowieso alles Salat :-( . )
Darf ich daraus schließen, daß Du mit "räumlich eindeutig" forderst, daß
ein bestimmter auto_increment-Wert für die ganze Datenbank eindeutig
ist, d. h. praktisch die Tabelle noch mit enthält? Die auto_increment-ID
ist gut als Primärschlüssel in einer Tabelle geeignet, und niemand
fordert von Primärschlüsseln eine datenbankweite Eindeutigkeit.
Einen Satz zu "migrieren" habe ich noch nie gehört. Du kannst höchstens
die gleichen Daten in eine strukturell gleiche, andere Tabelle
übernehmen. Dann mußt Du Dir etwas anderes als Primärschlüssel einfallen
lassen, oder den PS in einer Tabelle halt selber als ID erzeugen. (Dabei
darauf achten, daß er in der anderen Tabelle nicht vorkommt, und auch
nie vorkommen wird, also "zeitlich eindeutig" ist. - Viel Spaß! :-b)
Wenn ich das richtig sehe, daß Du mit der "Migration" von Kunden zu
Lieferanten nur einen Status erfassen willst (und die sonstigen
Attribute gleich bleiben), dann hast Du ein Designproblem, weil die
Daten dann nicht in zwei Tabellen gehören, sondern ein zusätzliches
Attribut Kunde/Lieferant brauchen.
> Naja, man kann ja nicht alles haben.
Sei mal ehrlich, wir haben hier ne Menge zu sehr guten Konditionen ;-)
Matthias
--
w e b f a c t o r y | matthias pigulla
www.webfactory.de mp_(at)_webfactory.de
php::bar PHP Wiki - Listenarchive