AW: [SQL] - Stored Procedure bzw. Funktion vs. Direktabfrage
Zitat:
Fand ich bisher immer die einfachste Möglichkeit. Ich wollte zwar auch schon den Zugriff auf die Datenbank speziell kapseln, aber weiß noch nicht genau wie das funktionieren soll. Interfaces wären da ja sicherlich das Mittel zum Zweck. Zitat:
Tabellen die auf jeden Fall noch dazu kommen sind welche zum Protokollieren der Änderungen von Berechtigungen, Dokumenten, Schlagwörtern, ... (da habe ich aktuell auch noch nicht die ultimative Lösung wie ich das ohne extrem viel Aufwand protokollieren könnte). Die Software wird bestimmt noch in den nächsten Jahren (wenn sie denn mal funktioniert) erweitert. Es wird kein Produkt das verkauft werden soll (zumindest aktuell nicht und ich denke, dass sich das auch nicht ändern wird). Die Software wird ausschließlich in unserer Firma verwendet. CRUD (musste erstmal nachschauen was das bedeutet :oops: :lol:): Ja, also es stehen Daten in der Datenbank die abgerufen und entsprechend angezeigt werden. Ein Berechtigungssystem ähnlich wie bei NTFS soll auch enthalten sein. Hierzu hatte ich auch mal einen Thread eröffnet wie man das am Besten umsetzt. Habe aber mittlerweile denke ich die Lösung welche ich in dem Thread auch schon vorgestellt hatte. 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? Gruß Aviator |
AW: [SQL] - Stored Procedure bzw. Funktion vs. Direktabfrage
Hallo,
ich würde keine SPs nehmen. Wenn du eine Änderung an den Parametern machst, sind das immer 2 Stellen zu ändern. Dann ändert sich vielleicht die Datenstruktur und du fässt mehrere SPs an. Die Frage ist hier, wie viele Kunden werden das Programm benutzen, das ergibt einen unschönen Update-Vorgang. Solange das Programm nur in der eigenen Firma genutzt wird, spricht nichts gegen die SPs. |
AW: [SQL] - Stored Procedure bzw. Funktion vs. Direktabfrage
Zitat:
|
AW: [SQL] - Stored Procedure bzw. Funktion vs. Direktabfrage
Zitat:
genau. Und hier macht es eben einen großen Unterschied ob du da mit Queries hantieren musst:
Delphi-Quellcode:
oder ob du Objekte zur Verfügung hast
summe := qryRechnung.FieldByName('Skonto').AsCurrency * qryPosition.FieldByName('Anzahl').AsCurrency * qryPosition.FieldByName('Einzelpreis').AsCurrency;
Delphi-Quellcode:
daher: Nimm dir ein, zwei Tage Zeit und schau dir die Thematik an.
summe := Rechnung.Skonto * Positon.Anzahl * Position.Einzelpreis;
|
AW: [SQL] - Stored Procedure bzw. Funktion vs. Direktabfrage
Mein Senf:
SP sind nicht aus Prinzip schneller. Sie vermeiden am ehesten Datentransport zum Client. Wenn das so ist, sind sie schneller. Arbeitet ein Client "mühsam" per Schleife, irgendwelche Updates oder sowas durch, ist es per SP schneller. Ein reines Select per SP ist nicht schneller, es ist eigentlich genau das gleiche. Freiheiten bei Modelländerungen erhält man nicht nur durch SP, sondern auch durch die Nutzung von Views, statt (komplexen) SQL Anweisungen. 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. |
AW: [SQL] - Stored Procedure bzw. Funktion vs. Direktabfrage
Zitat:
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. Zitat:
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. Zitat:
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. :stupid: |
AW: [SQL] - Stored Procedure bzw. Funktion vs. Direktabfrage
Wiese ist ein View statisch?
Nehmen wir an:
SQL-Code:
Dann kannst du doch darauf eine Abfrage machen:
create view Koeln as select * from Kunden where ort = 'Köln'
SQL-Code:
Ein View ist doch nichts weiter, als ein in der Datenbank abgelegtes, mehr oder weniger komplexes SQL-Statement zur Abfrage von Daten, das immer wieder benutzt werden kann.
select * from Koeln as select * from Kunden where name = 'Müller'
Flappsig formuliert ist für mich ein View nix weiter, als ein Shortcut auf ein in der Datenbank abgelegtes Selectstatement. Bei einer Abfrage der View wird letztlich dieses SQL ausgeführt und die entsprechende Ergebnismenge geliefert. Wenn Du willst kannst Du auch per SQL mehrere View joinen ... Zum eher Grundsätzlichen: Bei einem leistungsstarken Datenbanksystem halte ich die Nutzung von SPs ... für deutlich effektiver. Gerade bei großen Datenmengen (zigtausende oder Millionen von Datensätzen) müssen diese nicht zum Client und verändert wieder zurück. Änderungen kann man per Trigger protokollieren ... Ebenso Logiken, die bei der Einfügung neuer Datensätze in die Datenbank, ausgeführt werden müssen. (Ebenso natürlich auch beim Update oder Delete.) Meine praktische Erfahrung aus der Vergangenheit unter C++ und Oracle ist die: Je mehr Logik in der Datenbank implementiert war, um so schneller liefen die Jobs ab. Es ging hierbei um Datenmengen von 100ten Millionen Datensätzen in 'nem recht komplexen Datenmodell. Die Zeitersparnis lag da im Bereich von Stunden und ab und an auch mal ein paar Tagen. Meine persönliche Regel ist: Alles was die Datenbank machen kann, macht die Datenbank. Außerhalb der Datenbank wird nur das erledigt, was mit Mitteln der Datenbank nicht umzusetzen ist. So gerne ich mit Delphi programmiere. Das Delphiprogramm übernimmt nur die Teile, die die Datenbank nicht erledigen kann. Ggfls. per Benutzeroberfläche den Anstoß der SPs ..., um bestimmte Aufgaben zum von Benutzer manuell bestimmten Zeitpunkt auszuführen ... Regelmäßig auszuführende Aufgaben, die die Datenbank selbständig ausführen kann, werden mit der datenbankeigenen "Prozesssteuerung" geplant und überwacht. |
AW: [SQL] - Stored Procedure bzw. Funktion vs. Direktabfrage
Zitat:
Zitat:
|
AW: [SQL] - Stored Procedure bzw. Funktion vs. Direktabfrage
Zitat:
Was Du eingangs von den SP geschrieben hast, mit denen Du alles kapseln kannst, wäre dann konsequent zu Ende gedacht/gemacht, wenn alle Datenquellen aus Prinzip als View angelegt werden.
Code:
Wäre der erste Schritt.
create table document (...);
create view iDocument as Select ... from document; Verfeinerungen, die direkt bestimmte gejointe Daten liefern, wäre der nächste. Verstecken von Modelländerungen usw. wäre dann irgendwann später dran. Das ist sicher nicht das primäre Ziel. |
AW: [SQL] - Stored Procedure bzw. Funktion vs. Direktabfrage
Zitat:
Habe noch so viele Baustellen wo ich Dinge in DLLs auslagern will weil die Daten auch von anderen Programmen abgerufen werden sollen. Allerdings habe ich noch nie wirklich eine DLL geschrieben und tue mich schwer, damit diverse Dinge abzubilden. :( Ein einfaches Laden von Benutzern aus der Datenbank macht mir da irgendwie schon Probleme. Ein Benutzer hat ja mehrere Eigenschaften die ich normalerweise in einer Klasse zusammenfassen würde. Aber dann fängt es ja schon an, dass man nicht so einfach Objekte über die DLL Grenze hinweg austauschen kann/sollte. Also wie funktioniert es dann ... Ist zwar ein anderes Thema, hat aber ja doch etwas mit der Abfrage von Daten aus der DB zu tun. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:15 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz