Berechnungen in MySQL vs. PHP durchführen

Ich würde die Stärken jedes Systems ausspielen.

Die Aggregations-, Verbindungs- und Filterlogik gehört offensichtlich auf die Datenschicht. Es ist schneller, nicht nur, weil die meisten DB-Engines über mehr als 10 Jahre Optimierung dafür verfügen, sondern Sie minimieren auch die Daten, die zwischen Ihrer DB und Ihrem Webserver verschoben werden.

Andererseits haben die meisten DB-Plattformen, die ich verwendet habe, eine sehr schlechte Funktionalität für die Arbeit mit einzelnen Werten. Dinge wie Datumsformatierung und String-Manipulation saugen in SQL einfach auf, Sie erledigen diese Arbeit besser in PHP.

Verwenden Sie grundsätzlich jedes System für das, wofür es gebaut wurde.

In Bezug auf die Wartbarkeit, solange die Trennung zwischen dem, was wo passiert, klar ist, sollte die Trennung dieser Logiktypen keine großen Probleme verursachen und sicherlich nicht genug, um die Vorteile zunichte zu machen. Meiner Meinung nach geht es bei Code-Klarheit und Wartbarkeit mehr um Konsistenz als darum, die gesamte Logik an einem Ort unterzubringen.

Betreff:konkrete Beispiele...

1. Ich weiß, dass Sie sich auch nicht darauf beziehen, aber Daten sind fast ein Sonderfall. Sie möchten sicherstellen, dass alle vom System generierten Daten entweder auf dem Webserver ODER in der Datenbank erstellt werden. Andernfalls werden einige heimtückische Fehler verursacht, wenn der DB-Server und der Webserver jemals für unterschiedliche Zeitzonen konfiguriert sind (ich habe dies gesehen). Stellen Sie sich zum Beispiel vor, Sie haben ein createdDate Spalte mit dem Standardwert getDate() die beim Einfügen von der DB angewendet wird . Wenn Sie dann einen Datensatz einfügen würden, verwenden Sie ein in PHP generiertes Datum (z. B. date("Y-m-d", time() - 3600) , Datensätze auswählen, die in der letzten Stunde erstellt wurden, erhalten Sie möglicherweise nicht das, was Sie erwarten. Was die Ebene betrifft, auf der Sie dies tun sollten, würde ich die DB bevorzugen, da Sie im Beispiel Spaltenvorgaben verwenden können.

2. Für die meisten Apps würde ich dies in PHP tun. Das Kombinieren von Vor- und Nachnamen klingt einfach, bis Sie feststellen, dass Sie manchmal auch Anreden, Titel und mittlere Initialen benötigen. Außerdem werden Sie mit ziemlicher Sicherheit in eine Situation geraten, in der Sie den Vornamen, den Nachnamen UND eine Kombination aus Anrede + Vorname + Nachname des Benutzers wünschen. Wenn Sie sie auf der DB-Seite verketten, bedeutet dies, dass Sie am Ende mehr Daten verschieben, obwohl es wirklich ziemlich wenig ist.

3. Hängt ab. Wie oben, wenn Sie sie jemals separat verwenden möchten, ist es leistungsmäßig besser, sie separat herauszuziehen und bei Bedarf zu verketten. Das heißt, es sei denn, die Datensätze, mit denen Sie es zu tun haben, sind riesig, es gibt wahrscheinlich andere Faktoren (wie, wie Sie erwähnt haben, Wartbarkeit), die eine größere Bedeutung haben.

Ein paar Faustregeln:

• Das Generieren inkrementeller IDs sollte in der Datenbank erfolgen.
• Persönlich mag ich meine Standardeinstellung, die von der Datenbank angewendet wird.
• Bei der Auswahl sollte alles, was die Anzahl der Datensätze reduziert, von der DB erledigt werden.
• Es ist normalerweise gut, Dinge zu tun, die die Größe des Datensatzes auf der DB-Seite reduzieren (wie bei dem String-Beispiel oben).
• Und wie du sagst; Reihenfolge, Aggregation, Unterabfragen, Verknüpfungen usw. sollten immer DB-seitig sein.
• Außerdem haben wir nicht darüber gesprochen, aber Auslöser sind normalerweise schlecht/notwendig.

Es gibt ein paar grundlegende Kompromisse, denen Sie hier gegenüberstehen, und das Gleichgewicht hängt wirklich von Ihrer Anwendung ab.

Einige Dinge sollten unbedingt – immer – immer in SQL erledigt werden. Das Ausschließen einiger Ausnahmen (wie das Datumsding) für viele Aufgaben kann SQL sehr klobig sein und Sie mit Logik an abgelegenen Stellen zurücklassen. Beim Durchsuchen Ihrer Codebasis nach Verweisen auf eine bestimmte Spalte (zum Beispiel) ist sie leicht zu übersehen, die in einer Ansicht oder gespeicherten Prozedur enthalten sind.

Leistung ist immer eine Überlegung, aber je nach App und spezifischem Beispiel vielleicht keine große. Ihre Bedenken bezüglich der Wartbarkeit und wahrscheinlich sehr berechtigt, und einige der Leistungsvorteile, die ich erwähnt habe, sind sehr gering, also hüten Sie sich vor vorzeitiger Optimierung.

Auch wenn andere Systeme direkt auf die DB zugreifen (z. B. für Berichte oder Importe/Exporte), profitieren Sie von mehr Logik in der DB. Wenn Sie beispielsweise Benutzer direkt aus einer anderen Datenquelle importieren möchten, wäre so etwas wie eine wiederverwendbare E-Mail-Validierungsfunktion in SQL implementiert.

Kurze Antwort:Es kommt darauf an. :)