Was genau meinst du mit Berechnungen und Abhängigkeiten? Sowas wird ja dann normalerweise auf Programmebene und nicht in der Datenbank gemacht. Oder verstehe ich da jetzt etwas grundlegend falsch?
genau. Und hier macht es eben einen großen Unterschied ob du da mit Queries hantieren musst:
summe := qryRechnung.FieldByName('Skonto').AsCurrency * qryPosition.FieldByName('Anzahl').AsCurrency * qryPosition.FieldByName('Einzelpreis').AsCurrency;
oder ob du Objekte zur Verfügung hast
summe := Rechnung.Skonto * Positon.Anzahl * Position.Einzelpreis;
daher: Nimm dir ein, zwei Tage Zeit und schau dir die Thematik an.
Hmm. Muss ich mir dann doch mal anschauen. Bisher habe ich mir immer direkt meine eigenen Klassen geschrieben und die Daten dann dort in einzeln angelegten Objekten gespeichert. Hatte den Vorteil, dass ich sehr einfach darauf zugreifen konnte.
Mit Feldern aus einer
Query arbeite ich schon lange nicht mehr. Viel zu Umständlich. Eine Klasse hat eben zusätzlich noch die nette Eigenschaft, dass ich eine Funktion aufrufen kann, die die Daten direkt aufbereitet so wie ich sie benötige.
Freiheiten bei Modelländerungen erhält man nicht nur durch SP, sondern auch durch die Nutzung von Views, statt (komplexen)
SQL Anweisungen.
Bei Views habe ich eben das Problem, dass ich keine Filter von außen mitgeben kann. Eine View ist ja soweit ich weiß statisch. Bei einer SP kann ich noch Parameter angeben welche dann in einer WHERE Klausel verarbeitet werden können. Bei meinem DMS wüsste ich nicht, welche Daten ich ohne Filter einfach so selektieren kann. Außer eventuell alle angelegten Benutzer um auf einem LoginScreen diese in einer Combobox anzeigen zu lassen.
Wenn ich jetzt gezielter drüber nachdenken würde, dann würden sich bestimmt noch die ein oder anderen Abfragen finden die per View erstellt werden könnten, aber so spontan fällt mir da nicht mehr ein. Aber Views sind nicht per se aus meinem Konzept gestrichen. Da wo ich sie benutzen kann, da werde ich sie auch nutzen.
Das Thema Testing und Testdaten sehe ich so, dass es am besten in der
DB aufgehoben ist. Gerade SP und ein paar Scripte und die Nutzung von Transaktionen (Commit/Rollback) erlauben es, extrem schnell und viel Testdaten zu generieren und Tests zu durchlaufen. Im Zweifel sogar im laufenden Betrieb (kann man sich vielleicht firmenintern erlauben, natürlich hat man normalerweise Testsysteme dafür)
SP lohnen sich m.E. vor allem dann, wenn man die Fähigkeiten der
DB ausreizen will und die können recht groß sein, zb. auch bei MS
SQL, wenn ich das richtig verstanden habe.
Insbesondere das Thema DMS stelle ich mir hier ganz spannend vor, weil es auf einem MS Server mit MS Dokumentensoftware (also Word und Excel und Co) ziemlich viel serverseitige Dienste erlaubt.
Ansonsten vielleicht doch eher ORM oder ein "fertiges" OpenSource System erweitern.
P.S:Wenn mal ein weiteres Clientsystem hinzukommen soll, bspw. Webportal Extranet DMS, dann sind SP natürlich sehr gut geeignet.
Mit
MSSQL liegst du richtig. Siehe meinen Ausgangspost.
An ein Webportal ist aktuell noch nicht zu denken. In unserer Firma arbeiten 100% der Benutzer an einem Windows PC. Mit Tablets oder Smartphones á la BYOD haben wir hier noch nix am Hut. Rein aus sicherheitstechnischen Gründen.
Ich muss aber zugeben das ich bereits daran gedacht habe, irgendwann mal eine App zu entwickeln um ebenfalls darauf zuzugreifen. Da ich die Anwendung aus diversen Gründen mit der
VCL entwickele, müsste da sowieso ein separates Projekt werden. Somit hat das dann auch noch Zeit.
