Werte Mitstreiter,
ein paar Fragen zum Löschen in 3 Schichten Architekturen:
Ich habe Beziehungen zwischen Entitäten in der Datenbank, nehmen wir mal an, dass eine Klasse Schüler hat, die Schüler haben Noten.
Klasse 1 -- n Schüler 1 -- n Noten
Wenn ich jetzt in der Businessschicht den Geschäftsvorfall "lösche Klasse" habe, dann könnte ich auf zwei Arten vorgehen:
1.: Ich habe in der Datenbankschicht hinterlegt, dass beim Löschen von Klasse auch die entsprechenden Schüler und Noten gelöscht werden.
2.: Ich erstelle einen Geschäftsvorfäll für das Löschen eines Schülers und rufe diesen für alle Schüler der Klasse auf. Genauso wird bei den Noten für jeden Schüler verfahren.
Ich sehe bei dem 1. Modell weniger Aufwand und eine bessere Performance, bei dem 2. Modell sehe ich eine bessere Schichtentrennung, da es ja letzlich eine fachliche Anforderung ist, dass beim Löschen auch die abhängigen Entitäten gelöscht werden.
Was meint ihr dazu?
Hallo,
ich würde das 1. Modell nehmen.
Programmierer sind doch sooo faul... 😮)
nee, spass bei seite, warum soll das frontend das löschen der schüler und noten durchführen. Habe mal gerlernt, dass man soviel funktionalität wie möglich in die DB packen sollte...
Der geschäftsfall heißt "lösche Klasse" und die DB muss dann eben wissen, dass sie eben alle schüler und deren noten löschen muss. das muss doch nicht das fontend wissen, oder?
aber belehrt mich eines besseren!! ist auch für mich eine sehr interessante frage.
grüße von der ostsee!!
MFG Veasel
Der geschäftsfall heißt "lösche Klasse" und die Businessschicht muss dann eben wissen, dass sie eben alle schüler und deren noten löschen muss. das muss nicht das fontend wissen, richtig!
Die Frage ist, ob die DB das auch wissen darf!?
achja es waren ja 3 schichten...
hmm...wie geschrieben...mir wurde mal beigebracht soviel in die DB zu packen wie geht also würde ich das auch in die db packen.
MFG Veasel
hallo Quallo,
das Schichtenmodell stösst in der Praxis häufiger auf die Frage, macht eine strikte Schichtentrennung Sinn oder kaufe ich mir damit nicht nur mehr Aufwand ein und habe keinen Vorteil. Daher sehe ich das Schichtenmodell als Modell... und würde das mit Löschweitergabe über die Datenbank lösen. Warum mehr Aufwand betreiben? Warum sollte die Datenbank nicht über die Daten bescheid wissen? Es können ja keine Schüler ohne Klasse existieren, diese Beziehung hast du auch in deinem Datenbankmodell gepflegt?
-yellow
Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).
Mein Blog: Yellow's Blog auf sqlgut.de
Ich würde Differenzieren.
Wenn du das der DB mit boardeigenen Mitteln wie Referenzielle Integrität beibringen kannst, dann würde ich es in die DB packen.
Wenn du das nicht machen kannst und das via SP´s integrieren müßtest, dann würde ich es in die BL packen.
Damit hast du den Source Code zentralisiert und kannst bei einer Portierung nicht vergessen ihn mit zu portieren.
Gruß, maYer
Danke für Eure Antworten.
Im Prinzip kristallisiert sich die Lösung 1 heraus, besonders die Meinung von Yellow entspricht genau meiner Meinung.
Ich habe das in der Oracle DB bereits über Referentielle Integrität abgebildet. Sollte die beste Performance bieten und am wenigsten Aufwand sein.
Und ich bin für möglichkeit 2.
Das möglichst viel funktionalität in die DB gehört, erzählen immer
nur die DB-Admins, und die hersteller/Vertreiber von DB-Servern.
Um eine echte Scalierbarkeit zu erreichen gehören reine CRUD operationen
in die DB, alles andere gehört in eine Businessschicht ausserhalb des RDBMS.
Das ist dann "egal"ob es ein echter Appserver oder "nur" ne businessschicht in
der jeweiligen Application ist.
Wenn Du nämlich dann mal z.B. noch Sitzplätze in den Räumen,
Sitzkissen o.ä. verwalten musst, musst Du das bei eurer Lösung immer
an mehr als einer stelle machen.
Auch ist beim Scalieren, ein Appserver deutlich günstiger hinzuzustellen, als
ein weiterer SQLServer z.B.
hallo FZelle,
Original von FZelle
Das möglichst viel funktionalität in die DB gehört, erzählen immer
nur die DB-Admins, und die hersteller/Vertreiber von DB-Servern.Um eine echte Scalierbarkeit zu erreichen gehören reine CRUD operationen
in die DB, alles andere gehört in eine Businessschicht ausserhalb des RDBMS.Das ist dann "egal"ob es ein echter Appserver oder "nur" ne businessschicht in
der jeweiligen Application ist.Auch ist beim Scalieren, ein Appserver deutlich günstiger hinzuzustellen, als
ein weiterer SQLServer z.B.
sehe ich vollkommen genauso, bin in diesem Fall trotzdem für Lösung 1 mit Löschweitergabe.
-yellow
Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).
Mein Blog: Yellow's Blog auf sqlgut.de
Für Stored Procedures in der DB bin ich in so einem Fall auch nicht, außer es ist performancemäßig wirklich kein Stück anders abzubilden.
Aber ist das ausnutzen der referentiellen Integrität wirklich etwas, dass gegen Skalierbarkeit spricht? In meinen Augen nicht.
Wenn ich die Datenbank erst noch Fragen muss, wie die Schüler der Klasse heissen, bevor ich die Klasse lösche, und dann noch einzelne Löschbefehle für die Schüler loslasse, dann ist die Datenbank garantiert mehr ausgelastet, als wenn ich den Weg 1 wähle.
Wäre also nett, wenn Du deine Gedanken noch ein wenig erläutern könntest.
Grüße, Christoph
Tja, was ist, wenn dann beim löschen eines Schülers, oder eines wie auch immer gearteten childobjects, noch etwas anderes gemacht werden muss?
Wenn die DB die Daten gleich löscht, sind sie weg.
Das problem ist, das Du bei der Verteilung der Aufgaben dann an verschiedenen stellen
nach den Fehlern suchen musst.
Das ist nicht gut.
Das alles ist immer aus sicht eines einzelplatz systems mit ein paar hundert
Datensätze vielleicht nicht so wichtig, aber bei richtig grossen systemen,
wird die echte trennung von Businesslogic und Datenhaltung wichtig.
Bei letzterem Punkt muss ich dir natürlich recht geben.
Aber wenn man das so betrachtet, dann sollte man durch die Datenbank ja gar nichts mehr machen lassen, ausser reines CRUD auf die Entitäten.
Wie sieht es mit der referentiellen Integrität(ohne löschen) aus, wie sieht es mit Aggregatsfunktion wie Sum... aus?
Grüße, Christoph
Gerade bei größeren Projekten mit großen Tabellen und vielen Daten (am besten noch Varchar) würde ich die Referentielle Integrität nutzen, weil es für den Kunden günstiger ist einen dicken Server zu kaufen als alle Clients hochzupimpen.
Also für mich würde in diesem Fall die Performance wichtiger sein als dass ein Entwickler vergisst, dass die Daten über RI mitentfernt werden.
Anders sieht es bei SP´s aus. Die kommen mir nur in die DB, wenn eine Schnittstelle zu einem Fremdprodukt aufgebaut werden muss.
Gruß, maYer
Tja und ich würde lieber einen Dicken Appserver dazwischen hängen, der die BL hostet, und nen kleinen DB Server.
Der Appserver kostet "nur" Hardware, der DB-Server einen haufen für lizenzen.
Was meinst Du, ab wann da für den kunden der Preis stimmt?
Richtig ab der ersten installation.
Und natürlich gibt es fälle in denen man der db auch aufgaben geben kann/sollte,
aber nicht bei den Businessrules.
hmm Quallo,
ich denke es gibt hier kein schwarz und kein weiß. FZelle hat mit seinen Überlegungen vollkommen recht, allerdings ist es auch immer eine Gradwanderung zwischen strikter Trennung sowie Aufwand und Performance. Die Aggregatsfunktion SUM verletzt nach meinen Verständnis das Schichtenmodell nicht, da die SQL-Anweisung in der Businesslogik implementiert ist. Wer allerdings Gespeicherte Prozeduren verwendet, darf auch Löschweitergaben verwenden... 😁
-yellow
Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).
Mein Blog: Yellow's Blog auf sqlgut.de
Original von FZelle
Tja und ich würde lieber einen Dicken Appserver dazwischen hängen, der die BL hostet, und nen kleinen DB Server.Der Appserver kostet "nur" Hardware, der DB-Server einen haufen für lizenzen.
Was meinst Du, ab wann da für den kunden der Preis stimmt?
Richtig ab der ersten installation.Und natürlich gibt es fälle in denen man der db auch aufgaben geben kann/sollte,
aber nicht bei den Businessrules.
Da gebe ich dir prinzipiell recht, aber man sollte bedenken, dass die Datenbank umso stärker belastet wird, wenn ich die gleiche Datenmanipulation einzeln anstoße und dazu noch zwischenzeitig Informationen abrufe. Soll heißen, Stored Procedures sind oft so schnell, referentielle Integrität ebenso, dass die Datenbank kaum belastet wird. Wenn ich gleiche Funktionen über die Businessschicht mit CRUDL-Methoden abbilde, dann wird die Datenbank eher stärker belastet.
Original von Yellow
Die Aggregatsfunktion SUM verletzt nach meinen Verständnis das Schichtenmodell nicht, da die SQL-Anweisung in der Businesslogik implementiert ist.
Implementiert ist die SQL-Anweisung nicht in der Businesslogik.
Allerdings ist dort der Aufruf einer Methode aus der Datenbankschicht implementiert, die einen summierten Wert erwartet. Das ist für mich in Ordnung.