höhere Performance durch direkte Abfragen

Kampfgummibaerlie

Kampfgummibaerlie

Datenbank-Guru
Beiträge
734
Einen schönen guten Abend!
Ich bin am denken, dass meine Datenbank noch auf das neueste gebracht werden könnte, durch das "ablösen" von diversen Insert- Update- Delete-Funktionen durch eine (im Programm oder auf der Homepage) direkte Eingabe zu lösen.

Der andere Gedanke wäre, dass es auch Speicherkapazität spart, was jedoch (bei mir) verdammt wenig wäre.

Also um ein Szenario zu beschreiben:
ich öffne die Homepage, und möchte eine neue Mietung eintragen, indem ich auf die Funktion zugreife, welche wiederum die Werte in eine Tabelle einträgt.
Wäre es hier nicht einfacher, die Funktion einfach durch eine Query ablösen kann, die auf Knopfdruck das insert direkt ausführt, und nicht auf eine Funktion zugreifen muss?

Meiner Meinung nach könnte ich dann eigentlich viele Funktionen auf diese Art ablösen....

Ich denke hier an die Worte von unserem mr. Elephant mit "Eine Funktion ist teuer", hier frage ich aber noch einmal nach, ob ich das "alles" entsprechend ändern sollte...

Mein entwickeltes Werk wird nicht in Betrieb gehen, aber ich möchte mich für die Zukunft weiterbilden, und frage daher, ob es sinnvoll wäre.
 
Werbung:
Kampfgummibaerlie schrieb:
Ich denke hier an die Worte von unserem mr. Elephant mit "Eine Funktion ist teuer", hier frage ich aber noch einmal nach, ob ich das "alles" entsprechend ändern sollte...
Zum Vergrößern anklicken....

Ich erinnere mich, ja. Du hast mal angefangen, für jede kleine Aktion eine eigene Funktion zu schreiben und in der Applikation diese zu verwenden. Kann man machen, ist aber irgendwie nicht sehr sinnvoll, weil es die Dinge (vermutlich) auch schwerer wartbar machen. Stored Procs sind schön, um bestimmte Geschäftslogig abzubilden, aber nicht wirklich Mittel der Wahl als Ersatz für ein simples INSERT.
 
Da erinnere ich mich auch gut dran, verstanden hab ich es nicht.

Für INSERTs sind vielleicht prepared statements interessant, aus Sicherheitsaspekten.
 
Ich weiß das ich hier wahrscheinlich einen Shit-Storm damit auslösen werde aber ich bin kein Fan davon Business Logik in die Datenbank zu packen. Für mich sollte im Gegensatz dazu die Datenbank das sein wofür sie mal entwickelt wurde. Eine Datenbank. Und damit auch einfach austauschbar und wartbar. Programmcode hat dadrin eigentlich überhaupt nichts verloren.
 
Thallius schrieb:
Ich weiß das ich hier wahrscheinlich einen Shit-Storm damit auslösen werde aber ich bin kein Fan davon Business Logik in die Datenbank zu packen.
Zum Vergrößern anklicken....
Kein Shitstorm von mir. Es gibt gute Argumente dafür und dagegen, das sehe ich bei unseren Kunden. Mit Business Logik in der DB nagelt man sich an die DB fest, das spüren viele Ora-Nutzer, die aus 'politischen' Gründen von Ora weg wollen und dies nur schwer können. Vorteilhaft ist aber, daß man u.U. massiv Performance gewinnt, wenn man die Logik in der DB macht. Ich weiß z.B., daß Zalando ihre komplette Warenwirtschaft in PG als StoredProcs abwickelt.
 
akretschmer schrieb:
Vorteilhaft ist aber, daß man u.U. massiv Performance gewinnt, wenn man die Logik in der DB macht. Ich weiß z.B., daß Zalando ihre komplette Warenwirtschaft in PG als StoredProcs abwickelt.
Zum Vergrößern anklicken....

Das liegt jetzt aber zu einem großen Teil daran, das heutzutage Application und db server nicht nur komplett getrennt werden sondern auch noch jeder Server mit soviel Security Kram abgesichert wird das 90% der performance dafür draufgeht statt einfach nur ein paar Daten auszutauschen, diese auch auf Viren zu checken und zu en- und decrypten
 
Naja, ich weiß nicht, was Du uns damit jetzt sagen willst. Trennung DB und APP ist schon immer eine gute Idee, Verschlüsselung auf der Leitung ebenso. Und meist kannst Du auch nicht erzwingen, daß DB und Anwender (mit seiner App) zusammen im Serverraum hocken...
 
Business Logik ist das eine, Datenintegrität das andere. Ich finde letzteres gehört auf jeden Fall in eine DB, ist aber selten bei Software die schon länger Markt ist. Ich habe hier nichts wo die Fremdschlüssel in der DB abgebildet werden und das Ergebnis sind häufig kaputte Daten.
 
akretschmer schrieb:
Naja, ich weiß nicht, was Du uns damit jetzt sagen willst. Trennung DB und APP ist schon immer eine gute Idee, Verschlüsselung auf der Leitung ebenso. Und meist kannst Du auch nicht erzwingen, daß DB und Anwender (mit seiner App) zusammen im Serverraum hocken...
Zum Vergrößern anklicken....

Früher standen aber die beiden Server immer irgendwo in einem Serverraum, verbunden mit einem Netzwerkkabel und waren nicht irgendwelche virtuellen Server in virtuellen Servern in virtuellen Server..... irgendwo auf der Welt.
 
ukulele schrieb:
Da erinnere ich mich auch gut dran, verstanden hab ich es nicht.

Für INSERTs sind vielleicht prepared statements interessant, aus Sicherheitsaspekten.
Zum Vergrößern anklicken....

Danke für die Idee ;)
Habe ich glaube ich schon einmal probiert (im Jahre Schnee und so), aber nie wirklich einprogrammiert... :(

Falls es jemand weiß, wie steigt die Sicherheit dadurch?
 
Durch prepared Statements definierst Du die exakte Struktur deines SQL-Befehls. Also das Grundgerüst und Platzhalter für variable Parameter. Später rufst Du das so 'prepared statement' nur noch mit den Parametern auf. Damit hast Du einen effektiven Schutz gegen SQL-Injection.

1657131793024.png
 
Werbung:
Es gibt so viele Möglichkeiten.

Eine Funktion kann ich immerhin als Interface sehen. Eine Handvoll Insert, Update, Delete Statements rein, ich kann transparent jede Modelländerung bedienen und bin damit für meinen Geschmack auch besser als irgendwelche kranken Trigger.
Apropos Trigger:
Wenn ich eine Funktion nehme, um Massenupdates zu machen, ist es ziemlich sicher suboptimal und viel langsamer als ein korreliertes Update.

Ich kann soweit gehen, die Business Logik da rein zu packen, komplett. Bietet sich vielleicht für heterogene Client Landschaften an oder für pure Performance. Egal welcher Client, alle machen es richtig (und so DB nah wie möglich, also schnell)
Ein App Server muss zwangsläufig Performance schlucken, der Datentransport, wie geschickt auch immer, kostet halt. Und ich hab schon gesehen, dass es ungeschickt gemacht wurde, selten zwar aber .. haha

Und wenn ich ne Open Source DB nehme, ist die größte Gefahr, dass ich auf einen Exot gesetzt habe, totes Pferd oder so. Ein Wechsel bedeutet ja auch nicht den Weltuntergang. Ich meine, davon geht keine Bedrohlichkeit aus.

App Server haben nebenbei genau das gleiche Problem wie eine DB oder jedes andere System, sie können aus der Mode kommen, veralten, …
Es soll ja kommerzielle Anbieter geben, die aus Strategiewechseln und neuen Tools einen Sport machen. Da bin ich auf jeden Fall schnell raus, egal ob App Server oder DB.
 
Zurück
Oben