it-swarm.com.de

Gespeicherte Prozeduren von MySQL verwenden sie oder verwenden sie nicht

Wir stehen am Beginn eines neuen Projekts und fragen uns wirklich, ob wir gespeicherte Prozeduren in MySQL verwenden sollten oder nicht.

Die gespeicherten Prozeduren würden wir nur zum Einfügen und Aktualisieren von Geschäftsmodellentitäten verwenden. Es gibt mehrere Tabellen, die eine Modellentität darstellen, und wir würden sie in diesen gespeicherten Prozeduren einfügen/aktualisieren.

Andererseits können wir insert und update aus der Model-Ebene aufrufen, jedoch nicht in MySQL, sondern in PHP.

Nach Ihrer Erfahrung Welches ist die beste Option? Vor- und Nachteile beider Ansätze. Welches ist das schnellste in Bezug auf Hochleistung?

PS: Es ist ein Webprojekt mit meistens gelesenem und hoher Leistung ist die wichtigste Voraussetzung.

56
Emilio Nicolás

Im Gegensatz zum eigentlichen Programmiersprachencode gilt Folgendes:

  • nicht portabel (jede Datenbank hat eine eigene Version von PL/SQL. Manchmal sind andere Versionen der Datenbank same inkompatibel - ich habe es gesehen!)
  • nicht leicht zu testen - Sie benötigen eine real (dev) -Datenbankinstanz, um sie zu testen. Daher ist es nahezu unmöglich, den Code eines Teilprogramms als Teil eines Builds zu testen
  • nicht leicht zu aktualisieren/freizugeben - Sie müssen sie löschen/erstellen, dh Modify die Produktionsdatenbank, um sie freizugeben
  • haben keine Bibliotheksunterstützung (warum Code schreiben, wenn jemand anderes hat)
  • sind nicht leicht in andere Technologien integrierbar (versuchen Sie, einen Webservice von ihnen aufzurufen)
  • sie verwenden eine Sprache, die ungefähr so ​​primitiv ist wie Fortran, und sind daher unelegant und mühsam, um eine nützliche Codierung durchzuführen. Daher ist es schwierig, Geschäftslogik auszudrücken, auch wenn dies normalerweise der Hauptzweck ist
  • debugging/Tracing/Message-Logging usw. nicht anbieten (einige Dbs unterstützen dies - ich habe es jedoch nicht gesehen)
  • es fehlt ein anständiger IDE, der bei der Syntax und beim Verknüpfen mit anderen vorhandenen Prozeduren hilft (z. B. wie bei Eclipse für Java).
  • menschen, die mit dem Codieren qualifiziert sind, sind seltener und teurer als App-Codierer
  • ihre "Hochleistung" ist ein Mythos, da sie auf dem Datenbankserver ausgeführt werden, den sie normalerweise Erhöhung der Db-Serverauslastung ausführen. Wenn Sie sie verwenden, wird der maximale Transaktionsdurchsatz in der Regel Verringerung
  • unfähigkeit, Konstanten effizient zu teilen (normalerweise gelöst durch Erstellen einer Tabelle und Abfragen innerhalb Ihrer Prozedur - sehr ineffizient)
  • usw.

Wenn Sie über eine sehr datenbankspezifische Aktion verfügen (z. B. eine In-Transaction-Aktion zur Aufrechterhaltung der Datenbankintegrität) oder Ihre Prozeduren sehr atomar und einfach halten, könnten Sie sie vielleicht in Betracht ziehen.

Vorsicht ist geboten, wenn Sie im Vorfeld "hohe Leistung" angeben. Dies führt oft zu schlechten Entscheidungen auf Kosten eines guten Designs und wird Sie viel früher beißen als Sie denken.

Verwenden Sie gespeicherte Prozeduren auf eigene Gefahr (von jemandem, der dort gewesen ist und niemals zurückkehren möchte). Meine Empfehlung ist, sie wie die Pest zu vermeiden.

58
Bohemian

Im Gegensatz zu Programmcode:

  • machen SQL-Injection-Angriffe fast unmöglich (sofern Sie es nicht sind.)
    Dynamisch konstruieren und ausführen
    SQL innerhalb Ihrer Prozeduren)
  • es muss weit weniger Daten über der IPC als Teil des Callouts gesendet werden
  • aktivieren Sie die Datenbank für weitaus bessere Cache-Pläne und Ergebnismengen (dies ist mit MySQL aufgrund der internen Zwischenspeicherung von Strukturen nicht so effektiv).
  • sind in isolierter Weise leicht überprüfbar. (d. h. nicht im Rahmen von JUnit-Tests)
  • sind portabel in dem Sinne, dass sie die Verwendung von db-spezifischen Features ermöglichen, die hinter einem -Prozedurnamen abstrahiert werden (im Code stecken Sie mit generischem SQL-Typ-Zeug)
  • sind fast nie langsamer als SQL vom Code aufgerufen

aber, wie Böhmisch sagt, gibt es auch viele Nachteile (dies ist nur eine Möglichkeit, eine andere Perspektive zu bieten). Sie müssen vielleicht einen Benchmark setzen, bevor Sie entscheiden, was für Sie am besten ist.

24
davek

Was die Performances angeht, haben sie das Potenzial, wirklich performant zu sein in einer zukünftigen MySQL-Version (unter SQL Server oder Oracle sind sie ein wahrer Genuss!). Für alle anderen ... Sie sprengen den Wettbewerb völlig in die Luft. Ich fasse zusammen:

  • Sicherheit: Sie können Ihrer App nur EXECUTE geben, alles ist in Ordnung. Ihr SP fügt update select ... ein, ohne dass irgendein Leck auftritt. Dies bedeutet globale Kontrolle über Ihr Modell und erzwungene Datensicherheit.

  • Sicherheit 2: Ich weiß, dass es selten ist, aber manchmal tritt PHP-Code vom Server aus (d. H. Wird für die Öffentlichkeit sichtbar). Wenn Ihre Abfragen darin enthalten sind, kennen mögliche Angreifer Ihr Modell. Das ist ziemlich seltsam, aber ich wollte es trotzdem signalisieren

  • Task Force: Ja, für die Erstellung effizienter SQL-SPs sind bestimmte Ressourcen erforderlich, die manchmal teurer sind. Wenn Sie jedoch glauben, dass Sie diese Ressourcen nicht benötigen, nur weil Sie Ihre Abfragen in Ihren Client integrieren, werden Sie ernsthafte Probleme haben. Ich möchte die Analogie zur Webentwicklung erwähnen: Es ist gut, die Ansicht vom Rest zu trennen, da Ihr Designer an seiner eigenen Technologie arbeiten kann, während sich die Programmierer auf die Programmierung der Business-Schicht konzentrieren können.

  • Einkapseln der Business-Schicht: Durch die Verwendung gespeicherter Prozeduren wird das Unternehmen, wo es hingehört, vollständig isoliert: die verdammte Datenbank.

  • Schnell testbar: Eine Befehlszeile unter Ihrer Shell und Ihr Code wird getestet.

  • Unabhängigkeit von der Client-Technologie: Wenn Sie morgen von PHP zu etwas anderem wechseln möchten, kein Problem. Ok, das Speichern dieser SQL-Dateien in einer separaten Datei würde den Trick auch tun, das ist richtig. Ein guter Punkt in den Kommentaren darüber, wenn Sie sich für den Wechsel der SQL-Engines entscheiden, hätten Sie viel Arbeit zu erledigen. Dafür müssen Sie ohnehin einen guten Grund haben, denn bei großen Projekten und großen Unternehmen geschieht dies selten (hauptsächlich aufgrund des Kosten- und Personalmanagements).

  • Erzwingen agiler 3 + -tier-Entwicklungen: Wenn sich Ihre Datenbank nicht auf demselben Server wie Ihr Clientcode befindet, haben Sie möglicherweise andere Server, aber nur einen für die Datenbank. In diesem Fall müssen Sie keinen Ihrer PHP-Server aktualisieren, wenn Sie den SQL-Code ändern müssen.

Ok, ich denke, das ist das Wichtigste, was ich zu diesem Thema sagen musste. Ich habe in beiden Spirits (SP vs client) entwickelt und ich liebe den SP Stil wirklich sehr. Ich wünschte nur, Mysql hätte ein echtes IDE für sie, weil es im Moment so ist ein schmerz in den arsch begrenzt.

13
Sebas

Gespeicherte Prozeduren sind gut zu verwenden, da sie Ihre Abfragen organisiert halten und einen Stapel gleichzeitig ausführen können. Gespeicherte Prozeduren werden normalerweise schnell ausgeführt, da sie im Gegensatz zu Abfragen, die bei jedem Lauf kompiliert werden, vorkompiliert werden. Dies hat erhebliche Auswirkungen auf Situationen, in denen sich die Datenbank auf einem Remote-Server befindet. Wenn sich Abfragen in einem PHP -Skript befinden, gibt es eine mehrfache Kommunikation zwischen der Anwendung und dem Datenbankserver. Die Abfrage wird gesendet, ausgeführt und das Ergebnis zurückgegeben. Bei Verwendung gespeicherter Prozeduren muss jedoch nur eine kleine CALL-Anweisung anstelle von großen, komplizierten Abfragen gesendet werden.

Es kann eine Weile dauern, sich an die Programmierung einer gespeicherten Prozedur anzupassen, da sie ihre eigene Sprache und Syntax hat. Wenn Sie sich erst einmal daran gewöhnt haben, werden Sie feststellen, dass Ihr Code wirklich sauber ist.

In Bezug auf die Leistung ist es möglicherweise kein bedeutender Gewinn, wenn Sie gespeicherte Prozeduren verwenden oder nicht.

7
Abhay

Ich werde meine Meinung mitteilen, obwohl meine Probleme möglicherweise nicht direkt mit der Frage zusammenhängen:

Wie in vielen Ausgaben ist die Antwort auf die Verwendung gespeicherter Prozeduren oder einer Lösung auf Anwendungsebene auf Fragen angewiesen, die den Gesamtaufwand bestimmen:

  • Was willst du bekommen? 

Versuchen Sie entweder Batch-Operationen oder Online-Operationen durchzuführen? sind sie vollständig transaktional? Wie wiederkehrend sind diese Operationen? Wie hoch ist die erwartete Arbeitslast für die Datenbank? 

  • Was Sie haben, um es zu bekommen.

Welche Art von Datenbanktechnologie haben Sie? Was für eine Infrastruktur? Ist Ihr Team vollständig in der Datenbanktechnologie geschult? Ist Ihr Team besser in der Lage, eine Datenbank-aegnostic-Lösung aufzubauen?

  • Zeit, es zu bekommen.

Keine Geheimnisse darüber.

  • Die Architektur.

Muss Ihre Lösung an mehreren Standorten verteilt werden? Ist Ihre Lösung für die Fernkommunikation erforderlich? Funktioniert Ihre Lösung auf mehreren Datenbankservern oder verwendet sie möglicherweise eine Cluster-basierte Architektur? 

  • Instandhaltung.

Wie viel muss die Anwendung ändern? Haben Sie speziell geschulte Personen für die Wartung der Lösung?

  • Änderungsmanagement.

Sehen Sie, dass sich Ihre Datenbanktechnologie in kurzer, mittlerer und langer Zeit ändern wird? sehen Sie, dass die Lösung häufig migriert werden muss?

  • Kosten

Wie viel kostet die Implementierung dieser Lösung mit der einen oder anderen Strategie?

Die Gesamtheit dieser Punkte wird die Antwort bestimmen. Sie müssen sich also um jeden dieser Punkte kümmern, wenn Sie sich entscheiden, ob Sie eine Strategie anwenden oder nicht. Es gibt Fälle, in denen die Verwendung gespeicherter Prozeduren besser ist als verwaltete Abfragen auf Anwendungsebene. In anderen Fällen ist es am besten, Abfragen durchzuführen und eine auf Anwendungsebene basierende Lösung zu verwenden. 

Die Verwendung von gespeicherten Prozeduren ist in der Regel angemessener, wenn:

  1. Ihre Datenbanktechnologie kann nicht kurzfristig geändert werden.
  2. Ihre Datenbanktechnologie kann parallelisierte Vorgänge, Tabellenpartitionen oder andere Strategien zur Aufteilung der Arbeitslast auf mehrere Prozessoren, Speicher und Ressourcen (Clustering, Grid) verarbeiten.
  3. Ihre Datenbanktechnologie ist vollständig in die gespeicherte Prozedurdefinitionssprache integriert, dh die Unterstützung liegt innerhalb der Datenbank-Engine.
  4. Sie haben ein Entwicklungsteam, das keine Angst vor der Verwendung einer Verfahrenssprache (3. Generation) hat, um ein Ergebnis zu erhalten.
  5. Vorgänge, die Sie erreichen möchten, sind in der Datenbank integriert oder werden unterstützt (Exportieren in XML-Daten, Verwalten der Datenintegrität und -kohärenz mit Triggern, geplanten Vorgängen usw.).
  6. Portabilität ist kein wichtiges Thema, und Sie bringen in kurzer Zeit einen Technologiewechsel in Ihrem Unternehmen an, auch wenn dies nicht wünschenswert ist. Im Allgemeinen wird Portabilität von den anwendungsorientierten und auf Schichten ausgerichteten Entwicklern als Meilenstein betrachtet. Aus meiner Sicht ist Portabilität kein Problem, wenn Ihre Anwendung nicht für mehrere Plattformen bereitgestellt werden muss, weniger, wenn keine Gründe für eine Technologiewechsel vorliegen oder der Aufwand für die Migration aller Unternehmensdaten größer ist als der Vorteil für eine Änderung. Was Sie durch den Einsatz eines anwendungsschichtgestützten Ansatzes (Portabilität) gewinnen können, können Sie an Leistung und Wert verlieren, die Sie aus Ihrer Datenbank erhalten ?).
  7. Leistung ist ein Problem. Erstens: In mehreren Fällen können Sie durch Verwendung eines einzelnen Aufrufs einer gespeicherten Prozedur bessere Ergebnisse erzielen als mehrere Datenanfragen aus einer anderen Anwendung. Darüber hinaus sind einige Merkmale, die Sie ausführen müssen, möglicherweise in Ihre Datenbank integriert, und ihre Verwendung ist hinsichtlich der Arbeitslast weniger kostspielig. Wenn Sie eine auf einer Anwendungsschicht basierende Lösung verwenden, müssen Sie die Kosten berücksichtigen, die für die Herstellung von Datenbankverbindungen, für Aufrufe der Datenbank, für den Netzwerkverkehr und für den Datenumbruch (dh für die Verwendung von Java oder .NET) entstehen Verwendung von JDBC/ADO.NET-Aufrufen, da Sie Ihre Daten in Objekte umhüllen müssen, die die Datenbankdaten darstellen, so dass die Instantiierung mit Kosten verbunden ist, die sich auf Verarbeitung, Speicher und Netzwerk beziehen, wenn Daten von außen kommen und nach außen gehen.

Die Verwendung von auf der Anwendungsschicht basierenden Lösungen ist in der Regel besser geeignet, wenn:

  1. Portabilität ist ein wichtiges Thema. 
  2. Die Anwendung wird an mehreren Standorten mit nur einem oder wenigen Datenbank-Repositorys bereitgestellt.
  3. Ihre Anwendung verwendet strenge geschäftsorientierte Regeln, die von der zugrunde liegenden Datenbanktechnologie unabhängig sein müssen.
  4. Sie haben vor, Technologieanbieter je nach Marktentwicklung und Budget zu ändern.
  5. Ihre Datenbank ist nicht vollständig in die Sprache der gespeicherten Prozedur integriert, die die Datenbank aufruft.
  6. Ihre Datenbankfähigkeiten sind begrenzt und Ihre Anforderungen gehen über das hinaus, was Sie mit Ihrer Datenbanktechnologie erreichen können.Ihre Anwendung kann die mit externen Anrufen verbundene Strafe unterstützen, ist geschäftsspezifisch eher transaktionsbasiert und muss das Datenbankmodell für die Benutzer auf ein Geschäftsmodell abstrahieren.
  7. Das Parallelisieren von Datenbankoperationen ist nicht wichtig. Außerdem verfügt Ihre Datenbank nicht über Parallelisierungsfunktionen.
  8. Sie verfügen über ein Entwicklungsteam, das nicht gut mit der Datenbanktechnologie vertraut ist und durch den Einsatz einer anwendungsorientierten Technologie produktiver ist.
  9. Ich hoffe, dass dies jedem helfen kann, der sich fragt, was besser zu gebrauchen ist.

Hope this may help to anyone asking himself/herself what is better to use.

5
Enyix Mexico

Ich würde empfehlen, dass Sie keine gespeicherten Prozeduren verwenden:

  • Ihre Sprache in MySQL ist sehr beschissen
  • Es gibt keine Möglichkeit, Arrays, Listen oder andere Arten von Datenstrukturen in eine gespeicherte Prozedur zu senden 
  • Eine gespeicherte Prozedur kann nicht ever ihre Schnittstelle ändern. MySQL erlaubt weder benannte noch optionale Parameter
  • Die Bereitstellung neuer Versionen Ihrer Anwendung wird dadurch komplizierter - beispielsweise, Sie haben 10x Anwendungsserver und 2 Datenbanken. Welche Updates werden zuerst durchgeführt?
  • Ihre Entwickler müssen alle die Sprache der gespeicherten Prozeduren lernen und verstehen - was sehr scheiße ist (wie ich bereits erwähnt habe).

Stattdessen empfehle ich, eine Schicht/Bibliothek zu erstellen und alle Ihre Abfragen dort zu platzieren

Sie können

  • Aktualisieren Sie diese Bibliothek und versenden Sie sie mit Ihrer App auf Ihren App-Servern
  • Lassen Sie umfangreiche Datentypen wie Arrays, Strukturen usw. herum
  • Testen Sie diese Bibliothek anstelle der gespeicherten Prozeduren.

Auf leistung:

  • Die Verwendung gespeicherter Prozeduren verringert die Leistung Ihrer Anwendungsentwickler. Dies ist die Hauptsache, die Sie interessieren.
  • Es ist äußerst schwierig, Leistungsprobleme in einer komplizierten gespeicherten Prozedur zu erkennen (es ist bei einfachen Abfragen viel einfacher).
  • Sie können einen Abfragestapel in einem einzelnen Block über die Leitung senden (wenn das Flag CLIENT_MULTI_STATEMENTS aktiviert ist). Dies bedeutet, dass Sie ohne gespeicherte Prozeduren keine Latenz mehr erhalten.
  • Anwendungsseitiger Code skaliert im Allgemeinen besser als datenbankseitiger Code
3
MarkR

Wenn Ihre Datenbank komplex ist und kein Formentyp mit Antworten ist, ist True Warehousing SP definitiv von Vorteil. Sie können Ihre gesamte Geschäftslogik da rausbringen und kein Entwickler wird sich darum kümmern, sie nennen nur Ihre SPs. Ich habe das gemacht, über 15 Tische zu verbinden, macht keinen Spaß, und einem neuen Entwickler kann man das nicht erklären.

Entwickler haben auch keinen Zugriff auf eine Datenbank, großartig! Überlassen Sie das den Datenbank-Entwicklern und Betreuern. Wenn Sie auch entscheiden, dass die Tabellenstruktur geändert werden soll, können Sie diese hinter Ihrer Schnittstelle ausblenden. n-Tier, denk dran?

Hohe Performance und relationale DBs passen nicht zusammen, auch wenn MySQL InnoDB nicht langsam ist, sollte MyISAM jetzt aus dem Fenster geworfen werden. Wenn Sie Leistung mit einer Web-App benötigen, benötigen Sie einen geeigneten Cache, Memcache oder andere.

in Ihrem Fall würde ich, da Sie "Web" erwähnt haben, keine gespeicherten Prozeduren verwenden. Wenn es sich um ein Data Warehouse handelt, würde ich es definitiv in Betracht ziehen (wir verwenden SPs für unser Warehouse).

Tipp: Da Sie Web-Projekt erwähnt haben, schon immer über eine Lösung von nosql? Außerdem benötigen Sie eine schnelle Datenbank. Warum verwenden Sie nicht PostgreSQL? (versucht hier zu befürworten ...)

2
R. van Twisk

Ich benutzte MySql und mein Verständnis von SQL war im besten Fall schlecht. Ich habe ziemlich viel Zeit mit SQL Server verbracht.

Ich habe mich manchmal frustriert gefühlt, wenn kein ORM verwendet wurde, da die Entwicklung mit gespeicherten Prozeduren sehr schnell ist und viel langsamer ist. Ich denke, ein Großteil unserer Arbeit hätte durch den Einsatz eines ORM beschleunigt werden können.

Wenn Ihre Anwendung eine kritische Masse erreicht, leidet die ORM-Leistung. Eine gut geschriebene gespeicherte Prozedur führt zu einem schnelleren Ergebnis.

Als Leistungsbeispiel sammle ich 10 verschiedene Datentypen in einer Anwendung, konvertiere diese dann in XML, das ich in der gespeicherten Prozedur verarbeite. Ich habe statt der 10 einen Aufruf an die Datenbank.

SQL ist wirklich gut im Umgang mit Datensätzen. Eine Sache, die mich frustriert, ist die Tatsache, dass jemand Daten von SQL in einer Rohform erhält und Anwendungscode zum Durchlaufen der Ergebnisse und zum Formatieren und Gruppieren der Daten verwendet . 

Mein Rat ist, SQL genug zu lernen und zu verstehen und Ihre Anwendungen werden wirklich von Nutzen sein.

2
Charles Bryant

Viele Informationen hier, um die Leute zu verwirren, Softwareentwicklung ist eine Evolution. Was wir vor 20 Jahren gemacht haben, ist jetzt keine Best Practice. Damals mit klassischen Client-Servern würden Sie nichts anderes als SPs träumen. 

Es sind absolut Pferde für Kurse. Wenn Sie eine große Organisation sind, werden Sie mehrstufig und wahrscheinlich SPs einsetzen, aber Sie werden sich wenig um sie kümmern, da ein engagiertes Team sie aussortiert.

Das Gegenteil ist der Punkt, an dem ich versuche, schnell eine Web-App-Lösung aufzuschlagen, die die Geschäftsanforderungen konkretisiert. Es war superschnell, dem Entwickler (entfernt von mir) die Seiten und SQL-Abfragen zu überlassen, und ich definiere die Datenbank Struktur. 

Die Komplexität nimmt jedoch zu und ohne einen einfachen Weg, APIs bereitzustellen, stelle ich mir vor, SPs zu verwenden, um die Geschäftslogik zu enthalten. Ich denke, es funktioniert gut und vernünftig. Ich kontrolliere das, weil ich Logik aufbauen kann und einen einfachen Ergebnissatz für meinen Offshore-Entwickler bereitstellen kann, um ein Front-End zu schaffen.

Sollte meine Software einen phänomenalen Erfolg haben, wird es zu einer stärkeren Trennung der Anliegen kommen, und es werden verschiedene Implementierungen von n teir zustande kommen, aber für jetzt sind SPs perfekt. 

Sie sollten alle Werkzeugsätze kennen, die Ihnen zur Verfügung stehen, und es ist ratsam, sie zusammenzustellen. Wenn Sie nicht zuerst ein Unternehmenssystem erstellen, ist dies am besten schnell und einfach.

1
Richard

Ich würde empfehlen, dass Sie sich nicht an DB-spezifische gespeicherte Prozeduren halten.

Ich habe eine Menge Projekte durchlaufen, bei denen sie plötzlich die DB-Plattform wechseln möchten und der Code in einem SP normalerweise nicht tragbar ist = zusätzliche Arbeit und mögliche Fehler.

Die Entwicklung gespeicherter Prozeduren erfordert auch, dass der Entwickler direkt auf die SQL-Engine zugreifen kann, wobei eine normale Verbindung von jedem im Projekt nur mit Codezugriff geändert werden kann.

In Bezug auf die Idee von Model/Layer/Tier: Ja, bleib dabei.

  • Website ruft Business Layer (BL) auf
  • BL ruft Datenschicht (DL) auf
  • DL ruft jeden beliebigen Speicher auf (SQL, XML, Webservice, Sockets, Textdateien usw.)

Auf diese Weise können Sie den Logikpegel zwischen den Ebenen beibehalten. WENN und NUR WENN die Aufrufe von DL sehr langsam zu sein scheinen, können Sie anfangen, mit gespeicherten Prozeduren herumzuspielen, aber den ursprünglichen SP-Code irgendwo beibehalten, wenn Sie die Datenbank plötzlich auf eine völlig neue Plattform übertragen müssen . Mit all dem Cloud-Hosting der Branche wissen Sie nie, was die nächste DB-Plattform wird ...

Ich habe Amazon AWS aus demselben Grund genau im Auge.

1
BerggreenDK

Ich denke, es gibt eine Menge falscher Informationen über in der Datenbank gespeicherte Abfragen.

Ich würde die Verwendung von MySQL Stored Procedures empfehlen, wenn Sie viele statische Abfragen zur Datenmanipulation durchführen. Vor allem, wenn Sie Dinge von einem Tisch zu einem anderen verschieben (d. H. Von einem Live-Tisch zu einem historischen Tisch, aus welchem ​​Grund auch immer). Nachteile bestehen natürlich darin, dass Sie ein separates Protokoll der Änderungen an ihnen führen müssen (theoretisch könnten Sie eine Tabelle erstellen, die nur Änderungen an den gespeicherten Prozeduren enthält, die vom DBA aktualisiert werden). Wenn Sie viele verschiedene Anwendungen mit der Datenbank verbinden, insbesondere wenn Sie ein in C # geschriebenes Desktop-Programm und ein Web-Programm in PHP haben, kann es vorteilhafter sein, einige Ihrer Prozeduren in der Datenbank zu speichern, da sie plattformunabhängig sind. 

Diese Website enthält einige interessante Informationen, die Sie möglicherweise nützlich finden.

https://www.sitepoint.com/stored-procedures-mysql-php/

Bauen Sie wie immer zuerst eine Sandbox ein und testen Sie. 

0
Dave Babler