phpbar.de logo

Mailinglisten-Archive

Re: Neuer Listen-Index
Archiv Mailingliste mysql-de

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Neuer Listen-Index



-----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-----


Home | Main Index | Thread Index

php::bar PHP Wiki   -   Listenarchive