PHP und Datenbanken: Ansichten, Funktionen und gespeicherte Prozeduren Leistung

Question

Ich arbeite an einer PHP-Webanwendung mit PostgreSQL. Alle SQL-Abfragen werden aus dem PHP-Code aufgerufen. Ich habe keine Ansichten, Funktionen oder gespeicherte Prozeduren gesehen. Von dem, was ich gelernt habe, ist es immer besser, diese Datenbank Subroutinen zu verwenden, da sie in der Datenbank mit den Vorteilen gespeichert sind:

• Encapsulation
• Abstraktion
• Zugriffsrechte (begrenzt auf DB Admin) und Verantwortung
• vermeiden Kompilation

ich glaube, ich etwas über Leistungsverbesserungen zu lesen. Ich verstehe wirklich nicht, warum das Team diese noch nicht benutzt hat. In diesem speziellen Fall möchte ich aus Erfahrung wissen, gibt es einen guten Grund, sie NICHT zu benutzen?

Meistens, wenn es so viele "SELECT" -Abfragen entlang des Codes gibt, warum nicht Views verwenden?

Ich plane Refactoring des Codes und starten Sie die Programmierung der Subroutinen auf dem DB Server. Ich würde gerne Meinungen dafür oder dagegen wissen. Das Projekt ist ziemlich groß (viele Tabellen) und erwartet, dass viele Daten gespeichert werden. Die Menge an Daten, die du in einem sozialen Netzwerk mit etwas mehr Zeug haben würdest, also ja, ziemlich groß.

Answer 1

I. Ansichten bieten Kapselung, aber wenn nicht sorgfältig entworfen, können sie die Anwendung verlangsamen. Verwenden Sie mit Vorsicht.
II. Verwenden Sie Funktionen bei Bedarf, keinen Grund, sie einzufügen, wenn sie nicht benötigt werden.
III. Gespeicherte Prozeduren sind ein Geschenk des Himmels, benutze sie überall dort, wo es eine statische Anfrage gibt !!

Als Reaktion auf die Ansichten vs. Abfragen versuchen Ansichten zu verwenden, mit der gespeicherten Prozedur wird die gespeicherte Prozedur ist ein Teil der Performance-Einbußen mit meisten Blick genommen mildern.

Answer 2

Meiner Meinung nach sind Ansichten und gespeicherte Prozeduren in der Regel nur ein zusätzlicher Ärger mit wenig Nutzen.

Ich habe geschrieben und arbeitete mit einer Reihe von verschiedenen Web-Apps, obwohl keine mit bazillions von Benutzern. Die mit gespeicherten Prozeduren sind peinlich. Die mit Ad-hoc-SQL-Abfragen sind sehr schnell (Platzhalter und andere Best Practices verwenden, um SQL-Injection zu vermeiden). Meine bevorzugte Verwendung ist die Datenbankabstraktion (ORM), daher behandelt Ihr Code PHP-Klassen und -Objekte und nicht direkt mit der Datenbank. Ich habe mich zunehmend dem Symfony-Framework zugewandt.

Auch: im Allgemeinen sollten Sie nicht für Leistung vorzeitig optimieren. Optimiere jetzt für eine gute schnelle Entwicklung (keine gespeicherten Prozeduren). Wenn es funktioniert, benchmarken Sie Ihre App, finden Sie die Engpässe und optimieren Sie sie. Sie verschwenden nur Zeit und Komplexität, wenn Sie versuchen, von Anfang an zu optimieren.

Answer 3

Wir versuchen, die Funktionen, die Sie nur erwähnt zu verwenden, wo es ein signifikanter Vorteil

Teil der „Datenbank“ zu sein, sie fallen unter „Schemaänderungen“, anstatt
„Quellcode ändert sich ", und sind natürlich schwieriger Versionskontrolle.

Was auch immer Sie tun, stellen Sie sicher, dass Sie die volle Sichtbarkeit von "what-changed-what-when" beibehalten, so dass Sie im Fall von Problemen differenzieren, zurücksetzen und wiederherstellen können.

Answer 4

Der Vorteil von Stored Procedures ist, dass, weil die gesamte Verarbeitung in der Datenbank ausgeführt wird, keine Zwischenergebnissätze für das Netzwerk-Overhead-Shunting auftreten.

Der Nachteil ist, dass jedes RDBMS-System da draußen eine eigene Syntax für gespeicherte Prozeduren hat. Wenn Sie Ihre Geschäftslogik in gespeicherte Prozeduren implementieren, schränken Sie Ihre App auf ein einzelnes Datenbankprodukt ein, was Sie im Auge behalten sollten, wenn Sie beabsichtigen, dass Ihre Anwendung datenbankunabhängig ist. Wie Gahooa bereits ausgeführt hat, kann der Zugriff auf sie als Entwickler durch lokale Richtlinien eingeschränkt sein, da gespeicherte Prozeduren in der Datenbank gespeichert sind. Einige Organisationen lassen nur DBAs die Datenbank berühren.

@WolfmanDragon: Ich weiß nicht, ob Ansichten inhärent Dinge langsamer machen; Je nach Komplexität der Ansicht und des von Ihnen verwendeten RDBMS kann die Laufleistung variieren. Außerdem ermöglichen es einige RDBMS, häufig verwendete Ansichten zu materialisieren, so dass der Zugriff darauf genauso schnell ist wie eine Basistabelle.