Probleme mit Foreign Keys
Mike Wesling
ich habe ein Problem mit meinen Foreign-Key-Constraints. Ich habe
verschiedene Tabellen modelliert und als InnoDB-Tabellen erzeugt.
Das dumme ist nur, dass ich eine Tabelle habe, auf der ich einen
Volltext-Index erstellen möchte und sie daher als MyISAM Tabelle
deklarieren muss. Nun kann ich die Foreign-Keys-Contraints aber nicht
mehr anwenden.
Lässt sich das irgendwie umgehen??
Das nächste, was ich zu den Foreign-Keys fragen wollte: Muss ich mich
um das Einfügen, der referenzierten Werte selbst kümmern? Ich habe 2
Entitäten, die über eine (n:m)-Verbindung miteinander verknüpft sind.
Das heisst, es gibt noch eine dritte Tabelle, die beide Primary-Keys
der Tabellen als Foreign-Key miteinander verbindet. Zusätzlich habe
ich für beide angegeben, dass ein ON UPDATE/ON DELETE CASCADE gemacht
werden soll.
Ist es nun normal, dass ich mich selbst um das Einfügen der Werte in
der Verknüpfungstabelle (dritte Tabelle) kümmern muss? Also ein UPDATE
bedeutet hier dann nicht, dass wenn ich in eine Tabelle einen neuen
Wert einfüge, dass dieser dann in der Verknüpfungstabelle auch
eingetragen werden muss, nur falls sich Werte ändern, die in beiden
Tabellen da sind?
Andreas Kretschmer
> Das dumme ist nur, dass ich eine Tabelle habe, auf der ich einen
> Volltext-Index erstellen möchte und sie daher als MyISAM Tabelle
> deklarieren muss. Nun kann ich die Foreign-Keys-Contraints aber nicht
> mehr anwenden.
>
> Lässt sich das irgendwie umgehen??
Ja. Du kannst warten, bis 'Falcon' als Storage Engine fertig ist, die
soll das dann können.
> Ist es nun normal, dass ich mich selbst um das Einfügen der Werte in
> der Verknüpfungstabelle (dritte Tabelle) kümmern muss? Also ein UPDATE
> bedeutet hier dann nicht, dass wenn ich in eine Tabelle einen neuen
> Wert einfüge, dass dieser dann in der Verknüpfungstabelle auch
> eingetragen werden muss, nur falls sich Werte ändern, die in beiden
> Tabellen da sind?
Und hier die gute Nachricht: TRIGGER wurden bereits erfunden bei MySQL.
end
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
Christian Franzen
"Andreas Kretschmer" <akret...@spamfence.net> schrieb
> Ja. Du kannst warten, bis 'Falcon' als Storage Engine fertig ist, die
> soll das dann können
Wurde dafür schon ein genauer Termin verkündet (oder wenigsten ein Monat)?
mfg Xion
Christian Kirsch
Heißer Tipp: Wenn's fertig ist.
--
Christian
Andreas Kretschmer
Axel Schwenke
>
> ich habe ein Problem mit meinen Foreign-Key-Constraints. Ich habe
> verschiedene Tabellen modelliert und als InnoDB-Tabellen erzeugt.
>
> Das dumme ist nur, dass ich eine Tabelle habe, auf der ich einen
> Volltext-Index erstellen möchte und sie daher als MyISAM Tabelle
> deklarieren muss. Nun kann ich die Foreign-Keys-Contraints aber nicht
> mehr anwenden.
>
> Lässt sich das irgendwie umgehen??
Der Standard-Workaround ist, die Tabelle InnoDB zu machen und in eine
MyISAM-Tabelle in einem anderen MySQL-Server (z.B. auch auf der gleichen
Maschine) zu replizieren. Dann kann man die Volltext-Suchen auf der
MyISAM-Tabelle machen und alle Writes auf die InnoDB-Tabelle.
XL
Andreas Scherbaum
> Andreas Scherbaum <ads-...@wars-nicht.de> wrote:
>> Axel Schwenke <axel.s...@gmx.de> wrote:
>>>
>>> Der Standard-Workaround ist, die Tabelle InnoDB zu machen und in eine
>>> MyISAM-Tabelle in einem anderen MySQL-Server (z.B. auch auf der gleichen
>>> Maschine) zu replizieren. Dann kann man die Volltext-Suchen auf der
>>> MyISAM-Tabelle machen und alle Writes auf die InnoDB-Tabelle.
>>
>> zwei Datenbankverbindungen und getrennte Logik für Lesen, Lesen mit Suchen
>> und Schreiben, um das zu realisieren?
>
> Eine zum Lesen, eine zum Schreiben. Das ist nicht unbedingt ungewöhn-
> lich weil man das auch für Scale-out mittels Replikation braucht. Wenn
> man will, kann man das aber vom MySQL-Proxy auseinanderfitzeln lassen.
Ich will aber kein Scale-out, ich will einfach nur eine Volltextsuche
in Sicher (sprich: InnoDB). Die skalierende Lösung interessiert mich
vielleicht, wenn ich mehr als einen Datenbankserver dort hinstellen muss.
Ansonsten kostet mich die Replikation bloss Performance und Mehrarbeit
in der Applikation, abgesehen vom Aufwand, bereits existierende
Programme zu so einem Schritt zu bewegen.
>> Abgesehen davon, das bei diesem komplizierten Workaround die Daten in
>> der Volltexttabelle nicht unbedingt denen in der InnoDB Tabelle
>> entsprechen müssen? L
>
> Also *ich* finde die MySQL-Replikation nicht kompliziert. YMMV. Und
> wenn man das richtig aufsetzt (Replikat read-only) dann gibt es keinen
> Grund warum die Daten unterschiedlich sein sollten.
Warum gibt es sonst 'Seconds_Behind_Master', eine Variable, die schon
mal größere Werte annehmen kann. Oder die Replikation stoppt aus
irgendwelchen Gründen, die nicht am Netzwerk liegen.[1][2]
Alles in allem ist das trotz deiner Zusicherung, dass dies nicht kompliziert
ist, ein sehr großer Overhead für ein kleines bischen Funktionalität.
[1] http://forums.mysql.com/read.php?26,79962,79962#msg-79962
[2] http://forums.mysql.com/read.php?26,68933,68933#msg-68933
--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)
Axel Schwenke
> Axel Schwenke <axel.s...@gmx.de> wrote:
>> Andreas Scherbaum <ads-...@wars-nicht.de> wrote:
>>> Axel Schwenke <axel.s...@gmx.de> wrote:
>>>>
>>>> Der Standard-Workaround ist, die Tabelle InnoDB zu machen und in eine
>>>> MyISAM-Tabelle in einem anderen MySQL-Server (z.B. auch auf der gleichen
>>>> Maschine) zu replizieren. Dann kann man die Volltext-Suchen auf der
>>>> MyISAM-Tabelle machen und alle Writes auf die InnoDB-Tabelle.
>>>
>>> Nur das ich das richtig verstehe: ich brauche in meiner Anwendung
>>> zwei Datenbankverbindungen und getrennte Logik für Lesen, Lesen mit Suchen
>>> und Schreiben, um das zu realisieren?
>>
>> Eine zum Lesen, eine zum Schreiben. Das ist nicht unbedingt ungewöhn-
>> lich weil man das auch für Scale-out mittels Replikation braucht. Wenn
>> man will, kann man das aber vom MySQL-Proxy auseinanderfitzeln lassen.
>
> Ich will aber kein Scale-out, ich will einfach nur eine Volltextsuche
> in Sicher (sprich: InnoDB).
Na klar willst du das. Das gibts aber nicht. Was es gibt, ist o.g.
Workaround (du hast sicher schon gemerkt, daß da nicht Lösung steht).
Und wenn es dir zuviel Aufwand ist, Lesen und Schreiben in der
Applikation auf verschiedene Datenbankverbindungen aufzuteilen, dann
kann das der MySQL-Proxy auch automatisieren.
> Ansonsten kostet mich die Replikation bloss Performance und Mehrarbeit
> in der Applikation, abgesehen vom Aufwand, bereits existierende
> Programme zu so einem Schritt zu bewegen.
Ja. Und?
>> Also *ich* finde die MySQL-Replikation nicht kompliziert. YMMV. Und
>> wenn man das richtig aufsetzt (Replikat read-only) dann gibt es keinen
>> Grund warum die Daten unterschiedlich sein sollten.
>
> Warum gibt es sonst 'Seconds_Behind_Master', eine Variable, die schon
> mal größere Werte annehmen kann.
Weil asynchrone Replikation impliziert, daß der Slave *immer* hinter dem
Master ist? Abgesehen davon: klassische Volltextsuchmaschinen verwenden
alle einen Offline-Indexer. D.h. der Volltextindex und der Datenbestand
differieren die meiste Zeit sowieso. Ein paar Sekunden Lag von der
MySQL-Replikation dürften in vielen Fällen eine substantielle Verbesse-
rung gegenüber einer andere Suchmaschine darstellen.
> Oder die Replikation stoppt aus
> irgendwelchen Gründen, die nicht am Netzwerk liegen.[1][2]
>
> [1] http://forums.mysql.com/read.php?26,79962,79962#msg-79962
> [2] http://forums.mysql.com/read.php?26,68933,68933#msg-68933
Du hast nichts besseres gefunden als zwei eineinhalb Jahre alte Bugs?
(ich nehme einfach mal zu deinen Gunsten an, daß das Bugs waren)
Kann es sein, daß dich eine Lösung für das Problem des OP gar nicht
interessiert und du nur ein bisschen trollen willst?
XL
Andreas Scherbaum
> Andreas Scherbaum <ads-...@wars-nicht.de> wrote:
>
>> Ansonsten kostet mich die Replikation bloss Performance und Mehrarbeit
>> in der Applikation, abgesehen vom Aufwand, bereits existierende
>> Programme zu so einem Schritt zu bewegen.
>
> Ja. Und?
Alles klar, eine Antwort in der Form habe ich von dir erwartet. Schön,
die Vermutung bestätigt zu bekommen.
> Du hast nichts besseres gefunden als zwei eineinhalb Jahre alte Bugs?
> (ich nehme einfach mal zu deinen Gunsten an, daß das Bugs waren)
Nimm an, was du möchtest, daran hindern kann und möchte ich dich nicht.
Beim ersten Durchlesen der Beschreibung für diesen Workaround sind mir
ein paar Gedanken der Form: "das schreit nach Folgeproblemen" in den
Kopf gekommen und ich wollte einfach wissen, ob dem wirklich so ist.
Darin sehe ich mich bestätigt und die pawlowschen Reflexe auf kritische
Fragen tragen nicht zu einer Verbesserung der Situation bei.
Die beiden aufgeführten Bugs (beide nicht geschlossen, auch nach
eineinhalb Jahren nicht) sind nicht das einzige, was mir dazu einfällt.
Die ganze Liste erspare ich mir und hebe sie mir als Argumente für
später auf.
> Kann es sein, daß dich eine Lösung für das Problem des OP gar nicht
> interessiert und du nur ein bisschen trollen willst?
Warum ist bei dir jeder, der bei einem so komplexen Setup (tschuldigung,
Workaround) die Probleme hinterfragt, ein Troll?
Bye
Axel Schwenke
> Axel Schwenke <axel.s...@gmx.de> wrote:
>> Andreas Scherbaum <ads-...@wars-nicht.de> wrote:
>>
>>> Ansonsten kostet mich die Replikation bloss Performance und Mehrarbeit
>>> in der Applikation, abgesehen vom Aufwand, bereits existierende
>>> Programme zu so einem Schritt zu bewegen.
>>
>> Ja. Und?
>
> Alles klar, eine Antwort in der Form habe ich von dir erwartet. Schön,
> die Vermutung bestätigt zu bekommen.
Welche Vermutung? Daß man für ein extra Feature manchmal mit extra
Aufwand bezahlen muß? Wie gesagt, *ich* finde den Preis nicht zu hoch.
Du vielleicht schon. Warum sollte mich *deine* Auffassung von einem
angemessenem Preis-Leistungsverhältnis interessieren?
>> Du hast nichts besseres gefunden als zwei eineinhalb Jahre alte Bugs?
>> (ich nehme einfach mal zu deinen Gunsten an, daß das Bugs waren)
>
> Nimm an, was du möchtest, daran hindern kann und möchte ich dich nicht.
...
> Die beiden aufgeführten Bugs (beide nicht geschlossen, auch nach
> eineinhalb Jahren nicht)
Das sind Foren-Postings. Keine Bugreports. Postings werden nicht
geschlossen.
> Die ganze Liste erspare ich mir und hebe sie mir als Argumente für
> später auf.
Soll das eine Drohung sein?
>> Kann es sein, daß dich eine Lösung für das Problem des OP gar nicht
>> interessiert und du nur ein bisschen trollen willst?
>
> Warum ist bei dir jeder, der bei einem so komplexen Setup (tschuldigung,
> Workaround) die Probleme hinterfragt, ein Troll?
Du bist deswegen ein Troll, weil du gar nicht beabsichtigst, ein
solches Setup jemals aufzubauen und deswegen auch nie in die Situation
kommen wirst, dich mit den real existierenden Problemen auseinander zu
setzen. Ich habe das getan. Ich habe schon vor 5 Jahren eine Umgebung
mit 16 MySQL-Servern und Replikation betreut. Wir haben *damals* einige
Bugs gefunden und die wurden *alle* schnell behoben. Seit ca. 3 Jahren
läuft das im wesentlichen störungsfrei.
Wikipedia hat einige Dutzend Replikate laufen und mobile.de gerüchte-
weise 300(!). Ganz sicher nicht ohne Probleme. Aber weit entfernt davon
so wackelig zu sein, wie du das darstellst.
XL
Andreas Scherbaum
> Du bist deswegen ein Troll, weil du gar nicht beabsichtigst, ein
> solches Setup jemals aufzubauen und deswegen auch nie in die Situation
> kommen wirst, dich mit den real existierenden Problemen auseinander zu
> setzen.
Du hast keine Ahnung, aber pöbelst hier rum.
Weniger zufällig (deshalb auch meine ursprüngliche Frage) weiss ich, das
ich demnächst eine wild gewachsene und mittlerweile ziemlich komplexe
Suchfunktion ein einer Webseite, die MySQL nutzt, ersetzen soll.
Und deshalb dann auch:
>> Die ganze Liste erspare ich mir und hebe sie mir als Argumente für
>> später auf.
>
> Soll das eine Drohung sein?
Nein, eine Argumentationsgrundlage, die ich jedoch hier nicht weiter
ausbreiten muss. Dann weiss ich später, worauf ich von Anfang an achten
muss.
> Ich habe das getan.
Schön für dich.
Meine Frage war, ob das Setup wirklich so komplex wird (auch wenn du
das nicht als komplex empfindest), die Antwort reicht mir.
> Wikipedia hat einige Dutzend Replikate laufen und mobile.de gerüchte-
> weise 300(!). Ganz sicher nicht ohne Probleme. Aber weit entfernt davon
> so wackelig zu sein, wie du das darstellst.
Ja, kommt immer drauf an, wie großzügig man "wackelig" definiert und
wieviel Administrationsaufwand da hineingesteckt wird. Bekannt.
Ich bevorzuge normalerweise pragmatische Lösungen, die sich KISS annähern.
Verursacht trotz aller gegenteiligen Behauptungen immer noch die
geringsten Folgeprobleme.
Sven Paulus
> Der Standard-Workaround ist, die Tabelle InnoDB zu machen und in eine
> MyISAM-Tabelle in einem anderen MySQL-Server (z.B. auch auf der gleichen
> Maschine) zu replizieren. Dann kann man die Volltext-Suchen auf der
> MyISAM-Tabelle machen und alle Writes auf die InnoDB-Tabelle.
Was ich bei der ganzen Diskussion nicht verstehe: Warum Replikation? Wenn
man nur ein kleines System hat, fuer das eine Kiste mehr als ausreicht, kann
man das doch problemlos mit drei Triggern (INSERT/DELETE/UPDATE) auf einer
InnoDB-Tabelle loesen, die parallel eine MyISAM-Tabelle updaten, welche dann
den Volltext-Index traegt.
Und als Kuer koennte man auch bei einem solchem Setup vor die eine
MySQL-Datenbank MySQL-Proxy schalten, der alle SELECT-Queries, die sich auf
den Volltext beziehen, automatisch auf die MyISAM-Tabelle umschreibt.
Axel Schwenke
>> Der Standard-Workaround ist, die Tabelle InnoDB zu machen und in eine
>> MyISAM-Tabelle in einem anderen MySQL-Server (z.B. auch auf der gleichen
>> Maschine) zu replizieren. Dann kann man die Volltext-Suchen auf der
>> MyISAM-Tabelle machen und alle Writes auf die InnoDB-Tabelle.
>
> Was ich bei der ganzen Diskussion nicht verstehe: Warum Replikation? Wenn
> man nur ein kleines System hat, fuer das eine Kiste mehr als ausreicht, kann
> man das doch problemlos mit drei Triggern (INSERT/DELETE/UPDATE) auf einer
> InnoDB-Tabelle loesen, die parallel eine MyISAM-Tabelle updaten, welche dann
> den Volltext-Index traegt.
Hmm ja. Du hast natürlich vollkommen recht.
Der "Standard-Workaround" stammt noch aus pre-Trigger Zeiten. Wird Zeit
sich mal ein paar Gedanken über die neuen Möglichkeiten zu machen :)
MySQL Proxy bietet ja auch ein paar nette Möglichkeiten:
http://datacharmer.blogspot.com/
XL