phpbar.de logo

Mailinglisten-Archive

AW: FOREIGN KEY's in MySQL

AW: FOREIGN KEY's in MySQL

mysql-de_(at)_lists.bttr.org mysql-de_(at)_lists.bttr.org
Thu, 6 Jun 2002 08:39:53 +0200


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>&nbsp;</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