Mailinglisten-Archive |
--part1_f6.1c3c13c4.2a2fd9dd_boundary Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi, das stand dazu im MySQL - Datenhandbuch, warum man das nicht einsetzen=20 sollte. Foreign Keys verkomplizieren das allgemeine Datenbankhandling. Die=20 Einfachheit von MySQL, z.B. im Intranet eine Datenbank zu pflegen (SHOP), un= d=20 t=E4glich in das Internet zu kopieren, w=E4re dahin. Die Geschwindigkeit von INSERT und UPDATE Stements w=E4re ebenfalls gef=E4hr= det,=20 da die Datenbank nach einem INSERT oder UPDATE alle foreign keys einzeln=20 duchlaufen mu=DF. Im Allgemeinen werden ohnehin INSERTS stets in den richtig= en=20 Tabellen (mehrere INSERT/UPDATES in mehreren Tabellen gleichzeitig)=20 durchgef=FChrt. Also keine Panik, man kann diese Konstrukte durch Workaround= s=20 in den Griff bekommen. Abfragen und Verkn=FCpfungen =FCber mehrere Tabellen=20= sind=20 aber stets erlaubt, damit keine Mi=DFverst=E4ndnisse aufkommen. Backups und Restores werden fast unm=F6glich gemacht. Der einfache Vorgang,=20 eine einzelne Tabelle bei Mangel an Datenintegrit=E4t (Festplattenfehler)=20 einfach zu l=F6schen, und dann von der Backup-Platte oder dem Tape zu=20 restaurieren, funktioniert bei Datenbanken mit foreign keys nicht mehr. Es=20 mu=DF in diesen F=E4llen dann immer die gesamte Datenbank restauriert werden= , und=20 es mu=DF eine bestimmte Reihenfolge peinlich genau eingehalten werden. Bei=20 gro=DFen Datenbanken, die =FCber mehrere Millionen Eintr=E4ge verf=FCgen, is= t dann=20 mit l=E4ngeren Ausf=E4llen zu rechnen. Beim Einsatz im Internet mu=DF die Da= tenbank=20 jedoch den "mission critical" Anforderungen entsprechen. Bei foreign keys passiert es recht h=E4ufig, da=DF zirkul=E4re (rekursive) B= ez=FCge=20 entstehen, die zwar erlaubt sind, jedoch verhindern, da=DF man eine Tabelle=20= so=20 einfach mit einem CREATE Befehl erzeugen kann. Hierf=FCr sind oft sehr kompl= exe=20 Statements notwendig. Und nun einge gute Nachricht: MySQL wird in absehbarer Zeit um foreign keys=20 erweitert, im SQL Parser sind diese schon enthalten. Gruss Thomas --part1_f6.1c3c13c4.2a2fd9dd_boundary Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <HTML><FONT FACE=3Darial,helvetica><FONT SIZE=3D2 FAMILY=3D"SANSSERIF" FACE= =3D"Arial" LANG=3D"2">Hi,<BR> <BR> das stand dazu im MySQL - Datenhandbuch, warum man das nicht einsetzen sollt= e.<BR> <BR> <BR> Foreign Keys verkomplizieren das allgemeine Datenbankhandling. Die Einfachhe= it von <B>MySQL</B>, z.B. im <B>Intranet</B> eine Datenbank zu pflegen (SHOP= ), und t=E4glich in das Internet zu kopieren, w=E4re dahin.<BR> <BR> <BR> Die Geschwindigkeit von INSERT und UPDATE Stements w=E4re ebenfalls gef=E4hr= det, da die Datenbank nach einem INSERT oder UPDATE alle foreign keys einzel= n duchlaufen mu=DF. Im Allgemeinen werden ohnehin INSERTS stets in den richt= igen Tabellen (mehrere INSERT/UPDATES in mehreren Tabellen gleichzeitig) dur= chgef=FChrt. Also keine Panik, man kann diese Konstrukte durch <B>Workaround= s</B> in den Griff bekommen. Abfragen und Verkn=FCpfungen =FCber mehrere Tab= ellen sind aber stets erlaubt, damit keine Mi=DFverst=E4ndnisse aufkommen.<B= R> <BR> <BR> Backups und Restores werden fast unm=F6glich gemacht. Der einfache Vorgang,=20= eine einzelne Tabelle bei Mangel an Datenintegrit=E4t (Festplattenfehler) ei= nfach zu l=F6schen, und dann von der Backup-Platte oder dem Tape zu restauri= eren, funktioniert bei Datenbanken mit foreign keys nicht mehr. Es mu=DF in=20= diesen F=E4llen dann immer die gesamte Datenbank restauriert werden, und es=20= mu=DF eine bestimmte Reihenfolge peinlich genau eingehalten werden. Bei gro= =DFen Datenbanken, die =FCber mehrere Millionen Eintr=E4ge verf=FCgen, ist d= ann mit l=E4ngeren Ausf=E4llen zu rechnen. Beim Einsatz im Internet mu=DF di= e Datenbank jedoch den <B>"mission critical"</B> Anforderungen entsprechen.<= BR> <BR> <BR> Bei foreign keys passiert es recht h=E4ufig, da=DF zirkul=E4re (rekursive) B= ez=FCge entstehen, die zwar erlaubt sind, jedoch verhindern, da=DF man eine=20= Tabelle so einfach mit einem CREATE Befehl erzeugen kann. Hierf=FCr sind oft= sehr komplexe Statements notwendig.<BR> <BR> <BR> Und nun einge gute Nachricht: <B>MySQL</B> wird in absehbarer Zeit um foreig= n keys erweitert, im SQL Parser sind diese schon enthalten.<BR> <BR> Gruss<BR> Thomas</FONT></HTML> --part1_f6.1c3c13c4.2a2fd9dd_boundary-- --- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql
php::bar PHP Wiki - Listenarchive