MySQL: Autoimcrement ohne Key?
Mario Steinko
- webserver
0 Mario Steinko0 Mario Steinko0 ChrisB
Hi!
Ich hatte jetzt endlich Zeit mir mal den alten Post über das Thema anzuschaun, vor allem Toms Vorschlag.
Ich dachte damals das das bereits eine Lösung wäre, musste jetzt aber leider feststellen, dass es nicht so ist.
@Tom: Bei deiner Lösung kann es immer noch passieren das zwei Einträge zur selben Zeit passieren und dann 2 messages die gleiche id_populate haben :-/
Wie kann ich sowas denn verhindern?
thx
Mario
Sry, ich hab "falsch herum" gedacht, ich dachte erst das die populate_id die ID sein soll, die angezeigt wird, es wird aber die Message_id angezeigt und die populate_id is die vorlaufende AutoIncr ID, alles klar, ich werd mich mal dran machen die Stored Procedures zu schreiben....
thx
Mario
Mist, es funktioniert leider doch nicht:
In der Original-messages Tabelle:
messages:
message_id INT(11) Autoincr.
blog_id INT(5)
...
PRIMARY KEY: message_id & blog_id
@Tom:
Hier wird die message_id aber auch nicht richtig durchnummeriert!
Die message_id wird nicht abhängig von der blog_id erhöht, sondern immer
einfach um eins erhöht, wobei ich dann wieder nicht den gewünschten Effekt aheb :-/
lg
Mario
Hi,
message_id INT(11) Autoincr.
blog_id INT(5)
...
PRIMARY KEY: message_id & blog_idHier wird die message_id aber auch nicht richtig durchnummeriert!
Und wenn du die message_id im Key mal nach hinten stellst?
MfG ChrisB
Wenn ich das ganze so erstell:
CREATE TABLE 'messages' (
`blog_id` INTEGER(5) UNSIGNED NOT NULL,
`message_id` INTEGER(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`other_data` VARCHAR(45) NOT NULL,
PRIMARY KEY (`blog_id`, `message_id`)
)
ENGINE = InnoDB;
dann erhalte ich als Rückmeldung:
Incorrect table definition; there can be only one auto column and it must be defined as key, mit der ordnung andersherum funktioniert das erstellen, aber die Nummern sind dann halt primitiv fortlaufend, was falsch is...
thx
Mario
Hi,
Wenn ich das ganze so erstell:
[...]
ENGINE = InnoDB;
... dann hast du die falsche Enginge gewählt, denn das, was ich dir im anderen Thread aus dem Manual zitiert hatte, ist eindeutig:
"For MyISAM tables you can specify AUTO_INCREMENT on a secondary column in a multiple-column index"
MfG ChrisB
Stimmt, mit MyISAM funktionierts, ich wollte eigentlich die InnoDB verwenden weil es foreign keys ermöglicht....
Wie stable sind denn Stored Procedures, ich hab schon einiges negatives drüber gehört, dann ich davon ausgehn das da wirklich keine Daten verloren gehen oder is es besser das ganze mit PHP Queries zu lösen?
lg
Mario
Spricht eigentlich irgendwas dagegen das Design genau umzudrehen?
messages mit InnoDB (wegen foreign keys):
id INTEGER autoincr., Primary Key
blog_id INT(5)
andere daten....
messages_displayed_ids als MyISAM
messages_id INTEGER
blog_id INT(5)
displayed_id INT(11) autoincr.
Primary Key (blod_id, displayed_id);
INDEX (messages_id)
Dann hätt ich für die größere Tabelle die foreign keys, bei der kleineren is die Datenmenge mit 3 Integer eh sehr gering, außerdem könnt ich das ganze dann in meinem Framework in die afterRead() reinprogrammieren anstatt mit Stored Procedures herumzubasteln, die angeblich nicht immmer ganz zuverlässig sein...
Was meint Ihr?
lg
Mario