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