Mailinglisten-Archive |
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20D24.F6CF9C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, warum foreign key's ? ist doch nur wasserkopf ... wenn man so was will kann man doch herrliche produkte von m$ erwerben = .... oder von HAL ... die haben auch so was ... also freu dich =FCber die einfache struktur von mysql ... und die damit verbundenen vorteile ... ist herzschonender als mit DB's von HAL zu arbeiten ... jedenfalls im net ein HAL gesch=E4digter net tipper h1 =20 -----Urspr=FCngliche Nachricht----- Von: Potsdam14473_(at)_aol.com [mailto:Potsdam14473_(at)_aol.com] Gesendet: Mittwoch, 5. Juni 2002 23:19 An: mysql-de_(at)_lists.4t2.com Betreff: Re: FOREIGN KEY's in MySQL Hi, das stand dazu im MySQL - Datenhandbuch, warum man das nicht einsetzen sollte. Foreign Keys verkomplizieren das allgemeine Datenbankhandling. Die Einfachheit von MySQL, z.B. im Intranet eine Datenbank zu pflegen = (SHOP), und t=E4glich in das Internet zu kopieren, w=E4re dahin. Die Geschwindigkeit von INSERT und UPDATE Stements w=E4re ebenfalls = gef=E4hrdet, da die Datenbank nach einem INSERT oder UPDATE alle foreign keys = einzeln duchlaufen mu=DF. Im Allgemeinen werden ohnehin INSERTS stets in den = richtigen Tabellen (mehrere INSERT/UPDATES in mehreren Tabellen gleichzeitig) durchgef=FChrt. Also keine Panik, man kann diese Konstrukte durch = Workarounds in den Griff bekommen. Abfragen und Verkn=FCpfungen =FCber mehrere = Tabellen sind aber stets erlaubt, damit keine Mi=DFverst=E4ndnisse aufkommen. Backups und Restores werden fast unm=F6glich gemacht. Der einfache = Vorgang, eine einzelne Tabelle bei Mangel an Datenintegrit=E4t = (Festplattenfehler) einfach zu l=F6schen, und dann von der Backup-Platte oder dem Tape zu restaurieren, funktioniert bei Datenbanken mit foreign keys nicht mehr. = Es mu=DF in diesen F=E4llen dann immer die gesamte Datenbank restauriert = werden, und es mu=DF eine bestimmte Reihenfolge peinlich genau eingehalten = werden. Bei gro=DFen Datenbanken, die =FCber mehrere Millionen Eintr=E4ge = verf=FCgen, ist dann mit l=E4ngeren Ausf=E4llen zu rechnen. Beim Einsatz im Internet mu=DF = die Datenbank jedoch den "mission critical" Anforderungen entsprechen. Bei foreign keys passiert es recht h=E4ufig, da=DF zirkul=E4re = (rekursive) Bez=FCge entstehen, die zwar erlaubt sind, jedoch verhindern, da=DF man eine = Tabelle so einfach mit einem CREATE Befehl erzeugen kann. Hierf=FCr sind oft sehr komplexe Statements notwendig. Und nun einge gute Nachricht: MySQL wird in absehbarer Zeit um foreign = keys erweitert, im SQL Parser sind diese schon enthalten. Gruss Thomas=20 ------_=_NextPart_001_01C20D24.F6CF9C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D136233706-06062002>hi,</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D136233706-06062002>warum=20 foreign key's ?</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D136233706-06062002>ist=20 doch nur wasserkopf ...</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D136233706-06062002>wenn=20 man so was will kann man doch herrliche produkte von m$ erwerben=20 ....</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D136233706-06062002>oder=20 von HAL ... die haben auch so was ...</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D136233706-06062002>also=20 freu dich =FCber die einfache struktur von mysql ... und die damit = verbundenen=20 vorteile ...</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D136233706-06062002>ist=20 herzschonender als mit DB's von HAL zu arbeiten ...</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D136233706-06062002>jedenfalls im net</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN = class=3D136233706-06062002>ein=20 HAL gesch=E4digter net tipper</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D136233706-06062002>h1</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D136233706-06062002></SPAN></FONT> </DIV> <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT = face=3DTahoma=20 size=3D2>-----Urspr=FCngliche Nachricht-----<BR><B>Von:</B> = Potsdam14473_(at)_aol.com=20 [mailto:Potsdam14473_(at)_aol.com]<BR><B>Gesendet:</B> Mittwoch, 5. Juni = 2002=20 23:19<BR><B>An:</B> mysql-de_(at)_lists.4t2.com<BR><B>Betreff:</B> Re: = FOREIGN KEY's=20 in MySQL<BR><BR></FONT></DIV><FONT face=3Darial,helvetica><FONT = lang=3D2 face=3DArial=20 size=3D2 FAMILY=3D"SANSSERIF">Hi,<BR><BR>das stand dazu im MySQL - = Datenhandbuch,=20 warum man das nicht einsetzen sollte.<BR><BR><BR>Foreign Keys = verkomplizieren=20 das allgemeine Datenbankhandling. Die Einfachheit von <B>MySQL</B>, = z.B. im=20 <B>Intranet</B> eine Datenbank zu pflegen (SHOP), und t=E4glich in das = Internet zu=20 kopieren, w=E4re dahin.<BR><BR><BR>Die Geschwindigkeit von INSERT und = UPDATE=20 Stements w=E4re ebenfalls gef=E4hrdet, da die Datenbank nach einem = INSERT oder=20 UPDATE alle foreign keys einzeln duchlaufen mu=DF. Im Allgemeinen = werden ohnehin=20 INSERTS stets in den richtigen Tabellen (mehrere INSERT/UPDATES in = mehreren=20 Tabellen gleichzeitig) durchgef=FChrt. Also keine Panik, man kann diese = Konstrukte=20 durch <B>Workarounds</B> in den Griff bekommen. Abfragen und = Verkn=FCpfungen =FCber=20 mehrere Tabellen sind aber stets erlaubt, damit keine = Mi=DFverst=E4ndnisse=20 aufkommen.<BR><BR><BR>Backups und Restores werden fast unm=F6glich = gemacht. Der=20 einfache Vorgang, eine einzelne Tabelle bei Mangel an Datenintegrit=E4t = (Festplattenfehler) einfach zu l=F6schen, und dann von der = Backup-Platte oder dem=20 Tape zu restaurieren, funktioniert bei Datenbanken mit foreign keys = nicht mehr.=20 Es 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 gro=DFen=20 Datenbanken, die =FCber mehrere Millionen Eintr=E4ge verf=FCgen, ist = dann mit l=E4ngeren=20 Ausf=E4llen zu rechnen. Beim Einsatz im Internet mu=DF die Datenbank = jedoch den=20 <B>"mission critical"</B> Anforderungen entsprechen.<BR><BR><BR>Bei = foreign keys=20 passiert es recht h=E4ufig, da=DF zirkul=E4re (rekursive) Bez=FCge = entstehen, die zwar=20 erlaubt sind, jedoch verhindern, da=DF man eine Tabelle so einfach mit = einem=20 CREATE Befehl erzeugen kann. Hierf=FCr sind oft sehr komplexe = Statements=20 notwendig.<BR><BR><BR>Und nun einge gute Nachricht: <B>MySQL</B> wird = in=20 absehbarer Zeit um foreign keys erweitert, im SQL Parser sind diese = schon=20 enthalten.<BR><BR>Gruss<BR>Thomas</FONT> </FONT></BODY></HTML> ------_=_NextPart_001_01C20D24.F6CF9C20-- --- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql
php::bar PHP Wiki - Listenarchive