Perfomaceverlust bei Check Constaints

[sono]

Morgen , ich mal wieder.

Mich würde mal interessieren ob jemand Erfahrungen hat ob umfrangreiche CHECK Constraints und Trigger das System mehr ausbremsen als wenn ich dasselbe in PHP machen würde ( was ich nebenbei für unsicherer halten würde als direkt in der Datenbank ) , bzw ob die Performace überhaupt 'messbar ' beeinträchtigt wird , oder ob man das vernachlässigen kann.

Ich denke doch mal dass die Datenbank auf jeden Fall schneller sein sollte als PHP. Nur wie es mit dem Performanceverlust aussieht würde mich eben interessieren.

Da man sich mit ein paar kleinen Programmierfehlern in PHP schnell mal ein paar neue Einträge in der Datenbank einfangen kann , oder einem einer einfach mal das adminpasswort ändern könnte usw , würde ich relevante Bereiche gerne mit Triggern sichern , und ungültige neu Einträge eben mit CHECK zumindest teilweise auschliesen.

Gibt es da irgendwelche Erfahrungswerte ?

Gruß Sono

[goth]

Kommt darauf an welchen Datenbank-Server Du verwendest ... unter MySQL gibt's absolut keinen Performance Verlust für CHECK Constraints ... !

[sono]

Ich entwickle momentan unter Postgres 8.0 . Später kommen dann Unterstützung für MySql ab Version 4.1 und Oracle dazu.

Ok, wenn es by MySql zu vernachlässigen ist, kann man davon ausgehen das zumindest Postgres und Oracle auch kaum gebremst werden, vermute ich jetzt einfach mal.

Und bei den Triggern wird er wohl drauf ankommen in welcher Sprache er implementiert ist , wieviele ich davon einbaue , wie sauber ich sie implementiere und was genau die Teile machen müssen.

Ok, danke für deine Hielfe.

Gruß Sono

[onemorenerd]

Original geschrieben von goth
unter MySQL gibt's absolut keinen Performance Verlust für CHECK Constraints ... !

@sono: Hast du das mal geCHECKt?

[goth]

Original geschrieben von sono
Ok, wenn es by MySql zu vernachlässigen ist, kann man davon ausgehen das zumindest Postgres und Oracle auch kaum gebremst werden, vermute ich jetzt einfach mal.

Nein ... da liegst Du etwas falsch ... bei MySQL können CHECK constraints zwar definiert werden, sie werden allerdings schlichtweg ignoriert ... ... deshalb kein Performance Verlust ... mehr ... (such im Text nach CHECK ... da steht's dann irgendwo: )

The CHECK clause is parsed but ignored by all storage engines.

Ich würde allerdings auf jeden Fall annehmen das eine Serverseitige Prüfung performanter ist als eine in PHP, weil PHP halt einfach Interpretiert wird, während DB Trigger, sowie check constraints in einem zumindest vorkompilierten Binärformat vorliegen dürften.

Zudem halte ich es generell für Sinnvoller die Konsistenzprüfung einer Datenbank zu überlassen, weil da gehört sie hin. Ich bin mir allerdings bewusst, dass es auch Programmierer gibt die nicht einmal den Begriff FOREIGN KEY CONSTRAINT kennen (dabei ist's so fürchterlich lästig immer alle Detail Tabellen selbst aufzuräumen) ...

[sono]

bei MySQL können CHECK constraints zwar definiert werden, sie werden allerdings schlichtweg ignoriert ... ... deshalb kein Performance Verlust

Ok dann hast wirklich keinen Performace Verlust .

Und wieder mal ein Grund entdeckt warum ich mit lieber mit Postgres arbeite.


Andereseits , wer braucht schon CHECK , Trigger und Transaktionssicherheit ? ;-)

( Ja ich weiß 5.0 kann das auch mehr oder weniger , aber als ich angefangen haben gabs noch nichtmal Mysql 4.0 ).

Ich bin mir allerdings bewusst, dass es auch Programmierer gibt die nicht einmal den Begriff FOREIGN KEY CONSTRAINT kennen (dabei ist's so fürchterlich lästig immer alle Detail Tabellen selbst aufzuräumen) ...

Dass erinnert mich jetzt an nen IchAg ler mit dem ich mal das Vergnügen hatte. Der dachte er können nach einem 2 Wochen Kurs in der Abendschule "Datenbank basierte und Objektorientierte Webapplikationen" erstellen.

Andereseits ist es dem Kunden leider ziemlich egal was hinter der toll blinkenen bunten Seite im Web so auf dem Server passiert solange ihr Browser das anzeigt was Sie wollen und es halt schön billig war. :-(

In diesem Sinne,
Gruß Sono

[goth]

Wie wahr wie wahr ... PostgreSQL ist nur leider nicht sehr verbreitet ... gut auf meinen Server läuft's auch (wie auch MySQL 5.0) ... aber ich bin ja auch nicht Strato(t) ...

Mein Erfahrung mit Anti FOREIGN KEY Fetischisten bezog sich auf ein, für Bielefelder Verhältnisse, recht grosses Softwarehaus am Ort ... das sogar mit Oracle entwickelte ... derzeit habe ich mit ein paar Informix Freaks zu tun die ähnlich drauf sind ...

PS.: Als ich angefangen habe gab's nichtmal MySQL ...

[asp2php]

Original geschrieben von goth

PS.: Als ich angefangen habe gab's nichtmal MySQL ...

wenn ich mich nicht irre, es gab PHP auch noch nicht

[goth]

Das stimmt allerdings auffallend!

[Arni]

Mein Erfahrung mit Anti FOREIGN KEY Fetischisten bezog sich auf ein, für Bielefelder Verhältnisse, recht grosses Softwarehaus am Ort

Du meinst nicht E&S ??

[goth]

Nein ... aber ich nenne hier allerdings auch keine Namen ...

[sono]

Ich hab letzt was gelesen ,dass jemand eine "Schnitstelle" (keine Ahnung ob das jetzt der richtige Begriff) war schreiben will so das Postgres Mysql Sql kompatibel wird.

Vielleicht hilfts ja , aber andererseits , wenn jemand extra so eine Schnitstelle benötigt um mit Postgres zu arbeiten , dann sollte er vielleicht lieber bei MySql bleiben. Jemand der Postgres "benötigt" sollte auch damit umgehen können und für die Bedürftnisse des "Volks" reicht meist MySQL volkommen aus.

Dürfte allerdings für Massenhoster mit Webspace interessant werden falls das gut funktioniert und alle Scripte ohne Änderung laufen .

Wo wir gerade in der Nähe vom Thema sind ,
weiß eigentlich jemand wie das mit der Lizens bei MySQL ist.

Kostet das jetzt was oder doch nicht ? Ich hab da recht widersprüchliche Angaben bekommen .

Eine Info war das würde auf jeden Fall was kosten sobald man die Datenbank für Komerzielle Zwecke verwendet , jemand anderes hat gesagt nur der Support würde was kosten.

Bei MySQL selbst ist ja eigentlich auch nur die GPL dabei wenn ich die runterlade. ( mehr hab ich zumindest nicht entdeckt ).

Wisst ihr wie dass aussieht ?

Gruß Sono

[onemorenerd]

http://www.mysql.com/company/legal/licensing/