Mailinglisten-Archive |
Hallo Dirk >> Gute Frage ;). Also ich denke die Datenbank wird im Wesentlichen aus einem >> Table mit den Artikeln, einem Table mit Geboten und einem Table mit den >> Userdaten bestehen. Parallel auszuführende Update auf einer Row wird es wohl >> kaum geben. Die Datensätze werden einmal eigefügt und gut. >Das ist doch umständlich, oder? Es geht doch immer um das höchste Gebot. >Dann müßtest du aus den ganzen Einträgen immer das höchste für den >jeweiligen Artikel suchen. Ein Update wäre da doch besser. Dies könnte >dann in der Artikelltabelle mitgeführt werden und somit hätte mensch nur >zwei Tabellen. Wir hätten aber gerne eine History. Ansonsten wäre das sicherlich der einfachere Weg ;) >> btw: was macht autoincrement eigentlich wenn die ID größer werden würden als >> der Bereich des ZellenTyps? Sucht es dann von vorne an nach freien IDs? Wohl >> kaum oder? >Autoincrement verwendet immer die höchste ID + 1. Wenn du also die >letzten Einträge entfernst wird die Berechnung auf dem Höchsten der >verbleibenden IDs aufsetzen. Hm, das Problem ist ja, daß ich aus der Artikeltabelle eben nicht die letzten Artikel entferne, sondern die ersten, weil die halt als erstes weg sind. Dh die höchste ID ist mit ziemlich Sicherheit auch die, die als letztes entfernt wird. Mit BigINT als id wäre ich wohl auf der sicheren Seite, aber glücklich finde ich das immer nocht nicht ;). Ansonsten müßte ich wohl meine IDs selber generieren und - wenn ich das richtig sehe - dabei mit table-locking arbeiten. Irgendeine Ahnung was mehr Sinn macht? Schöne Grüße Christoph
php::bar PHP Wiki - Listenarchive