Mailinglisten-Archive |
Hans Theo Mislisch wrote: > > > Das wäre ja fatal. Es ist schon unangenehm genug, daß > > autoincrement-Werte, die vergeben und dann gelöscht werden, > > nochmal vergeben werden, wenn keine danach erfolgten. Das ist > > m.W. der einzige Unterschied zu anderen Datenbanken, die > > definitiv immer stramm weiterzählen. > es stimmt schon ,dass nur MySQL das macht, aber wo siehst Du > da ein Problem? Hast Du ein Beispiel wo das schwierig wird? Ja. Hatte ich schon mehrfach, wie war das nochmal? Zum Beispiel: bei uns können die Leute Anzeigen aufgeben. Die kriegen Nummern (autoincrement). Dazu können sie Bilder laden, gleich oder später. Diese Bilder kriegen auch Nummern (autoincrement). Im Datensatz wird dazu die Nummer der Anzeige vermerkt (klaro). Wenn jetzt einer eine Anzeige mit Bild hochlädt und anschließend die Anzeige löscht, kriegt der nächste dieselbe Nummer für seine Anzeige. Folglich hat seine Anzeige ein Bild, das nicht dahingehört. Das ist natürlich ein Programmier-Kunstfehler. Ich hätte vor dem Löschen der Anzeige nachschauen müssen, ob es dazu Bilder gibt, und die entsprechenden Datensätze erst löschen müssen. Kann man also reparieren. Ich habe mal mit einer Datenbank gearbeitet, da gab es etwas, das hieß wohl referentielle Integrität oder so. Da konnte man die Tabellen so definieren, daß ein Löschen gar nicht möglich war, wenn es abhängige Datensätze gab. Ob das in mySQL auch geht, weiß ich nicht. Aber damit hört es noch nicht auf. Wenn jetzt das nächste Bild geladen werden soll, kriegt dieses Bild die schon vergebene Nummer und das Upload klappt nicht, bzw. der Kopiervorgang, weil die entsprechende alte Datei noch da ist. Muß also auch gelöscht werden. Nun habe ich, als unsere Traffic-Grenze erreicht war, die Bilder als eine der ersten Maßnahmen auf eine andere Domain ausgelagert. Nun konnte ich nicht mehr schnell und bequem nachschauen, wie die Dimensionen der Bilder sind, um sauberen html-Code zu produzieren. Also habe ich die Dimensionen in die Tabelle geschrieben, da schaue ich ja sowieso nach. Klasse, soweit. Jetzt liegen die Bilder aber auf einer anderen Domain. Die kann ich gar nicht ohne weiteres löschen. Also habe ich auf das Löschen ganz verzichtet und durch "Totschreiben" ersetzt. Das ist nun typisch. Man hat etwas, das macht Probleme. Man krempelt die Ärmel auf, macht ein Workaround. Jetzt gibt es neue Probleme. Wieder Workaround. Irgendwann sagt man: wieso habe ich eigentlich diese Probleme? Völlig unnötig! War von Anfang an ein Design-Problem. So ähnlich wie strpos, wo ich nicht unterscheiden kann, ob needle nun in haystack ist oder nicht, weil die Position zurückgegeben wird und zumindest für php3 die Position 0 und falsch identisch sind. Na gut, sagt man, baue ich mir halt eine neue strpos-Funktion, die das richtig macht. Aber damit habe ich nicht die Wurzel des Problems beseitigt. Leider ist es so, daß diese Sachen unvermeidlich sind. Wenn ich etwas anfange, weiß ich nicht, wo ich landen werde. Ich habe zwar Vorstellungen, aber die müssen in der Regel korrigiert werden. Oft z.B. schon deshalb, weil der Rahmen viel zu eng gesetzt war. Ich weiß noch, wie wir gestaunt haben, als Netware 3 herauskam und Platten im TeraByte-Bereich verwalten konnte. Sowas konnte man damals hardwaremäßig noch gar nicht realisieren, eine 4 GB-Platte war schon riesig (und riesig teuer). Aber die hatten gelernt, daß es besser ist, zu hoch zu greifen als zu niedrig. Im Nachhinein kann ich vielleicht wissen, wie ich es hätte anstellen sollen, aber nun ist es zu spät, ich habe zu viel Arbeit investiert, lebe also mit meinen schrecklichen Workarounds. Und wenn ich es schaffe, neu anzufangen - fängt der ganze Zyklus mit absoluter Sicherheit wieder von vorne an. Es gibt kein Entrinnen. Man nehme es also mit Humor. -- Mit freundlichem Gruss Dr. Werner Stuerenburg _________________________________________________ ISIS Verlag, Teut 3, D-32683 Barntrup-Alverdissen Tel 0(049) 5224-997 407 · Fax 0(049) 5224-997 409 http://pferdezeitung.de http://art-quarter.com
php::bar PHP Wiki - Listenarchive