Laden...

Delete in 3 Schichten Architektur

Erstellt von Quallo vor 16 Jahren Letzter Beitrag vor 16 Jahren 1.888 Views
Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren
Delete in 3 Schichten Architektur

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?

V
327 Beiträge seit 2005
vor 16 Jahren

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

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

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!?

V
327 Beiträge seit 2005
vor 16 Jahren

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

476 Beiträge seit 2004
vor 16 Jahren

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

286 Beiträge seit 2006
vor 16 Jahren

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

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

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.

F
10.010 Beiträge seit 2004
vor 16 Jahren

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.

476 Beiträge seit 2004
vor 16 Jahren

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

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

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

F
10.010 Beiträge seit 2004
vor 16 Jahren

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.

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

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

286 Beiträge seit 2006
vor 16 Jahren

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

F
10.010 Beiträge seit 2004
vor 16 Jahren

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.

476 Beiträge seit 2004
vor 16 Jahren

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

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

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.

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

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.