Hallo,

ich habe mir mal erlaubt die Datenbank unseres CRM Systems genauer unter die Lupe zu nehmen. Dabei ist mir aufgefallen, dass in der Datenbank selbst keinerlei Relationen zwischen den einzelnen Tabellen vorhanden sind, es also keine Fremdschlüssel in den Tabellen gibt, die auf die Haupttabelle (z.B. Adressen) verweist.

Daher nun die Frage, ob es nicht sinnvoll ist, die Datenbank so zu optimieren, dass die Relationen in der Datenbank selbst hinterlegt sind. Oder reicht es auch aus, wenn die Beziehungen über die Programmiersprache der Anwendung, die afu die DB zugreift geliefert werden? Was ist für die Performance besser? Hat da jemand Erfahrungen?

Hi,

sofern die FK möglich sind, sollte man sich durchaus überlegen solche einzuführen. Das sollte aber unbedingt genau getestet werden, denn wenn die Anwendung z.B. intern immer zuerst die Adresse anlegt bevor die Person angelegt wird, gibt das erstmal Probleme. Des weiteren könnten jetzt Inkonsistenzen zum Vorschein kommen, die vorher nicht bemerkt wurden (z.B. Adressen ohne Personen o.ä.)

Die Performance wird sich durch die Anlage eines FK-Constraints nicht verändern, wenn man mal von Löschungen absieht, die falls gewünscht, dann von der DB durchgeführt werden und je nach Datenmodell dadurch schneller oder langsamer werden können.

Dim

Hi,

wie sieht das denn mit Select-abfragen aus? Sind die durch FKs einfacher bzw. besser zu lösen, als wenn man keine FKs hat? Wirken sich hier FKs evtl. positiv auf die Abfragen und die Geschwindigkeit der Ergebnisse aus?

Ich denke Du meinst mit Relationen die "referenzielle Integrität", oder täusche ich mich? Natürlich gehören dazu auch die PK / FK Beziehungen, d.h. in Deiner Datenbank existieren keine Informationen, welche Tabellenfelder Inhalte von anderen Tabellenfeldern verknüpfen, das führt dazu, dass es möglich ist, dass Du in einem FK Feld Inhalten haben kannst, die in den PK Feld nicht vorhanden sind. Damit kann es passieren, dass die Integrität Deiner Daten nicht konsistent ist.

Bei mySQL entsteht dieses Problem, wenn man die Datenbank vor dem Einsatz von InnoDB erstellt hat, da myISAM noch keine referenzielle Integrität beherrscht. Postgresql, MS SQL sollten dagegen es beherrschen.

Hi,

wie sieht das denn mit Select-abfragen aus? Sind die durch FKs einfacher bzw. besser zu lösen, als wenn man keine FKs hat? Wirken sich hier FKs evtl. positiv auf die Abfragen und die Geschwindigkeit der Ergebnisse aus?

Nein. FK Constraints werden, wie flashpixx schon erläutert hat, verwendet, um die technische integrität der Daten sicherzustellen. Sprich Du kannst damit z.B. festlegen, dass eine Adresse immer zu einer Person gehören muss und nicht allein dastehen darf.

Dim

ich habe mir mal erlaubt die Datenbank unseres CRM Systems genauer unter die Lupe zu nehmen.

Ist das eine Eigenentwicklung? Wenn nein, dann ist die Datenbank vermutlich genau so, wie sie sein sollte und man sollte sie nicht anfassen.

Wenn nein, dann ist die Datenbank vermutlich genau so, wie sie sein sollte und man sollte sie nicht anfassen.

"Never touch a running system" ist nicht immer die beste Lösung, vor allem wenn die Datenintegrität hier evtl nicht sicher gestellt ist. Bitte einmal den Schaden überlegen, der entsteht, wenn die Datenbank über Jahre betrieben wird und sich dann herausstellt, dass Daten auf einmal nicht mehr vorhanden sind bzw. nicht mehr zugeordnet werden kann, welche Abhängigkeit zwischen den Daten besteht.

Wenn es sich um eine Kaufsoftware handelt schon, denn kein Hersteller wird hier noch irgendwas kostenfrei beheben, wenn plötzlich irgendwas nicht mehr so läuft wie es laufen sollte.

Natürlich, aber so wie ich die Postings verstanden habe, geht es hier um den Hersteller, d.h. aus Sicht des Herstellers können bei eben nicht korrekt aufgebauter Datenbank Regressansprüche unter Umständen geltend gemacht werden. Wenn ich als Hersteller eines solchen Systems eben nicht korrekt arbeite, dann können eben Kosten auf mich zu kommen

Hmm kann sein, aber ich hab das eher so gelesen, dass jemand Performanceprobleme mit seinem CRM System hat und jetzt der Auftrag an TK8782 ergangen ist, sich "doch mal" die Datenbank anzusehen ob man da was machen könnte...

Kann aber auch anders sein. Auf jeden Fall muss die Anwendung danach nochmal komplett durchgetestet werden, wenn im großen Stil Constraints eingefügt werden. Was die Dateninkonstistenzen, die ohne PK-FK Constraints zwangsläufig auftreten, betrifft, hast Du natürlich recht.

Dim

"Never touch a running system" ist nicht immer die beste Lösung, vor allem wenn die Datenintegrität hier evtl nicht sicher gestellt ist. Bitte einmal den Schaden überlegen, der entsteht, wenn die Datenbank über Jahre betrieben wird und sich dann herausstellt, dass Daten auf einmal nicht mehr vorhanden sind bzw. nicht mehr zugeordnet werden kann, welche Abhängigkeit zwischen den Daten besteht.

Genau so hatte ich es nicht gemeint. Ich gehe viel eher davon aus, dass wenn das eine Fremdsoftware ist sie auch zu Beginn ordentlich eingerichtet wurde. Ob das tatsächlich so ist sollte man separat überprüfen. Wer sagt ihm denn, dass die Software nicht tatsächlich so programmiert ist, dass Sie zuerst die Häuser in der Datenbank anlegt, dann die Besitzer und anschließend die Records der Häuser updatet um die Besitzer mit den Häusern zu verknüpfen?

Vielleicht wird die ganze Wahrung der Integrität auf höherer Ebene in der Anwendung gemacht, da diese auf dutzenden verschiednenen Datenbanken läuft und der Hersteller nicht unbedingt davon ausgeht, dass ejde dies beherrscht. Das weiß man alles nicht.

Deshalb bei Fremdsoftware: Vorsicht mit der Datenbank. Supportet wird der Hersteller nämlich nicht leisten, wenn an der Datenbank manipuliert wurde und deshalb etwas nicht mehr geht.

Also, bevor wir hier sinnlos weiter diskutieren sollte der Op erstmal damit rausrücken, worum es eigentlich geht.

Wenn es eine eigene Software ist, dann werdet ihr auch wohl wissen, wie die Software funktioniert.

Der TO hat leider nichts zum verwendeten DBMS geschrieben. Ohne werten zu wollen: Generell kann man die referenzielle Integrität natürlich auch durch die Software realisieren.

Generell kann man die referenzielle Integrität natürlich auch durch die Software realisieren.

Das bestreitet ja niemand, dass man das machen kann, nur gehört so etwas nicht in die Anwendungslogik. Wenn man z.B. auf die Datenbank direkt zugreift (z.B. ODBC) dann wäre, wenn die Integrität nur in der Anwendung hinterlegt ist, eben die Gefahr von Inkonsistenz der Daten gegeben. Wenn die Datenbank z.B. von mehreren Anwendung z.B. PHP für das Webinterface und Java / C# für eine GUI verwendet wird, dann muss sichergestellt werden, dass die Integrität aus beiden Anwendungen identisch ist, was letztendlich zu höheren Entwicklungsaufwand führt.

Referentielle Integritäten gehören in die Datenbank und nicht in die Anwendung (sofern das DBMS diese Unterstützt)

Der TO hat leider nichts zum verwendeten DBMS geschrieben. Ohne werten zu wollen: Generell kann man die referenzielle Integrität natürlich auch durch die Software realisieren.

Das kannst Du nur, wenn Du den Zugriff auf die beteiligten Tabellen serialisierst - sprich vor jeder Änderung die Tabellen komplett für andere sperrst. Ansonsten geht es in einer Mutiuserumgebung definitiv nicht.

Dim

Das kannst Du nur, wenn Du den Zugriff auf die beteiligten Tabellen serialisierst - sprich vor jeder Änderung die Tabellen komplett für andere sperrst. Ansonsten geht es in einer Mutiuserumgebung definitiv nicht.

Stimmt, das hatte ich vergessen. Sprich in dem Fall 3-gliedrige Architektur, so dass nur eine Instanz auf die DB zugreift und eben dort entsprechende Lock Mechanismen abgebildet werden. Hat aber letztendlich die Konsequenz, dass alles über diese eine Instanz laufen muss und diese dann entsprechend dimensioniert wird.

Ich habe ausdrücklich betont, dass ich es nicht bewerten will. Ganz allgemein hat der TO viel zu wenig zum Problem geschrieben.