Puccini

Hi,

mir brennt da ne frage untern den fingernägeln

was ist besser um logik für ein projekt abzubilden? PHP oder SQL?

ein freund von mir is der übelste sql pro, macht fast nur alles damit, klappt auch alles super, aber ich als php-entwickler finde es schöne, richtigen code und funktonen zu haben.

also zum sachverhalt:

er prüft und validiert alles mittels sql, erzeugt alle nachrichten und was weis ich...

wenn ich das machen würde, gäb es vieleicht einen select und einen insert/update, der rest würde in php abgebildert.

was ist da besser?

SQL ist sicher performat, aber wenn das projekt gross wird und viel last erzeugt, wäre doch php besser, da man das clustern kann oder?

wie seht ihr das?

Mister Ad

Flor1an

Allein prüfen und Validieren ist schon mal problematisch. Denn die Daten müssen überprüft werden BEVOR sie in einen Datenbankquery geschrieben werden. Macht für mich auch keinen Sinn die Anwendungslogik in die Datenbank zu drücken.

KarlEgon

Berechnungen usw. können sicherlich von der Datenbank übernommen werden, aber das überprüfen von Daten würde ich auch in PHP abbilden.

Flor1an

Ich denke es kommt immer auf den Anwendungsfall darauf an. Datum formatieren kann MySQL gerne machen, einfache Rechnungen zwischen den Spalten von mir aus auch. Sobald dann Kontrollstrukturen mit rein kommen muss man sich überlegen ob es Sinn macht.

tkausl

man muss es in grenzen halten. SQL hat seine aufgaben genau wie PHP
wenn man mehrere tabellen hat und von jeder einige daten braucht ist es sicher besser SQL die teile zusammenpacken zu lassen als mit php alle tabellen einzeln abzurufen.

Dark Guardian

Wenn man gemäß MVC Muster vorgeht dann hat die Logik in der Datenbank nichts zu suchen.

Aber man kann es sich auch vom Namen herleiten: DATENbank, nicht Logikbank!

Die Datenbank ist zum speichern und abfragen von Daten da, nicht zum Ausführen komplexer Anwendungslogik.

Empfinde ich shcon wieder grenzwertig. Die Formatierung von Daten ist eigentlich nicht Aufgabe der Datenbank sondernd er View.

Da hingegen stimme ich zu. Dafür ist es ja auch da, z.B. maxima/minima ermitteln, zählen etc. fällt ja alles unter Abfrage der bestehenden Daten.

@TE
Ein schönes Beispiel ist Vor/Nachname.

Ich könnte meinen Select so absetzen das ich nur das Feld "name" erhalte welches eine Kombination der Felder Vorname und Nachname darstellt.

Dann brauch ich ja weniger PHP! Nachteil: Wenn ich z.B. Herr Meyer anzeigen lassen will muss ich erst wieder umständlich den Namen teilen. Wenn ich alle drei "name_komplett", "vorname", "nachname" ausgebe erzeuge ich ggf. nicht benötigten Overhead wenn "name_komplett" in meiner Ausgabe gar nicht benötigt wird.

Gebe ich nur "vorname" "nachname" aus bleibt es der Anwendung überlassen was dargestellt wird (ein Social Network würde warscheinlich nur "vorname" ausgeben, eine proeffsionelle Werbeseite "herr nachname" und ein Newsletter warscheinlich "vorname nachname").

Das Ziel beim Programmieren ist es ja sich Arbeit zu ersparen. Wenn ich nun Software schreibe die nicht wiederverwendbar ist und ich für jede Anwendung alle SQL-Befehle überarbeiten muss (weil das Format der Daten nicht passt) dann mache ich definitiv etwas verkehrt.

__________________
Truthähne starren während schwerer Regenfälle oft in den Himmel und ertrinken.

dennis81

Stell dir mal vor was passiert, wenn du die Datenhaltung änderst
Dann steht Mr. SQL aber auf'm Schlauch.

__________________
Es ist schon alles gesagt! Nur noch nicht von allen! (Karl Valentin)
Wenn du eine weise Antwort verlangst, musst du vernünftig fragen. (Johann Wolfgang von Goethe)

Puccini

hmm, das will er aber net verstehen XD

das mit den einfachen aufgaben ist mir klar, dafür sind ja auch die funktionen im sql supi!

aber er macht sehr komplizierte views da, hat (weis net wie das heist) "event's" drin, die reagieren, sobald sich ein wert einer spalte ändert und dann ausgaben/log's erzeugen etc.

ich finde, sowas sollte ins php, da dort ja wie ihr shcon sagt die logik sitzen sollte.

Das mit dem validieren ist mir auch ein echter dorn im auge! selbst wenn wir es via prepared statement laufen lassen, ist nicht sichergestellt das wirklich alles sicher ist da is es einfacher erst im php zu prüfen und dann das sql zu bemühen.



danke schonmal für eure antworten.

Habt ihr noch anregungen/tipps/erfahrungswerte bezüglich der Performance, sobald es ans eingemachte geht? (wir rechnen mit ca 500-1000 aktiven Nutzern gleichzeitig zu spitzenzeiten (ich weis, is kein ding ala facebook oder wie sie alle heisen, aber für uns shcon viel ))

Dark Guardian

Du meinst Trigger.

Das ist ja wieder was anderes. Wenn ich Zusammenhängende Daten auf mehrere Tabellen aufteile und sich in einer Tabelle etwas ändert ist es, je nach Fall, schon sinnvoll mit einem Trigger direkt in der zweiten Tabelle die Daten mit zu ändern.

Das ist ja alles noch i.O. Aber sobald das Ändern der Daten der zweiten Tabelle an erneute Bedingungen geknüpft ist wird es schon was anderes.

Um mal ein Beispiel zu nennen:

Ich habe Benutzer und Gruppen. Wenn ich einen Benutzer anlege und dem per Texteingabe eine Gruppe mitgebe und diese noch nicht existiert soll sie angelegt werden. Lässt sich schön in SQL abbilden und nimmt dem Benutzer Aufwand ab.

Ich lösche den letzten Benutzer aus einer Gruppe und möchte eine Option haben die Gruppe dann direkt mit zu löschen. Wohlgemerkt die OPTION. Ich kann das auch in SQL abbilden mittels Kontrollstrukturen aber dann kann ich von außerhalb keinen Einfluss mehr darauf nehmen das die Datenbank den Trigger auslöst. womit die Wiederverwertbarkeit der Anwendung abnimmt.

__________________
Truthähne starren während schwerer Regenfälle oft in den Himmel und ertrinken.

mepeisen

Eine Diskussion ist sicherlich nett aber jeder hier hat Recht. Warum? Weil es wirklich nur auf den Anwendungsfall drauf an kommt. Aber nicht nur auf diesen. Die Themen Performance, Datenmodellierung und Aufwand sind so eng verwoben, dass man nie eine pauschale Aussage treffen kann. Wenn man also erwartet, von einem Beispiel sofort einen allgemeinen Lehrsatz herzuleiten, der wird sich noch arg wundern, wenn das in der Praxis fast nie funktioniert. Dazu sind die Einflussfaktoren zu komplex.

Das ist noch einer der intelligentesten Sätze, die hier gefallen sind. Jedoch kannst du auch diesen Satz nie so genau auf jeden Fall umsetzen. Logik aus der Datenbank wegzulassen ist nicht immer der Weisheit letzter Schluss.
Manches mal muss man Logik ins SQL schreiben, weil du dadurch zwar den SQL etwas langsamer machst und komplizierter, dennoch aber beispielsweise die Menge der Daten auf einen bruchteil reduzieren kannst.
Manches mal muss man Logik aus dem SQL rauslassen, weil die Datenbank diese Logik zu aufwändig verarbeiten wird, die Anwendung aber deutlich effizientere Algorithmen anwenden kann.
Manches mal muss man sein Datenmodell anpassen und bewusst von der Normalisierung abweichen, nur um eine Anwendungslogik möglichst effizient und mit wenig Code abbilden zu können.

Vieles ist hier schon andeutungsweise gefallen. Eine pauschale Antwort auf diese Dikussion gibts nicht. Ihr habt alle Recht

__________________
Entwickler aus Leidenschaft und ein Zahnrad in einem der größten Java-Projekte der Welt.
Kostenlos-Webspace zu Weihnachten

Mister Ad