anpera.net

Hier mal eine Frage an die wirklich eingefleischten Coder:

Ich spielte kürzlich mit dem Gedanken, Foreign Keys in der Datenbank zu verwenden, als mit auffiel, das MyISAM diese ja gar nicht beherscht und man dazu auf InnoDB oder BerkleyDB umstellen müsste. Da Berkley mir aber zu ungewohnt vorkam, fiel meine Wahl zunächst auf InnoDB - nun die Frage: Geht das überhaupt oder würden da Probleme beim Betrieb von LotgD auftreten oder starke Leistungseinbrüche folgen etc.

Schon mal Danke im vorraus.

Auric

_________________
Mehr oder minder inaktiv

Es sollte prinzipiell gehen. Nur ist die frage ob dann wirklich alles geht... und da bleibt immernoch die umstellung ... ein fehler... und verloren hat man.

_________________
R.I.P.
†26.7.2004 - 20.3.2006†
†MeteorA†

100% ôo
Das kann soviel ich weiß Mysql garnet
Dazu müsste man auf zb. Firebird umsteigen

??? Was meinst du damit? InnoDB Tabellen verwalten kann MySQL auf jeden fall...

Und was hat dasmit firebird zu tun (Ist doch eigentlich ein Browser...)?

_________________
Mehr oder minder inaktiv

Das war auf Kevz Post bezogen

Sry, aber ich kapier's auch gerade nicht Oo
100% -> nicht MySQL -> aber Firebird ...

_________________
Legends of Imperencia ist mit folgenden Servern befreundet: Silienta, Pandyria, Kokoto

Tut mir Leid, hab auch noch Schule

[quote=Kevz]weil man gerade dort schutz gegen Transfer Fehler hat! [/quote]
100%?
Soviel ich weiß kann das nur Firebird, eine ebenfalls kostenlose Datenbank

Selbstverständlich kann man das zu 100% garantieren, aber das bremst die ganze Geschichte ziemlich aus.

_________________
A bus station is where busses stop. A train station is where trains stop. On my desk there is a workstation...

Entweder setzt man manuell zu Beginn des Scripts ein LOCK auf den eigenen User-Datensatz und entfernt ihn am Ende wieder, oder man verwendet eine Datenbank, die sowas selbständig kann.
Ich weiß allerdings nicht, ob bei MyISAM LOCKs nur auf einen Datensatz möglich sind.
Problem ist nur, daß es eben die Datenbank extrem ausbremst, weil alle munter warten und auch die Gefahr besteht, daß zwei Accounts sich gegenseitig blockieren. Die Alternative eines kompletten Tabellen-LOCKs würde dagegen absichern, würde das Ganze aber entgültig unspielbar langsam machen.

_________________
A bus station is where busses stop. A train station is where trains stop. On my desk there is a workstation...

Die alternative lautet also:
Firebird
Man kann den Transaktionsbug in LOGD auch schon ziemlich einschränken, indem man die Updates bissl modifiziert *g*..
Aber wie ich das meine werdet ihr in anperas version 4 sehen

Hm.. also meine Accounts un die mysteriöse neue Tabelle laufen nun als InnoDB. Nur bleibt ein problem: Ich bekomme keinen Foreign Key zustande..

Kennt sich jemand aus? Ich hab den Syntakx auf meinem Buch verwendet und als fehler kamm imer nur: "could nor create Table (errorno: 150)", selbst wenns per ALTER TABLE nacheingefügt oder gleich im CREATE befehl drin war. Der restliche Query war fehlerfrei und selbst beim foreigen key hab ich eigentlich keine Fehler gemacht...

Beide Tabellen sind also vom Transaktionfähigen typ InnoDB...also wenn jemand weis, woran das liegt: bitte melden!

Auric

PS: Performancetechnisch läuft alles bestens, bin sehr zufrieden mit der Tabelle!

_________________
Mehr oder minder inaktiv

Ungetestet:

ALTER TABLE accounts ADD FOREIGN KEY ( `key` ) REFERENCES `fkeytable` ( `fkey` ) ON DELETE CASCADE ON UPDATE CASCADE;

wichtig: beide tabellen müssen Type InnoDB sein!


zu deinem Fehler:

_________________
R.I.P.
†26.7.2004 - 20.3.2006†
†MeteorA†

nope.. funzt nicht.. muss wohl an den Rechten oder so liegen

Hm.. ich wollte es eigentlich anders herum, sodass eine Andere tabelle einen Foreign Key trät, also ein Feld daraus nur einen bereits bestehenden Wert aus der acctid-Spalter der accounts annehmen kann. Da müsste man den Syntax doch dann umdrehen, oder?


Trotzdem Danke, aber ich habs mittlerweile über php gelöst.
Auric

_________________
Mehr oder minder inaktiv

ok, ich bin weiter gekommen, jetzt hilft nichtmal mehr das mysql dev weiter:

$this->bbcode_second_pass_code('', '
ALTER TABLE `accounts` ADD INDEX ( `race` );
ALTER TABLE `races` ADD INDEX ( `raceid` ) ;

ALTER TABLE accounts
ADD
FOREIGN KEY `1` ( `race` )
REFERENCES `races`( `raceid` ) ;
')

_________________
R.I.P.
†26.7.2004 - 20.3.2006†
†MeteorA†

Sofern "CASCADE" kaskadierendes Löschen aktiviert, würde ich damit sehr vorsichtig sein. Da kann man nämlich schnell weit mehr löschen, als einem lieb ist.
Lieber über einen entsprechenden SQL-Code abfangen und von Hand auswerten.

Zu Devils Post bzgl. Vermeidung des Transaktionsbugs: Ich hab damals in meine Version ja schon mal eine Lösung eingefügt, die zwar recht aufwendig einzubauen ist, aber seitdem sämtliche Probleme behoben hat.
Inzwischen läuft die Version nur noch bei bibir, da ich selbst ja raus bin, aber evtl. kann Anp damit was anfangen, wenn er schon noch eine neue "Ausgabe" der ext ger macht.

_________________
A bus station is where busses stop. A train station is where trains stop. On my desk there is a workstation...