nicht angemeldet
Halihallo Andreas
*ARGS* ich habe mein schlaues SQL-Buch (SQL the complete reference) vorgestern nach
Hause verlegt und habe somit mein externes Hirn verloren, daher kann ich grad nicht
wirklich fundiert und wissend aussagen. :-)
Sollte ich mir vielleicht auch mal zulegen, die einziegn Bücher die ich habe sind ++ber PERL und C++, aber wirklich durchgearbeitet habe ich die noch nicht ;-)
Ja, also die "SQL the complete reference"
http://www.amazon.de/exec/obidos/ASIN/0072225599/qid=1054826978/sr=2-2/ref=sr_aps_prod_2_1/302-2941283-6201631
ist sehr empfehlenswert. Manchmal ist es aber auch wirklich für Laien
geschreiben, wie mir scheint... Aber es ist doch sehr ausführlich und nicht zu letzt,
ziemlich dick :-)
Aber ja, ich glaube die Constraints dürften die referenzielle Integrität sicherstellen,
soweit ich das jetzt beurteilen kann. Ich werde es morgen mitnehmen, dann kann ich
ggf. noch andere Integritäten nennen (die kenne ich jetzt nicht alle auswendig).Das weiß ich auch nicht, aber es besteht die Möglichkeit beim Löschen eines Datensatzes aus der Parent-Tabelle automatisch alle referenzierten Datensätze aus der/den Child-Tabellen zu löschen. Das ist doch schonmal was, das könnte ich _sehr_ gut gebrauchen!
Oh, mir kam in den Sinn, dass ich mir das mit den Integritäten mal aufgeschrieben habe:
Valid Column Integrity (Welche Daten werden überhaupt unterstützt?)
Required Data Integrity (Welche Daten müssen unbedingt vorhanden sein?)
Data validity Integrity (Ist der Datentyp und inhalt OK?)
Entity integrity ( ist der Primärschlüssel wirklich unique?; implizit durch Datenbank gegeben )
Referential integrity ( sind die Foreignkeys existent? - Foreign muss Primary der Foreign-Tabelle sein )
Business Rule integrity ( unterstützt der Account überhaupt Funktion A,B,C )
Consistency integrity ( sind die Daten konsistent? z.B. wenn Datum für
letzten Gebrauch gewechselt wurde, muss letzer Check auch geändert werden)
Wie man sieht, sind es wirklich nur "Oberbegriffe" für viele Arten der Anomalien.
Naja, wenn ich das richtig verstehe kann das MySQL also grundlegend bei InnoDB Tabellen, aber noch lange nicht so ausgefeilt wie Oracle & Co., Wobei mir das eigentlich fürs erste reicht...
Ja, denke ich auch. Für die meisten Anwendungen dürfte es wirklich reichen. Alles
weitere kann dann von mir aus in MySQL 6.x kommen :-)
- so nebenbei - SHOW INNODB STATUS könnte die von Lude gewünschten Infos enthalten...
SHOW INNODB STATUS??? - Meine Güte du liest genau! - Das versteckte sich ja irgendwo
in der Foreign_key_constraints. Aber wirklich eine Doku dazu habe ich noch nicht
gefunden. Oder suche ich falsch? (das ist eine rhetorische Frage! *g*)
Nun, ich will jetzt ja auch nicht den Glauben verbreiten, dass referenzielle Integrität
genau definiert ist; es ist IMHO ein Sammelbegriff für eine mögliche Anomalie.
Wie gesagt habe ich davon wenig Ahnung, aber mein Verständnis davon ist, dass referenzielle Integrität einfach bedeutet, dass verknüpfte Datensätze nicht isoliert betrachtet werden müssen, sondern dass wie oben beschreiben wenn ein Datensatz gelöscht wird alle verknüpften ebenfalls gelöscht werden. Oder geht das noch weiter? Ich bin gespannt was Dein schlaues Buch dazu sagt ;-))
Genaueres als das oben kann ich im Moment nicht sagen, aber ich glaube, dass es auch
nicht näher erleutert wurde. Ich nehme an, dass sich hinter der
"Referenziellen Integrität" wirklich nur das verbirgt (ich werd mal noch nachsehen,
vielleicht ist es ja doch schlauer, dieses Buch *g*).
Viele Grüsse
Philipp
RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.