Mailinglisten-Archive |
-----BEGIN PGP SIGNED MESSAGE----- On Sat, 10 Apr 1999, Matthias Pigulla wrote: >> Zeitlich und raeumlich eindeutige Schluessel werden haeufig benoetigt. >Was meinst Du mit "zeitlich" und "räumlich"? Ein Schluessel darf nur einmal in einer Datenbank vergeben werden. > >> 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 ;-) ) Nee, nicht nur probehalber; prinzipiell wenn ich einen Satz loesche und er zufaelligerweise der letzte gewesen ist. >> 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. Ja, mysql verzichtet auf vieles und ist damit schnell, robust und ressourcenschonend. Ich hoffe nur, das die vielen Benutzer dieses DBS dieses o.g. Wissen haben. >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 ;-) Das Problem loest man genau wie Y2k: 64 bit. >Zeitlich eindeutig >= auf alle Zeit eindeutig? Wofür ist dieses Kriterium notwendig? siehe oben (DELETE_CASCADE). >> 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. > Sicherlich wuerde ich Lieferanten/Kunden nicht so modellieren, ich habe es doch nur als einfaches Beispiel verwendet. In der oo-Welt wird Migration aber haeufig verwendet; ich benoetige das z.B. um CAD-Daten, Modellierungsdaten, Simulations- und Animationsdaten in einem DBS zu beschreiben und zu aendern, damit diese Informationsgewinnung allen Werkzeugen zur Verfuegung stehen. oli. - ----------------------------------------------------------------------- Oliver Artelt Jordanstr.7, 39112 Magdeburg mailto:oli_(at)_cubeoffice.de Tel: 0391-6112827 Fax: 0391-604243 - ----------------------------------------------------------------------- http://www.transnet.de ISP: Wir schaffen Verbindungen! http://www.magdeburg-online.de Die Magdeburger Online-Information - ----------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNxIXSP5e/rfn+ii1AQGGgQP/erqOZ3qVUrH8fPb7P9PxP/bFyyJG9Yu1 Dfe+OrB3ejsmmOq5SPiYyCuYK6wydViuE1Rwx4Kldt/DXiWEDjPjJ70/aNDZ/DbT 3GBjeZ3FoAVFD4olp/E97oyXdf0TfQsZ27aTDNPQYMPsM/s91BglOn7YsjZTqij9 AYYB9il9MGc= =VERK -----END PGP SIGNATURE-----
php::bar PHP Wiki - Listenarchive