[SQL] - Stored Procedure bzw. Funktion vs. Direktabfrage

[Aviator]

Zitat von Papaschlumpf73:

Habe zwar noch nie mit einem Debugger gearbeitet, jedoch dürfte der weder die SQL-Eigenschaft einer ADOQuery noch eine SP debuggen können. Egal ob ADOQuery oder ADOStoredProc müsste der Debugger wohl beim Öffnen/Ausführen mit .Open oder .ExecProc oder Active:=true oder was auch immer anhalten und kann nur den Fehler ausspucken, den der SQL-Server zurück gegeben hat.

Ja das ist klar. Eine SP oder Function würde ich dann ja direkt mit dem Management Studio debuggen. Nur finde ich es oft schöner, wenn man direkt sieht was denn das Statement (in dem Fall dann die SP/Function) eigentlich macht.

Aber das ist nur eine Nebensache.

Das Fazit das ich aktuell daraus schließen würde wäre, dass SPs, Views und Functions besser sind als Statements direkt an den Server zu senden.

Falls noch jemand ein gegenteiliges Argument hat, dann nur her damit.

[Lemmy]

Pack dein Businessmodell in ein OPF/ORM dann kannst Du darüber schon recht viel (eigentlich alles) der Businesslogik kapseln. Dann würde ich nur noch laufzeitkritische Dinge (wenn sie denn in der DB schneller sind) in eine StoredProcedure verpacken, das würde dann später auch den Austausch der Datenbank erleichtern.

[Aviator]

Zitat von Lemmy:

Pack dein Businessmodell in ein OPF/ORM dann kannst Du darüber schon recht viel (eigentlich alles) der Businesslogik kapseln. Dann würde ich nur noch laufzeitkritische Dinge (wenn sie denn in der DB schneller sind) in eine StoredProcedure verpacken, das würde dann später auch den Austausch der Datenbank erleichtern.

Oh je. Das ist ein ganz neues Themengebiet für mich. Habe zwar schonmal davon gelesen, aber noch nie damit gearbeitet. Wie genau das funktionieren soll weiß ich demzufolge natürlich auch nicht.

Es wird zwar mit sehr hoher Wahrscheinlichkeit nicht passieren, dass das Datenbanksystem ausgetauscht wird, aber interessieren würde mich der Ansatz schon. Ich weiß nur leider nicht, ob es meine Zeit zulässt, dass ich mich da auch noch einarbeite.

Ich will zwar versuchen meine Anwendung in kleine Teile/Module zu zerlegen, aber dafür habe ich leider zu wenig Ahnung wie das funktionieren soll. Aktuell bin ich dran, diverse Parts meine Anwendung in DLLs auszulagern da auf meine Anwendung (bzw. eher die Daten die sie speichert) auch aus einer anderen Anwendung zugegriffen werden soll. Ob das so funktioniert wie ich es mir vorstelle weiß ich leider noch nicht. Stehe ganz am Anfang der Entwicklung. Habe die letzten zwei Wochen damit verbracht, mir ein Konzept zu überlegen, wie ich das alles splitten kann. Hoffe ich habe nichts - oder wenn, dann nur einen Teil der keine großen Auswirkungen auf das ganze System hat - vergessen.

[Lemmy]

wie groß wird denn die Anwendung? sind da 2 Tabellen dabei oder wird das einen entsprechenden Umfang annehmen? Wie ist die BUsinesslogik? Einfachste CRUD (wie bei einer ToDo-APp) oder müssen auch konkrete Anforderungen erfüllt werden (Berechnungen, Abhängigkeiten,...)

Nimm dir die Zeit und schau dir mal ein, zwei OPF an, auch wenn es schwer ist, schau dir tiopf an, ggf. auch kommerzielle Systeme (TMS, Devart). Ja, das ist ein verdammt schwerer Einstieg, wenn Du aber in ein paar Jahren die Software immer noch pflegen musst, lohnt sich das meiner Meinung nach...