Perfomaceverlust bei Check Constaints

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Perfomaceverlust bei Check Constaints

    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
    Zuletzt geändert von sono; 09.01.2006, 14:54.

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

    [color=blue]Bitte keine Fragen per EMail ... im Forum haben alle was davon ... und ich beantworte EMail-Fragen von Foren-Mitgliedern in der Regel eh nicht![/color]
    [color=red]Hinweis: Ich bin weder Mitglied noch Angestellter von ebiz-consult! Alles was ich hier von mir gebe tue ich in eigener Verantwortung![/color]

    Kommentar


    • #3
      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

      Kommentar


      • #4
        Original geschrieben von goth
        unter MySQL gibt's absolut keinen Performance Verlust für CHECK Constraints ... !
        @sono: Hast du das mal geCHECKt?

        Kommentar


        • #5
          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) ...
          Zuletzt geändert von goth; 09.01.2006, 22:02.
          carpe noctem

          [color=blue]Bitte keine Fragen per EMail ... im Forum haben alle was davon ... und ich beantworte EMail-Fragen von Foren-Mitgliedern in der Regel eh nicht![/color]
          [color=red]Hinweis: Ich bin weder Mitglied noch Angestellter von ebiz-consult! Alles was ich hier von mir gebe tue ich in eigener Verantwortung![/color]

          Kommentar


          • #6
            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

            Kommentar


            • #7
              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 ...
              carpe noctem

              [color=blue]Bitte keine Fragen per EMail ... im Forum haben alle was davon ... und ich beantworte EMail-Fragen von Foren-Mitgliedern in der Regel eh nicht![/color]
              [color=red]Hinweis: Ich bin weder Mitglied noch Angestellter von ebiz-consult! Alles was ich hier von mir gebe tue ich in eigener Verantwortung![/color]

              Kommentar


              • #8
                Original geschrieben von goth

                PS.: Als ich angefangen habe gab's nichtmal MySQL ...
                wenn ich mich nicht irre, es gab PHP auch noch nicht

                Kommentar


                • #9
                  Das stimmt allerdings auffallend!
                  carpe noctem

                  [color=blue]Bitte keine Fragen per EMail ... im Forum haben alle was davon ... und ich beantworte EMail-Fragen von Foren-Mitgliedern in der Regel eh nicht![/color]
                  [color=red]Hinweis: Ich bin weder Mitglied noch Angestellter von ebiz-consult! Alles was ich hier von mir gebe tue ich in eigener Verantwortung![/color]

                  Kommentar


                  • #10
                    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 ??
                    Bei Risiken und Nebenwirkungen fragen Sie Dr.Alban

                    Kommentar


                    • #11
                      Nein ... aber ich nenne hier allerdings auch keine Namen ...
                      carpe noctem

                      [color=blue]Bitte keine Fragen per EMail ... im Forum haben alle was davon ... und ich beantworte EMail-Fragen von Foren-Mitgliedern in der Regel eh nicht![/color]
                      [color=red]Hinweis: Ich bin weder Mitglied noch Angestellter von ebiz-consult! Alles was ich hier von mir gebe tue ich in eigener Verantwortung![/color]

                      Kommentar


                      • #12
                        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
                        Zuletzt geändert von sono; 11.01.2006, 00:34.

                        Kommentar


                        • #13
                          http://www.mysql.com/company/legal/licensing/

                          Kommentar

                          Lädt...
                          X