Formel für % ausrechnen

K

kneitzel

Wie meinst Du das?
Wenn Du z.B. nur die Felder von der Datenbank abfragen willst, die Du für einen Report brauchst. Dann wählt der User eine Reihe von Feldern und genau die willst Du nun abfragen. Das geht mit einem PreparedStatement erst einmal nicht.

Also User wählt aus: id und name, also soll ein select id, name from some_table; ausgeführt werden....
Oder von mir aus ist die Tabelle auch dyamisch, d.h. der User wählt Tabelle und Felder ....
 
Wenn Du z.B. nur die Felder von der Datenbank abfragen willst, die Du für einen Report brauchst. Dann wählt der User eine Reihe von Feldern und genau die willst Du nun abfragen. Das geht mit einem PreparedStatement erst einmal nicht.

Also User wählt aus: id und name, also soll ein select id, name from some_table; ausgeführt werden....
Oder von mir aus ist die Tabelle auch dyamisch, d.h. der User wählt Tabelle und Felder ....
Aber selbst dann würde man keine escaping sondern whitelisting nutzen, und kombinieren kann man das ja trotzdem mit Prepared Statements für die Parameter
 
Dann wählt der User eine Reihe von Feldern und genau die willst Du nun abfragen. Das geht mit einem PreparedStatement erst einmal nicht.
Ach so, das lösen wir durch dynamischen Aufbau des vorzubereitenden SQL-Statements (Felder und Parameterliste). Anschließend wird das als prepared Statement verwendet.
 
Also wenn ich nach meiner Expertenmeinung gefragt würde.... so würde ich sagen, den LAMP-Stack nicht einzusetzen.... einfach, weil jede einzelne Komponente hochfehlkonfigurable und somit unsicher ist....

Außerdem ist PHP iwie aus dem letzten Jahrtausend...
 
K

kneitzel

Bezüglich:
Aber selbst dann würde man keine escaping sondern whitelisting nutzen, und kombinieren kann man das ja trotzdem mit Prepared Statements für die Parameter
und:
Ach so, das lösen wir durch dynamischen Aufbau des vorzubereitenden SQL-Statements (Felder und Parameterliste). Anschließend wird das als prepared Statement verwendet.
Ich sehe das durchaus ähnlich. Daher hatte ich in meiner ursprünglichen Antwort die Relativierung gebracht:
Also dass es Fälle gibt, in denen Parameter nicht genutzt werden können, ist klar. Das kann z.B. der Fall sein, wenn man Felder dynamisch ansprechen will oder generell bei DDE. Aber da ist das auch nicht der in meinen Augen gewünschte Weg, denn beim Datenbank Design will ich in der Regel keine Namen mit speziellen Zeichen auch wenn dies prinzipiell gehen würde.
Wir haben in der Vergangenheit sowas in der Regel mit Stored Procedures gelöst. Aber das liegt daran, dass wir Datenbank nicht immer exklusiv für uns hatten, sondern wir eine Art "Data Warehousing" (Begriff passt nicht wirklich, aber so haben wir oft tituliert gegenüber Managern) betrieben haben und da waren die Schnittstellen nach außen immer nur Views und Stored Procedures.
(So hatten wir klar definierte Schnittstellen und wir konnten die Datenbank drunter beliebig erweitern und umstellen - so wir die Schnittstellen beibehalten haben!).

Und Daten wurden bei uns in der Regel immer als Parameter übergeben. Mir fällt jetzt gerade kein Fall ein, bei dem wir davon abgewichen sind.
 
K

kneitzel

Also wenn ich nach meiner Expertenmeinung gefragt würde.... so würde ich sagen, den LAMP-Stack nicht einzusetzen.... einfach, weil jede einzelne Komponente hochfehlkonfigurable und somit unsicher ist....

Außerdem ist PHP iwie aus dem letzten Jahrtausend...
Also gegen den LAMP Stack spricht nicht wirklich etwas. Man muss sich aber natürlich damit auskennen. Aber das trifft auf andere Lösungen ebenso zu (Windows, IIS oder FreeBSD oder irgend welche anderen Produkte).
Ich habe mit LAMP Stack auch sehr gute Erfahrungen gemacht. Aber man darf nicht jeden Scheiß auf den Rechner lassen. Bzw. wenn man sowas hat, dann sollte man das kapseln, so dass da nur im User-Bereich etwas passieren kann.

Aber das ist generell etwas, das sehr viel Know How Bedarf. Das hatten wir ja auch schon in anderen Threads wo es dann Richtung eigenen Server gibt und so. Ein Stichwort, das man gut googlen sollte, wäre Hardening. Also "Hardening Linux", "Hardening Apachae", ....
Jeder kleine Fehler kann sich sehr schnell und sehr böse bemerkbar machen.
Neben dem Hardening wäre noch Intrusion Detection - wenn etwas passiert, dann sollte man dies möglichst sofort mitbekommen.

Das aber nur einmal kurz am Rande als meine Sicht auf dieses Thema.
 
K

kneitzel

Ihr habt keine DML-Queries abgesetzt sondern alles über SPs gemacht? Das ist heftig. Views sind bei mir gern gesehene Gäste, mit SPs halte ich mich im Java EE-Umfeld allerdings zurück; die sind mir zu DB-abhängig :)
Ja, in dem Umfeld, in dem ich bis vor einem 3/4 Jahr tätig war, war das die normale Herangehensweise. Würde ich heute auch nicht so empfehlen. Die Lösung, die ich hier bevorzugen würde, wäre ganz klar eine Kapselung durch (Micro)Services.

Das ist bei uns aber nicht gemacht worden - und das obwohl das im .Net Umfeld lange der Standard Weg war. So etwas wie einen Application Server kennt man da ja eigentlich nicht, statt dessen war halt mit WCF schon zu .Net 2 (?) mit ganz wenig Code möglich, einen Webservice zu erstellen oder zu konsumieren...
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben