Grundsatzdiskussion Trigger vs Constraints

Question

Trigger als "Pflaster" zu bezeichnen zeugt eher von Unverständis (Entschulduiigung, falls es zu hart klingt), wofür Trigger eben gut sind.
Man bedenke, dass es genug Mittel und Wege gibt, Daten an einer Anwendung vorbei zu manipulieren.
Da hat sich der Einsatz von Triggern schon oft genug bezahlt gemacht, auf diesem Wege Business-Logik zu implementieren, die jedeweden Zugriff auf die Datenbank dann möglich macht und Konsistenzen sicherstellt.
Außerdem benötigt man dann eben kein Anwendungsprogramm/-Modul, dass u.U. gar nicht zur Anwendung kommt.

Answer 1

Zur Businesslogic gehören Trigger genauso dazu wie Constraints.
Alles dient dazu, die Daten in Abhängigkeiten konsistent zu halten.
Constraints dienen des weiteren dazu, eine Veränderung der Daten i.d.R. abzulehnen (Ergebnis muss TRUE sein), wobei Trigger eben auch Daten in und aus andere Tabellen berücksichtigen können.
Alternativ kann man natürlich auch CheckFunktions als Constraints hinterlegen, wobei dies aber wiederum ähnlich einem Trigger funktioniert, mit dem Unterschied dass nur auf die definierten Parameter zugegriffen werden kann.
Es gibt da noch einen Unterschied:
CheckFunctions/Constraints werden bei jedem Insert/Update aufgerufen, Trigger nur dann, wenn sie per Definition benötigt werden, also z.B. nur Insert aber nicht mehr beim Update.
Um z.B. einen Delete zu verhindern, benötige ich einen Before-Delete-Trigger, denn Datenberechtigung alleine nützt da nichts, es gibt immer einen, der das dann doch darf. Ein Check-Constraint gegen Delete gibt es nicht, da helfen nur wiederum referentielle Constraints soweit man eine Referenz zur Verfügung hat.

Answer 2

Hi,

Trigger als "Pflaster" zu bezeichnen zeugt eher von Unverständis (Entschulduiigung, falls es zu hart klingt), wofür Trigger eben gut sind.

ist nicht böse gemeint aber ich sehe das Unverständnis eher auf deiner Seite. Trigger sind für den hier angedachten Zweck nur dann sinnvoll, wenn es gar nicht anders geht. Dass man das über die Datenbank lösen sollte, ist schon klar. Aber eben eher per SP, Constraint, ...

Man würde ja auch nicht auf die Idee kommen, anstelle einer Fremdschlüsselbeziehung einen Trigger einzusetzen. Dasselbe gilt für die Überprüfung von Werten/Daten anhand von Regeln, die dann zum Abweisen der Datenaktualisierung führen sollen. Natürlich geht das. Es ist nur in den allermeisten Fällen nicht die beste Wahl.

Dein Einwand, dass es keinen Check Constraint bei DELETE Operationen gibt, ist zwar vom Grundsatz her richtig, hat aber mit dem, was der OP will, nichts zu tun.

Zudem benötigt der OP eben bei INSERT und UPDATE eine Prüfung, von daher wüsste ich nicht, warum man hier unterscheiden sollte.

@OP: Schau dir mal das hier an:

  https://stackoverflow.com/questions/13000698/sub-queries-in-check-constraint

Dort findest Du ein Beispiel, wie man das von dir Gewünschte umsetzen kann.

 

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

Answer 3

Trigger als "Pflaster" zu bezeichnen zeugt eher von Unverständis (Entschulduiigung, falls es zu hart klingt), wofür Trigger eben gut sind.
Man bedenke, dass es genug Mittel und Wege gibt, Daten an einer Anwendung vorbei zu manipulieren.
Da hat sich der Einsatz von Triggern schon oft genug bezahlt gemacht, auf diesem Wege Business-Logik zu implementieren, die jedeweden Zugriff auf die Datenbank dann möglich macht und Konsistenzen sicherstellt.
Außerdem benötigt man dann eben kein Anwendungsprogramm/-Modul, dass u.U. gar nicht zur Anwendung kommt.

Wenn die entsprechende Prozess-Sicherheit fehlt, sind Trigger ein „Pflaster“, dies zu fixen. Das meine ich damit. Vielen Dank für die Bestätigung ;-)

Wer keine Frontend-Anwendung für seine Datenbank hat, sondern tatsächlich direkt über SSMS geht (auch eine Anwendung), der muss sich eben mit Triggern behelfen. Das macht diese aber noch lange nicht zum Mittel erster Wahl, sondern eben als Hilfsmittel bei solchen Problemen.

Bevor Sie hier irgendjemandem „Unverständnis“ vorwerfen, schauen Sie doch mal in sein Profil, und prüfen Sie mal, ob da nicht ein Kern Wahrheit hinter einer sicher provokanten, aber alles anderen als falschen Aussage steckt. ;-) Es könnte sonst leicht auf einen zurückfallen...

---

Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
MCM SQL Server 2008
MVP Data Platform
www.SarpedonQualityLab.com | www.andreas-wolter.com

Answer 4

Dass hier nur unterschiedliche Meinungen auf einander prallen ist doch ganz normal.
Ich persönlich halte mich nun auch nicht für ganz unerfahren im Umgang mit Datenbanken schließlich mache ich das auch schon seit 40 Jahren;-), nicht nur mit SQL-Servern.
Trigger gehören zur Datenbank ebenso wie Prozeduren und Funktionen, die man sich auf Grund Trigger dann auch schon mal sparen kann;-).
Alles was eine Datenbank kann darf und soll auch verwendet werden. Wenn ich mir mit Triggern Anwendungslogik in die Datenbank holen kann ist das mit Abstand der sicherste Weg.
Das hat mit Prozesssicherheit überhaupt nichts zu tun.
Alles was automatisierbar ist gehört auch automatisiert, wie schnell hat man schon mal bei der Anwendungsprogrammierung irgendeinen Funktionsaufruf vergessen, der bestimmte Anforderungen erfüllt.

Trigger in der Datenbank gehören genau zum selben guten Programmierstil oder Datenbankdesign, da sie das Leben vereinfachen und Logik genau dahin bringen wohin sie gehört.

Irgendeine Funktion hier als Pflaster zu titulieren geht in meinen Augen einfach zu weit.

Schließlich hält doch jeder eine Datensicherung sicherlich für kein Pflaster da man bei der Hardware doch nur für Prozesssicherheit sorgen muss um auf Datensicherungen verzichten zu können.
Deshalb werden auch zu hauf HA-Lösungen (Spiegelungen, verteilte Systeme, Redundanzen) erfunden die doch ebenso bei entsprechender Prozesssicherheit vollkommen unnötig wären.

Aber da sind wir ja nun am Thema vollkommen vorbei.

Für obige Aufgabe würde ich persönlich immer einen Trigger vorziehen, da ich dann auch z.B. Bulk-Inserts aus anderen Quellen verwenden kann ohne nun zusätzliche Anwendungslogik zu erfinden um diese triviale Aufgabe zu lösen.

Answer 5

Alles was eine Datenbank kann darf und soll auch verwendet werden.

Nichts ist so falsch wie diese Aussage, und das kann man nicht so stehenlassen. Denn wenn andere Neulinge das Verinnerlichen, ist keinem geholfen..

Das muss man eigentlich gar nicht erst widerlegen, denn da wird man nie fertig mit Beispielen

Aber gern ein Gegenbeispiel: Man kann auch mit Excel eine relationale Datenbank nachbilden. Und mit SQL Server eine Objektorientierte...

Von einzelnen Features, die man nie verwenden sollte, ganz zu schweigen...

Zu dem Rest sage ich jetzt mal Nichts. Fehlt ja noch, dass ich mich bei "Triggern entschuldige" ;-)

(Und Nein, ich sage nicht, dass da nichts Wahres darunter steckt. Aber an meiner Aussage brauch ich Nichts zu ändern. Wie sie gemeint war, habe ich ja extra nochmal betont. Hier geht es um Denkanstöße, kein Referat mit allen Vor- und Nachteilen.)

---

Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
MCM SQL Server 2008
MVP Data Platform
www.SarpedonQualityLab.com | www.andreas-wolter.com

Answer 6

 Wenn ich mir mit Triggern Anwendungslogik in die Datenbank holen kann ist das mit Abstand der sicherste Weg.

Ich bin jetzt nicht wirklich der Datenbankentwickler. Aber mMn wäre der bessere Weg, wenn die Anwendungslogik (wenn sie schon in der DB liegen muss) in Prozeduren verpackt wird.

Nachgelagert gibt es dann nur noch ein GRANT EXECUTE auf die Prozeduren und keinen direkten Zugriff mehr auf die Tabellen. Ist natürlich abhängig davon, wie man initial angefangen hat App und DB zu designen.

@toot_braunstein: Wenn man es ganz simpel haben will (so wie Du es am Anfang beschrieben hast), dann machst Du auf deine entsprechende Tabelle nur ein select mit der Eingrenzung der letzten 5 Minuten (du brauchst auf jeden Fall eine Art Zeitstempel)und am Ende ein GROUP BY Prüfwert HAVING COUNT (Prüfwert) >= 2. 

Das ganze verpackt in ein IF EXISTS  und schon hat man das Mini Überwachungs-Konstrukt fertig.

Also sowas wie IF EXISTS( SELECT....WHERE datetime between y und y GROUP BY HAVING COUNT (Prüfwert) >=2

BEGIN

EXEC Mailtask oder Ähnliches

END

Das mag ggf erst einmal etwas dilletantisch sein, erfüllt aber Deine initiale Anforderung. 

Und jetzt werde ich mal in einer meiner DBs auf jede Tabelle 999 non clustered indizes legen.Die DB kann das ja....

---

May you never suffer the sentiment of spending a day without any purpose

Answer 7

Prozeduren müssen explizit aufgerufen werden, Trigger werden automatisch aufgerufen.
Wie bereits gesagt, wenn ich z.B. den regelmäßigen Import von Daten über verknüpfte Tabellen (Verbindungsserver) per Bulk-Insert (Insert into... Select ... from ) anstoße handelt der Trigger das automatisch ab.
Habe ich nur eine oder gar mehrere Prozedur/en, muss ich eine Prozedur schreiben, die einen Select vom Verbindungsserver macht, die Prozedur/en mit den Parametern aufruft und dann den Insert durchführt.
Ich habe dadurch nur mehr Arbeit.

Auch wenn ich per Berechtigung andere von der Bearbeitung der Tabellen ausschließe, was ich sowieso i.d.R. (siehe obige Prozesssicherheit) tue, gibt es halt immer wieder Aufgaben die mal eben schnell an der Anwendung vorbei realisiert werden müssen. Keine Anwendung ist statisch.
Ich wehre mich ja nur gegen den Pflaster-Begriff einer ganz normalen Standardfunktion jeder x-beliebigen Datenbank. Denn oft genug werden ebenso Pflaster-Prozeduren geschrieben, da die Trigger für die Datenkonsistenz einfach fehlen.

"Works as Designd", "Das Programm macht ja keine Fehler, es ist halt nur so programmiert!"

Und 999 Indzes mögen ja etwas viel sein, aber wenn es denn nötig ist;-).
Aus Performancegründen werden häufiger schon mal 30-50 Indizes oder auch mal mehr benötigt, was bei wenigen Inserts/Updates je Sekunde unkritisch ist, bei Massentransaktionen muss man dann allerdings die Indizes temporär abschalten, damit die Inserts wieder schneller laufen.
Warum so viele Indizes?
Weil es eben viele Abfragen gibt die irgendwelche Aggregate bilden um aus den Echtdaten schöne Berichte zu zaubern.
Dies wird dann in Views gepresst damit es schön einfach wird.
Die Lösung des Problems bieten dann hier wieder Trigger an, die Vorstufen der Aggregate in weiteren Tabellen fortschreiben, auf denen dann diese Views basieren und man kann wieder einige Indizes abschalten.
Mit explizit aufzurufenden Prozeduren lässt sich das zwar ebenso lösen, aber dafür werden dann wieder zeitgesteuerte Batch's initiiert und der Anwender beschwert sich ggf. über die noch nicht aktuellen Daten, die ein Trigger ja aktuell halten könnte.

Aber wie ja schon gesagt, jedem seine Pflaster;-).

Answer 8

Hallo Herr Fürchau,

regelmäßige Importe mache ich gar nicht über linked Server. Die sind mir als Admin ein Dorn im Auge. Da nutze ich dann doch lieber ein SSIS Paket, was mir Daten aus einer (oder mehreren) Quelle(n)  lädt und in einen Staging Bereich verschubbst und das Ganze im Kontext eines entsprechenden Service Benutzers.

Und Danke für die kleine Index Lehrstunde. Wer hätte gedacht, dass Indizes Massentransaktionen ausbremsen können? Dafür partizipere ich doch gerne dann und wann mal in diesem Forum. Man lernt halt nicht aus.

---

May you never suffer the sentiment of spending a day without any purpose

Answer 9

Da nun aktive Indizes ständig mitgepflegt werden müssen, ins besonders wenn sie Unique sind, dauert dies eben auch. Man denkt, die Datenbank ist schnell, wenn ich 30-50 Inserts/Sekunde durchkriege?
Schmeißt man die Indizes raus (ggf. auch den Unique, wenn sicher ist, dass es keine doppelten Schlüssel gibt) kann man durchaus 10-100fache, also 300-3000 Inserts/Sekunde durchkriegen.
Das Aktivieren der Indizes geht dann durchaus flott, vor allem wenn man den Aufbau über getrennte Verbindungen parallelisiert (SQL unterstützt halt noch kein Multithreading, aber wer weiß...).

Answer 10

Alles was automatisierbar ist gehört auch automatisiert, wie schnell hat man schon mal bei der Anwendungsprogrammierung irgendeinen Funktionsaufruf vergessen, der bestimmte Anforderungen erfüllt.

Erstmal ist ja nichts automatisiert, du kannst das erstellen des Triggers genau so vergessen, wie jemand irgendeinen Funktionsaufruf.

Dann hast du das eigentliche Problem noch nicht, da fehlt ein Funktionsaufruf, der kann noch alles mögliche machen. Du hast jetzt vielleicht keine Exception mehr, dafür sind aber irgendwelche Berechnungen falsch. Und meistens ist es einfacher eine Exception zu beheben, als herauszufinden wie so jetzt die Berechnungen falsch sind.

Es ist eigentlich immer sinnvoller, das eigentliche Problem zu beheben.

Dann kommt hinzu das du das DRY Prinzip verletzt. Du hast jetzt Logic an 2 Stellen und musst bei jeder Änderung 2 Stellen ändern und auch daran denken, das du beide Stellen änderst. 

Answer 11

Wenn es danach geht, musst du schon bei den Tabellen und Views anfangen, denn diese sind quasi ebenso Geschäftslogik.
Deshalb spricht man ja auch vom 3-Ebenen-Modell:
- Datenmodell (Tabellen, Views, Indizes, Constraints)
- Funktionsmodell (Prozeduren, Funktionen, Trigger)
- Anwendungsmodell (Frontend, Backend)

Was ich im Funktionsmodell bereits erledigt habe brauche ich eben nicht mehr im Anwendungsmodell durchzuführen.
Wozu denn sonst gibt es Prozeduren und Funktionen?

Und was das Datenmodell angeht, so ist eben SQL so flexibel, dass ich dieses durch Anpassungen, Tabellen, Views und eben Trigger verbessern und optimieren kann, ohne dass das Anwendungsmodell davon irgendwas bemerkt.

Somit ist Daten- und Funktionsmodell das große Pflaster des Anwendungsmodelles.

Und wie soll ich einen Trigger vergessen?
Da dieser ebenso zum Modell gehört wird er ja nicht ständig entfernt und hinzugefügt. Er gehört ja ebenso zur Lösung wie eine Prozedur oder Funktion.
Man vergisst da leider eher einen Funktions/Prozeduraufruf alls eben einen aktivierten und immer mitlaufenden Trigger.

Die Auftragserfassung passiert im Frontend, eine Bestandsverbuchung ggf. über Prozeduren und die Bestandsfortschreibung, -historisierung, statistische Verteilung dann über Trigger.
Und alles schön Transaktionsgesteuert.
Was ist dagegen einzuwenden?

Answer 12

Das Aktivieren der Indizes geht dann durchaus flott, vor allem wenn man den Aufbau über getrennte Verbindungen parallelisiert (SQL unterstützt halt noch kein Multithreading, aber wer weiß...).

Na da hat sich in den letzten 40 Jahren aber einiges getan: selbstredend ist SQL Server multi-threaded, und das schon zu SMP-Zeiten, seit also ca. 20 Jahren oder mehr (genauer kann ich es nicht sagen, da ich mich nicht mit Legacy-Systemen befasse)

Was Trigger und "vergessen" angeht, hat sich in der Praxis leider durchaus gezeigt, dass über die Jahre da Trigger entstanden sind, von denen der App-Entwickler nichts mehr weiß. Und anders als "vergessene Prozeduren", die dann auch nichts tun, werden Trigger ja immer mit ausgeführt und führen dann oft zu unerklärbaren Fehlern...
Das ist eines der Hauptprobleme von Triggern: ihre implizite Verwendung - die MANCHMAL auch wirklich sinnvoll sein kann, aber das sind eben bestimmte, hoffentlich klar umrissene, dokumentierte Szenarien.

---

Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
MCM SQL Server 2008
MVP Data Platform
www.SarpedonQualityLab.com | www.andreas-wolter.com

Answer 13

Wenn es danach geht, musst du schon bei den Tabellen und Views anfangen, denn diese sind quasi ebenso Geschäftslogik.

Also das Tabellen Geschäftslogik sind mag ich stark zu Bezweifeln.

Gegen Logic in der Datenbank spricht einiges.

Einmal es frisst Performance. Wenn die Datenbank noch zusätzliche Aufgaben erfüllt wird sie einfach langsamer.

Dann Skaliert es schlechter. Bei Clients kann ich einen Zusätzlichen Computer anschaffen und einfach bereitstellen. Die Datenbank kann ich nicht einfach auf einen Zusätzlichen Server Stellen, da muss ich dann auch noch schauen das die Daten Synchronisiert werden. Was dann auch wieder Performance frisst.

Die Flexibilität sinkt. Wenn ich ein 3 Layer Architektur habe. Z.B Thin Clinet, WebApi und Datenbank. Kann ich die einzelnen Komponenten austauschen ohne das es großen Einfluss auf die Anderen hat. Die WebApi interessiert es nicht, ob das ein Webbrowser drauf zugreift oder ein Thin Client und auch nicht in welcher Programmiersprache der geschrieben wurde. Genau so interessiert es den Client nicht ob die WebApi mit Node.JS, C# oder PHP geschrieben ist. Und wenn ich die Datenbank tausche, kann es sein das ich im DAL der API einige Anpassungen machen muss. Das ist aber dann nur Fleißarbeit. Z.B. kann ich (wenn ich es richtig gemacht habe) Problemlos MySQL gegen MSSQL austauschen.

Dann hast du noch Logik die sich wiederholt und dann an 2 Stellen gewartet werden muss. Der Benutzer möchte ja nicht erst alle Felder ausfüllen und dann ein Feedback bekommen ob die Angaben richtig sind, sondern möglichst direkt.

Das sind so die großen Punkte, die mit spontan einfallen.

Ja der SQL Server kann wirklich, viel und es ist auch gut wenn man die Möglichkeiten bei bedarf hat. Man sollte sie nur nicht alle nutzen wenn man sie nicht brauch. Es kommen ja auch die Wenigsten auf die Idee ihr Ersatzrad vom Auto zu benutzen, aber es ist trotzdem gut wenn es im Notfall da ist.

Der SQL Server ist halt eine Datenbank und das ist seine zentrale Aufgabe. Dafür sollte er auch genutzt werden.

p.s.

Ein Insert Trigger und darin ein Insert in eine andere Tabelle kosten auch Performance. Ich denke mal da müssen schon ein paar Indexe wegfallen um das wieder auszugleichen.

Answer 14

Da nun aktive Indizes ständig mitgepflegt werden müssen, ins besonders wenn sie Unique sind, dauert dies eben auch. Man denkt, die Datenbank ist schnell, wenn ich 30-50 Inserts/Sekunde durchkriege?
Schmeißt man die Indizes raus (ggf. auch den Unique, wenn sicher ist, dass es keine doppelten Schlüssel gibt) kann man durchaus 10-100fache, also 300-3000 Inserts/Sekunde durchkriegen.
Das Aktivieren der Indizes geht dann durchaus flott, vor allem wenn man den Aufbau über getrennte Verbindungen parallelisiert (SQL unterstützt halt noch kein Multithreading, aber wer weiß...).

Und ich dachte, dass man meinen ironischen Unterton hätte rauslesen können. ;-)    Tatsächlich arbeite ich selbst schon lange genug mit dem Produkt SQL Server, um zu wissen, wie man Daten schnell in eine Tabelle pumpt oder welche Bremsen es so gibt. Und bis dato hatte ich immer genügend große Zeitfenster, um entsprechende Indizes neu anzulegen. Dies musste nie parallel betrieben werden. Aber da ist ja jede Anforderung anders...

Das SQL Server jedoch kein Multithreading besitzt ist wäre mir tatsächlich neu.  Warum werden denn dann Multiple CPUs/Kerne unterstützt von der Engine?

Guckt man sich mal an, wie viele CPUs der SQL Server beim Aufbau eines Index verwendet, dann würde ich schon sagen, dass das multiple threads sind, je nachdem wie der Query optimizer sich entschieden hat.  Hängt natürlich von der eingesetzten Edition ab. Ein SQL Server Standard unterstützt keine parallele Indexvorgänge. https://docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2016

Für weitere Infos verweise ich gerne mal auf Paul White:

https://www.red-gate.com/simple-talk/sql/learn-sql-server/understanding-and-using-parallelism-in-sql-server/

Oder die Microsoft Dokumentation

https://msdn.microsoft.com/en-us/library/ms191292.aspx

https://msdn.microsoft.com/en-us/library/ms178065.aspx

Das, was Sie meinen ist wohl mehrere Sessions aufbauen bzw Prozesse etablieren, um dann den SQL Server zu sagen: Baue mir Index 1,2,3,4 und 5 auf. Aber ich habe nunmal nur eine Session. Dann muss ich halt meine Applikation so umbauen, dass diese mehrere Verbindungen öffnet, auf SQL Server Seite mehrere SPIDs bekommt und dann über jede Session einen Index (re)build absetze.

Viel wichtiger finde ich aber mal beim Threadersteller nachzufragen welchen Weg er nun einschlagen möchte, um Seine Überwachung zu etablieren und ob neben der ganzen Off Topic Diskussion denn schon irgendetwas weiter geholfen hat.

---

May you never suffer the sentiment of spending a day without any purpose

Answer 15

Nun, bzgl. der Parallelverarbeitung im SQL-Server habe ich dazugelernt. Jede neue Version kann halt mehr. Man wundert sich halt immer wieder nur, dass sich Anwender über Performance der Anwendung beschweren;-).

Trotzdem bleibe ich bei meinem 3-Wege-Ansatz.
Es steht außer Frage, dass Feldprüfungen u.ä. bereits am Frontend durchgeführt werden müssen.
Dies hat aber nichts damit zu tun, dass eben Trigger wie auch Prozeduren eben Dinge erledigen, die auf dem Server dann einfach schneller erledigt werden können als durch viele kleine Zugriffe des Clients (der ja durchaus auch weiter weg sein kann).
Warum auch sonst schreibt man Prozeduren, die mehrere Schritte zusammenfassen, die auch von Triggern erledigt werden können?
Warum werden Constraints verwendet, die doch auf internen Triggern basieren (auch wenn sie nicht wie Trigger erscheinen)?
Bevor es Constraints gab, konnte man dies bereits mit Triggern erledigen.
Warum werden nun Hidden-Columns erfunden die sicherstellen dass bestimmte Werte in dei DB geschrieben werden, was Trigger bereits vorher erledigen konnten?

Und was das doppelte Arbeiten angeht, so kann man dies per Konzeption und Design ja ausschließen.

Und bei sauberer Anwendungsdokumentation kann man Trigger nicht übersehen, wenn sie denn unnötig werden, was ich aber eher für ein Gerücht halte. Wenn die Tabelle nicht mehr benötigt wird, wird ebenso der Trigger nicht mehr ausgeführt.
Andererseits, wenn eine Prozedur aufgerufen wird, die nicht mehr benötigte Tabellen verwendet, trifft es genauso.

Aber jeder hat so halt seine eigenen Erfahrungen, Vorzüge und Methoden. Schließlich gibt es nicht die Lösung schlechthin.

Answer 16

Nun, bzgl. der Parallelverarbeitung im SQL-Server habe ich dazugelernt. Jede neue Version kann halt mehr. Man wundert sich halt immer wieder nur, dass sich Anwender über Performance der Anwendung beschweren;-).

...

Ich habe nochmal nachgesehen: Multi-threading wurde erstmals in SQL Server 6.0 eingeführt (mit der Ablösung von Sybase, das andere Wege ging). Das war 1995. Da lag ich mit meiner Schätzung also ziemlich genau. Den Seitenhieb zu "40 Jahre Erfahrung" kann ich mir da schenken, oder? ;-)

Aber Multi-threading löst ja nicht automatisch jedes Performance-Problem. Bei 2 Cores und 20 worker-threads müssen sich 10 jeweils eine Core teilen (vereinfachtes Beispiel). Logisch oder? Zum anderen ist nicht jedes Problem überhaupt bei der CPU zu suchen. Gegen eine offen gelassene Transaktion mit einer Sperre, hilft kein Thread/Scheduler mehr. Auch logisch?

Alles halb so wild, jeder lernt sicher gern dazu, früher oder später.

---

Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
MCM SQL Server 2008
MVP Data Platform
www.SarpedonQualityLab.com | www.andreas-wolter.com

Answer 17

Und bei sauberer Anwendungsdokumentation kann man Trigger nicht übersehen, wenn sie denn unnötig werden, was ich aber eher für ein Gerücht halte. Wenn die Tabelle nicht mehr benötigt wird, wird ebenso der Trigger nicht mehr ausgeführt.

...

Das klingt für mich sehr pädagogisch, wie "von der Uni" - die (traurige) Realität ist, das Dokumentation (von "sauber") ganz zu schweigen, eher selten ist.

Answer 18

...

Warum werden Constraints verwendet, die doch auf internen Triggern basieren (auch wenn sie nicht wie Trigger erscheinen)?
Bevor es Constraints gab, konnte man dies bereits mit Triggern erledigen.

...

Das würde jetzt in eine Erklärung ausschweifen, wie Trigger vs Constraints eigentlich funktionieren.

In Kurz: Constraints haben mit Triggern technisch nichts zu tun. Trigger greifen erst, wenn die Daten bereits geschrieben wurden (Ausnahme "Instead-Of" Trigger für Views)

Vielleicht helfen einige Zitate aus BOL:

"Using constraints is preferred to using DML Triggers, rules, and defaults. The query optimizer also uses constraint definitions to build high-performance query execution plans."
(https://technet.microsoft.com/en-us/library/ms189862(v=sql.105).aspx)

"A DML trigger is an action programmed to execute when a data manipulation language (DML) event occurs in the database server. DML events include UPDATE, INSERT, or DELETE statements issued against a table or view. DML triggers are used to enforce business rules when data is modified and to extend the integrity checking logic of Microsoft SQL Server constraints, defaults, and rules."
(https://technet.microsoft.com/en-us/library/ms191524(v=sql.105).aspx)

Das soll als Tipp dazu genügen. Mehr kann man dort und anderswo ja nachlesen.

---

Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
MCM SQL Server 2008
MVP Data Platform
www.SarpedonQualityLab.com | www.andreas-wolter.com

Answer 19

Hallo zusammen,

neben der eigentlichen Frage des OT finde ich die Diskussion CONSTRAINT vs. TRIGGER recht interessant. Ich bin nicht wirklich "Fan" von Triggern. Trigger haben - neben der Integration von Geschäftslogik - aus meiner Sicht einen anderen Vorteil, der hier vielleicht etwas zu kurz gekommen ist - geöffnete Transaktionen.

Ein CONSTRAINT schützt nicht davor, dass die zu ändernden Ressourcen innerhalb einer Transaktion so lange geöffnet bleiben, bis die Transaktion abgeschlossen ist. In einem Trigger kann ich auf solche "Fehler" einfach reagieren, indem ich im Trigger die Transaktion schließe!

ALTER TABLE dbo.Customers
ADD CONSTRAINT chk_not_my_company CHECK (NAME <> 'db Berater GmbH');
GO

-- check vs trigger
BEGIN TRANSACTION;
GO
	UPDATE	dbo.Customers
	SET		Name = 'db Berater GmbH'
	WHERE	Id = 10;
	GO

	SELECT * FROM sys.dm_tran_locks
	WHERE	request_session_id = @@SPID;
	GO
ROLLBACK TRANSACTION;
GO

Ein CONSTRAINT führt nicht automatisch zu einem ROLLBACK!

In einem Trigger kann ich unmittelbar darauf reagieren:

CREATE TRIGGER dbo.trg_Customers_Update
ON dbo.Customers
FOR UPDATE
AS
BEGIN
	SET NOCOUNT ON;

	IF EXISTS (SELECT * FROM inserted WHERE name = 'db Berater GmbH')
	BEGIN
		RAISERROR ('This company name is not allowed', 11, 1) WITH NOWAIT;
		ROLLBACK TRANSACTION;
	END

	SET NOCOUNT OFF;
END
GO

Die vielen Vor- und Nachteile wurden von den Teilnehmern ja schon ausreichend kommentiert. Dennoch sollte noch ein weiterer Punkte berücksichtigt werden, der bei Triggern ebenfalls stark ins Gewicht fällt: Trigger verwenden TEMPDB! Ich habe bereits zu viele Systeme gesehen, bei denen TEMPDB das Bottleneck des Servers gewesen ist. Von daher würden Trigger diese Situation nur noch verschärfen.

Trigger in einer Business-Anwendung mit "sporadischer" Datenänderung sind nicht verkehrt; in einem hochtransaktionalen System würde ich sie nicht einsetzen wollen. Dem Argument der Trigger bei Massenimporten stehe ich ebenfalls eher skeptisch gegenüber, da solche Implementierungen - meistens - auf die Verwendung von Cursorn hinauslaufen :)

@Dirk: Ironie sollten wir in diesem Forum unterlassen. Hier ging/geht es immer sehr sachlich zu. Eine Besonderheit, die ich an den MSDN-Foren wirklich sehr zu schätzen weiß. Ich kenne Dich und weiß auch, wie Du "tickst"; von daher bin ich etwas überrascht gewesen. Du hast das nicht nötig - wie auch das ganze Forum nicht.

---

Uwe Ricken (Blog | Twitter)
Microsoft Certiied Master - SQL Server 2008
Microsoft Certified Solution Master - CHARTER Data Platform
Microsoft Certified Solution Expert - Data Platform
db Berater GmbH
Microsoft SQL Server Blog (german only)

Answer 20

Normalerweise sollte ein Trigger keine eigenen Transaktionen verwenden, da diese ja von außen erstellt werden.
Selbst bei AutoCommit habe ich den Vorteil, dass ich innerhalb des Triggers auf jeden Fall eine offene Transaktion habe.
Rufe ich mit AutoCommit eine Prozedur auf, wird jeder Update/Insert/Delete innerhalb der Prozedur einzeln commited es sei denn, die Prozedur startet eine eigene Transaktion.
Dies wiederspricht aber eigentlich dem Transaktionskonzept, dass der Client im Rahmen der Aufgabe die Transaktion steuert um somit viele Updates/Insert/Deletes mit Prozeduraufrufen konsistent zu halten.

Klar ist auch, dass jede Transaktion TEMPDB verwendet um im Rollback-Fall alle Änderungen rückgängig zu machen.
Dies ist kein Spezialfall des Triggers.

Aus persönlichen Erfahrungen würde ich auch nie eine Transaktion im Trigger schließen (egal ob Commit/Rollback) sondern wie oben gezeigt einen Fehler auswerfen, damit der Client dann darauf reagieren kann. Manche Fehler kann man auch innerhalb einer Transaktion tollerieren.

Anderes gilt u.U. für geschachtelte Transaktion (oder Safepoints) um z.B. Daten zu protokollieren, die auch im Rollback-Fall erhalten bleiben müssen. Vielleicht um einfach nur nachzuweisen, dass eine bestimmte Aktion stattfand.

Ach ja und noch eins:
Im Update-Trigger habe ich automatisch Zugriff auf Before- und After-Variablen um z.B. Prozeduren mit Differenzwerten aufzurufen, während ich in einer Prozedur erst noch mal einen Select für Vergleiche benötige.
In diesem Sinne ist ein Trigger dann sogar schneller.

Answer 21

Das finde ich eine super Idee;-)!

Answer 22

...Trigger haben - neben der Integration von Geschäftslogik - aus meiner Sicht einen anderen Vorteil, der hier vielleicht etwas zu kurz gekommen ist - geöffnete Transaktionen.

Ein CONSTRAINT schützt nicht davor, dass die zu ändernden Ressourcen innerhalb einer Transaktion so lange geöffnet bleiben, bis die Transaktion abgeschlossen ist. In einem Trigger kann ich auf solche "Fehler" einfach reagieren, indem ich im Trigger die Transaktion schließe!...

Da wird aber Apfel mit Brotkorb verglichen. Constraits sind keine Code-Blöcke, die abseits von "passt/passt nicht" irgendwelche Routinen durchführen sollen. Ihr alleiniger Zweck ist es, ein Insert/Update/Delete zuzulassen, oder eben nicht.
Was man daraufhin in seinem Code-Block macht, ist die Sache eben der aufrufenden Prozedur/oder Trigger(!).

Was die "Sachlichkeit" angeht, so mag ein Blick auf den ersten Satz in diesem Thread die Relation setzen ;-)
Ansonsten sehe ich es aber auch so.

---

Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012 - nicht nur "Charter Member" (gabs "kostenlos für alle 2008er MCMs dazu"), sondern tatsächlich geprüft auf 2012
MCM SQL Server 2008
MVP Data Platform
www.SarpedonQualityLab.com | www.andreas-wolter.com

Answer 23

(1-4) Normalerweise sollte ein Trigger keine eigenen Transaktionen verwenden, da diese ja von außen erstellt werden.
Selbst bei AutoCommit habe ich den Vorteil, dass ich innerhalb des Triggers auf jeden Fall eine offene Transaktion habe.
Rufe ich mit AutoCommit eine Prozedur auf, wird jeder Update/Insert/Delete innerhalb der Prozedur einzeln commited es sei denn, die Prozedur startet eine eigene Transaktion.
Dies wiederspricht aber eigentlich dem Transaktionskonzept, dass der Client im Rahmen der Aufgabe die Transaktion steuert um somit viele Updates/Insert/Deletes mit Prozeduraufrufen konsistent zu halten.

(5) Klar ist auch, dass jede Transaktion TEMPDB verwendet um im Rollback-Fall alle Änderungen rückgängig zu machen.
Dies ist kein Spezialfall des Triggers.

(6) Aus persönlichen Erfahrungen würde ich auch nie eine Transaktion im Trigger schließen (egal ob Commit/Rollback) sondern wie oben gezeigt einen Fehler auswerfen, damit der Client dann darauf reagieren kann. Manche Fehler kann man auch innerhalb einer Transaktion tollerieren.

(7) Anderes gilt u.U. für geschachtelte Transaktion (oder Safepoints) um z.B. Daten zu protokollieren, die auch im Rollback-Fall erhalten bleiben müssen. Vielleicht um einfach nur nachzuweisen, dass eine bestimmte Aktion stattfand.

(8)
Im Update-Trigger habe ich automatisch Zugriff auf Before- und After-Variablen um z.B. Prozeduren mit Differenzwerten aufzurufen, während ich in einer Prozedur erst noch mal einen Select für Vergleiche benötige.
In diesem Sinne ist ein Trigger dann sogar schneller.

(1-4) Was genau möchtest Du damit eigentlich sagen?

Warum ist es von Vorteil, innerhalb des Triggers eine Transaktion geöffnet zu bekommen, wenn ich es davor noch nicht explizit getan habe? Vor allem, wenn die Applikation damit gar nicht rechnet… AutoCommit = "Implicit Transactions" in SQL Server ist der Standard, den man normalerweise nicht extra "aufruft", es sei denn man hat den Modus geändert (keine gute Idee, weil damit außer in extrem abgeschotteten One-Man-Projekten keiner rechnet)

Warum ist ein "Begin Transaction" innerhalb einer Prozedur gleich ein Verstoß des Transaktionskonzeptes?? So oder so gibt es dann eine Transaktion. Ob das eine oder andere die bessere Vorgehensweise ist, kommt auf den Anwendungsfall an, oder?

(5) Das ist klar falsch und leicht nachzulesen. Vor SQL 2005 war der Aufwand für ein Rollback innerhalb von Triggern noch größer, seit 2005 etwas effizienter über Tempdb gelöst – aber eben immer noch nicht „kostenlos“. Datenänderungen außerhalb von Triggern werden NICHT über Tempdb hinterlegt, sofern man nicht in einer Variante von Snapshot Isolation arbeitet. Mag bei Oracle anders sein, ist bei SQL Server aber schon immer so.

(8) Das ist auch nicht richtig. Seit SQL Server 2005 kann man auch ohne Trigger die output-Clausel verwenden, und hat dann ebenso direkten Zugriff auf die Vorher-/Nachher-Werte. Trigger sind auch nicht schneller.

Ich hoffe, ich habe das Gröbste klarstellen können… Es tut mir leid für die, die aus diesem Thread etwas lernen möchten, bei so viel Halbwahrheiten… Wenn ich das mal so sagen darf. Es spricht ja nichts dagegen, seine eigenen Aussagen vorher einmal zu prüfen. Dafür gibt es BOL/Google. (Nutze ich selber auch, ohne mich dafür zu schämen)

---

Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
MCM SQL Server 2008
MVP Data Platform
www.SarpedonQualityLab.com | www.andreas-wolter.com

Answer 24

Was den 1.Satz angeht, so habe ich meine Entschuldigung ja gleich mit rein geschrieben.

Aber ansonsten ist das ja genau das Problem auf das ich häufig genug stoße, dass Anwendungen leider ohne Transaktionen arbeiten. Dies fördert die Inkonsistenz der Datenbank und dazu benötigt man dann auch noch Recovery-Funktionen für abgebrochene Vorgänge.
Sicherlich sollten Transaktionen auf Grund der Sperren nicht über User-Interaktion hinaus offengehalten werden.

Und was ich nachlesen kann ist, dass bei BeginTransaction() eben alle Änderungen in TempDB mit Satzversionen geschrieben werden und nach Commit/Rollback eben weg sind, unabhängig von Trigger oder nicht.

Was spricht dagegen Aufgaben, die mehrere Aktionen konsistent halten sollen in eine Transaktion zu packen?
AutoCommit wäre in diesem Fall jedenfalls fatal.

Und wie beschrieben, eine geschachtelte Transaktion erlaubt Veränderungen, die keinem Rollback unterliegen, Beispiel Protokolle über Zugriffe und sonst was, die im Falle eines Rollback außerhalb des Triggers ebenso weg wären.

Die Output-Klausel ist nur ein Ersatz für After-Insert/Update-Trigger und kann nicht mit Before-Insert/Update verglichen werden und liefert das Ergebnis der Operation Update/Insert/Delete, wenn also schon alles passiert ist.
Wenn ich den Inhalt vor der Aktion haben möchte benötige ich also trotzdem einen Select.

Ein After-Update/Insert macht auch etwas weniger Sinn als ein Before-Update/Insert, zumal ich dann z.B. Unterlassungswerte (Null's) mit nicht konstanten Defaults ergänzen kann.

Zusätzlich kann ich Fehler auswerfen bevor die Daten in der Datenbank sind, nachher ist meistens zu spät, vor allem bei AutoCommit.
Wer hauptsächlich mit AutoCommit arbeitet hat den Sinn von Transaktionen und der Erleichterung in der Programmierung bei Fehlern noch nicht verinnerlicht.

Und was die Constraints angeht, so habe ich diese bereits mit Triggern lösen können, bevor es Constraints überhaupt gab (wobei hier laufend Neue erfunden werden). OK, das mag schon eine Weile her sein, aber mit Constraints kann ich halt noch nicht alles erledigen.
Wie du schon sagst, Constraints sind ausschließlich Prüfungen für True/False, selbst wenn ich dort UDF's verwenden darf.
Trigger können da schon erheblich mehr, als reine Constraints.

Und Halbwahrheiten sind dies ja nun auch nicht;-) sondern Erfahrungswerte und ja, man kann sicherlich aus unterschiedlichen Konzepten durchaus lernen.

Answer 25

Hi,

Wie du schon sagst, Constraints sind ausschließlich Prüfungen für True/False, selbst wenn ich dort UDF's verwenden darf.

auch wenn ich den Thread gesplittet habe, damit der OP im Originalthread evtl. irgendwann auch mal eine Anwort erhält, hierzu auch nochmal der Hinweis, dass es dem OP genau darum ging. Er braucht nur die Möglichkeit, ein INSERT/UPDATE anhand einer Datenprüfung vorzunehmen oder das eben abzulehnen. Nicht mehr und nicht weniger.

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

Answer 26

Genau und da wurde der Triggervorschlag gleich als Pflaster und schlechter Programmierstil zerissen, wogegen ich mich einfach wehre und es trotzdem mit Trigger empfehle, zumal es nicht um Ablehnung ging.

Answer 27

Genau und da wurde der Triggervorschlag gleich als Pflaster und schlechter Programmierstil zerissen, wogegen ich mich einfach wehre und es trotzdem mit Trigger empfehle, zumal es nicht um Ablehnung ging.

Nuja, ich persönlich sehe Trigger für den Anwendungszweck des OP auch als schlechtesten Weg. Aber wie Du schon sagtest: Letztendlich ist das alles eine Frage der Betrachtung. Jeder hat so seine Vorlieben. Ich für meinen Teil setze Techniken dort ein, wo ich denke, dass sie angebracht sind. Für eine Datenprüfung, die ich auf DB Ebene durchführen muss und die mir ähnlich wie FKs, PKs, ... einfach sagen "Geht oder geht nicht", nutze ich Constraints und keine Trigger.

Zusammengefasst: Trigger sind natürlich nützlich und brauchbar. Nur hier nicht. (Meine Meinung^^)

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

Answer 28

(1)

Und was ich nachlesen kann ist, dass bei BeginTransaction() eben alle Änderungen in TempDB mit Satzversionen geschrieben werden und nach Commit/Rollback eben weg sind, unabhängig von Trigger oder nicht.

(2)
Was spricht dagegen Aufgaben, die mehrere Aktionen konsistent halten sollen in eine Transaktion zu packen?
AutoCommit wäre in diesem Fall jedenfalls fatal.

(3)
Und wie beschrieben, eine geschachtelte Transaktion erlaubt Veränderungen, die keinem Rollback unterliegen, Beispiel Protokolle über Zugriffe und sonst was, die im Falle eines Rollback außerhalb des Triggers ebenso weg wären.

(4)
Die Output-Klausel ist nur ein Ersatz für After-Insert/Update-Trigger und kann nicht mit Before-Insert/Update verglichen werden und liefert das Ergebnis der Operation Update/Insert/Delete, wenn also schon alles passiert ist.
Wenn ich den Inhalt vor der Aktion haben möchte benötige ich also trotzdem einen Select.

...

(5)
Wer hauptsächlich mit AutoCommit arbeitet hat den Sinn von Transaktionen und der Erleichterung in der Programmierung bei Fehlern noch nicht verinnerlicht.

...

(6)
Und Halbwahrheiten sind dies ja nun auch nicht;-) sondern Erfahrungswerte und ja, man kann sicherlich aus unterschiedlichen Konzepten durchaus lernen.

(1)
Das ist immer noch falsch. Korrekt ist, was ich oben schrieb. Wiederholung hilft da nichts. Vielleicht ist das im Kontext einer .Net-Funktions-Dokumentation falsch ausgedrückt worden, aber das ändert nichts daran, dass dieses Konzept längst nicht überall gilt. Wo, das schrieb ich oben bereits: Trigger und Snapshot-Isolation/Rowversioning.

(2)
Das war nicht meine Frage: Die Frage lautete: Warum ist ein "Begin Transaction" innerhalb einer Prozedur gleich ein Verstoß des Transaktionskonzeptes?? So oder so gibt es dann eine Transaktion. Ob das eine oder andere die bessere Vorgehensweise ist, kommt auf den Anwendungsfall an, oder?

Wozu vom Thema abweichen? Das wirkt als würde man unbedingt doch noch einen Punkt machen wollen, anstelle etwas zuende auszuführen, oder einzugestehen, das etwas doch nicht ganz durchdacht war.

(3)
Was ist das nun wieder für eine irreführende Aussage? „eine geschachtelte Transaktion erlaubt Veränderungen, die keinem Rollback unterliegen“ - Was passiert denn bei einem „ROLLBACK TRANSACTION“ wenn nicht genau das: Verlust aller Datenänderungen der gesamten „Transaktionkette“.
Denn: es gibt überhaupt keine geschachtelten Transaktionen. Sie „wirken“ nur so, als ob sie da wären, sind aber nur logisch definiert und nicht protokolliert“.  Es gibt nur genau eine. Das war auch schon immer so. Dieser Hinweis in diesem Rahmen gern kostenlos. (Gerne erläutere ich Transaktionen in SQL Server einmal an einem PASS Abend oder im Seminar)

(4)
Wie bitte? Ersatz für Trigger? Als ob Trigger die Standard-Funktionsweise einer Applikation wäre. Das wäre wohl die nächste Steigerung des Unsinns.

Über die Output-Klausel kann ich beim Update zB sehr wohl den VOR-Zustand eines Datensatzes noch mal eben erhalten und mit dem INSERT vergleichen. Betonung auf „Wert-Zustand“, nicht auf „vor der Aktion“.

(5)
Kann es sein, dass mich hier jemand absichtlich falsch verstehen will? Habe ich das geschrieben? Nein. Es ging nur um das Ändern des Modus. Das ist eine SET-Option, falls das nicht bekannt war. Soll hier absichtlich von der eigentlichen Aussage abgelenkt werden, um mir irgendwo ein Falschaussage „unterzujubeln“? Das ist eine gelinde gesagt seltsame Art zu „Antworten“.

(6)
Ok, dann sage ich es mal deutlich: Ihre "Antworten" strotzen voller technischer Falschaussagen. Beginnend bereits im Originalthread. – Das soll keine Beleidigung sein, sondern ist ein nachweisbarer Fakt.
Es ist sehr anstrengend, eine Diskussion zu führen, wenn in einem Paragraphen von 6 Aussagen 4 auf falschen Annahmen beruhen. Man muss nämlich versuchen den Sinn dahinter herzuleiten, die Fehler zu benennen, korrigieren, und dann kommt schon die nächste Riesenantwort gespickt mit Fehlinformationen, anstelle darauf einzugehen und einen Punkt mal zuende zu führen.
Korrekturen werden natürlich geflissentlich ignoriert. (Ich gebe zu, es erfordert eine gewisse Stärke, Fehler einzugestehen, und bei 40 Jahren Berufserfahrung festzustellen, das andere mit weniger „Jahren“ vielleicht doch weit tiefer in der Materie stecken)
Alles zusammen ist diese Art und Weise der Diskussion für niemanden hilfreich. Schon gar nicht für die später kommenden, die unter all der Wust die korrekten von den Fehl-Informationen unterscheiden müssen

In diesem Sinne verabschiede ich mich aus diesem Thread, der nur noch anstrengend ist und augenscheinlich nur noch den Sinn hat, dass jemand hier unbedingt ein Statement machen möchte.

der Andreas

---

Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
- nicht nur "Charter Member" (gabs "kostenlos" für alle 2008er MCMs dazu), sondern tatsächlich geprüft auf 2012
MCM SQL Server 2008
MVP Data Platform
www.SarpedonQualityLab.com | www.andreas-wolter.com

Answer 29

Nun wenn deine Empfehlung ist, diesem Thread doch nicht zu folgen, dann lösche ihn doch einfach.

Answer 30

Nun wenn deine Empfehlung ist, diesem Thread doch nicht zu folgen, dann lösche ihn doch einfach.

Hier wird nix gelöscht, nur weil ein paar Leute unterschiedlicher Meinung sind.

Solange es hier auf persönlicher Ebene friedlich abläuft, hat keiner etwas gegen eine gepflegte Diskussion.

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

Answer 31

Ich bin heute durch Zufall über den Artikel von Nick Craver (Stack Overflow: The Architecture - 2016 Edition) gestolpert. 

Ist vielleicht mal ganz interessant zu sehen wie so große Seitenbetreiber wie Stack Overflow, die Möglichkeiten von Triggern, Constraints und StoredProcedures nutzen (Wird da kurz beschrieben).

Ich Zitiere mal: Our usage of SQL is pretty simple. Simple is fast. Though some queries can be crazy, our interaction with SQL itself is fairly vanilla. "..." Let me put this another way: Stack Overflow has only 1 stored procedure in the database and I intend to move that last vestige into code.

Answer 32

Hallo Zusammen,
Jedes Model hat seine Berechtigung und richtig und falsch, gut oder schlecht ist hier nicht relevant.
Protierbarkeit oder Performance scheinen eher etwas zu sein auf das man achten sollte.
Die Lesbarkeit von Quelltext ist nicht hoch wenn da etwas dahinter steckt was man in diesem Moment nicht auf dem Bildschirm hat.

Sorry hierfür: Wenn da ein Werkzeugkasten steht mit vielen Schrauben diverser Größen, zweifelt man ja nicht ob der Hersteller der Schrankwand etwas falsch machte, nur weil er nur die eine Größe verwendete, wo es doch so viele gibt.

Man muss sich aus dem Werkzeugkasten das passende rausholen und weiß aber das die anderen Größen Ihre Bedeutung haben.

Eine SQL Datenbank sollte man mit Mengen füttern. Die Verarbeitung "Zeile" für "Zeile" ist, wenn das möglich ist im zugunsten einer Verarbeiten mit Mengenoperationen eliminieren.

Hier ein Beitrag bei dem es um den Vergleich Trigger / SP's ging bei System Versioned Temporal Tables.
Und nein, ich wusste nicht was gemeint sein könnte bis ich das las.

http://www.db-berater.de/2016/07/temporal-tables-verwendung-von-triggern/

Grüße Alexander

Answer 33

Leider ist die simplere Lösung "Before Update [or Insert]" hier nicht aufgeführt.
Dies erlaubt normalerweise das Ändern/Ergänzen der After-Variablen bevor sie in die Tabelle und ins Transaktionslog geschrieben werden. Die beschriebenen Probleme treten da gar nicht erst auf.

Andererseits kann es durchaus Transaktionsverläufe geben, die ein mehrfaches Update des selben Satzes erfordern. Nach der Beschreibung des Artikels hätte ich damit dasselbe Problem obwohl ich doch gar keine Trigger verwende.

Gerade bei Anwendungen mit Frameworks (Entity o.ä.) führt es innerhalb einer Transaktion zu Mehrfachupdates, die dann im beschriebenen Verfahren abgewickelt werden.
Was ist dann an der Verwendung eines Triggers schlechter als die Verwendung von Frameworks?

"Jedes Model hat seine Berechtigung und richtig und falsch, gut oder schlecht ist hier nicht relevant."

Das kann ich nur unterstreichen. Das Beispiel Stackoberflow zeigt, dass die Anwendung halt keine Trigger benötigt. Klassische ERP-Modelle, die es ja auch noch gibt, kommen baer sehr gut damit zurecht.

Answer 34

Leider ist die simplere Lösung "Before Update [or Insert]" hier nicht aufgeführt.
Dies erlaubt normalerweise das Ändern/Ergänzen der After-Variablen bevor sie in die Tabelle und ins Transaktionslog geschrieben werden. Die beschriebenen Probleme treten da gar nicht erst auf.

Guten Morgen,

sofern Du dich auf den von Alexander geposteten Link beziehst, so kann ein BEFORE UPDATE (INSTEAD OF) nicht greifen, da diese Art der Implementierung in System Versioned Temporal Tables nicht erlaubt ist. Der Artikel hat auch nicht unmittelbar mit der in diesem Thread geführten - interessanten - Diskussion zu tun. Darin ging es eher um die generellen Nachteile in Verbindung mit SVTT.

---

Uwe Ricken (Blog | Twitter)
Microsoft Certiied Master - SQL Server 2008
Microsoft Certified Solution Master - CHARTER Data Platform
Microsoft Certified Solution Expert - Data Platform
db Berater GmbH
Microsoft SQL Server Blog (german only)

Answer 35

Ich wusste doch, dass SQL Server noch immer keine normale Datenbank ist und ich deshalb lieber mit anderen DB's arbeite die das alles unterstützen (meine ganz persönliche Meinung).
Von nun an halte ich mich da raus, wenn ich so lese was SQL-Server bis heute noch nicht alles kann.
Wer von einer DB2 oder Oracle kommt muss sich da ganz schön umstellen und erhebliche Klimmzüge machen. Dort gehört sowas zum Standard. Kein Wunder dass hier alles mit Prozeduren gemacht werden muss.
Schade eigentlich.

Answer 36

Hi,

jedes DBMS hat seine Eigenheiten und natürlich auch seine Vor- und Nachteile.

Allerdings muss ich gestehen, dass ich deine Ausage:

Ich wusste doch, dass SQL Server noch immer keine normale Datenbank ist und ich deshalb lieber mit anderen DB's arbeite die das alles unterstützen (meine ganz persönliche Meinung).
Von nun an halte ich mich da raus, wenn ich so lese was SQL-Server bis heute noch nicht alles kann.

dann so verstehe, dass dein bisheriges Wissen doch eher ein "gefährliches Halbwissen" (so nenn ich das, wenn man denkt, etwas zu wissen aber es doch eher eine persönliche Meinung ist) sein dürfte, oder?

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

Answer 37

Rein bezogen auf den SQL-Server hast du sicherlich Recht, allerdings würde ich das nicht als gefährlich einstufen, denn nur weil der SQL-Server mit Triggern nicht vernünftig umgehen kann, ist die Verwendung derselben ja nicht gefährlich;-). Der Nachteil ist einfach, dass ein Trigger erst zieht, wenn der Schaden (also der Insert/Update  Geschichte ist) bereits angerichtet ist und ich das nur noch mit dem gesamten Abbruch der Transaktion beheben kann, denn nicht alles lässt sich per Constraints erledigen.
Das erfordert dann einfach nicht unerheblich Mehraufwand in das Design und die Businesslogik.
Und wenn mich mal wieder jemand fragt, ober er guten Gewissens von einer DB2/Oracle zu einem SQL-Server wechseln kann, werde ich das nun ehrlich nicht mehr empfehlen. Es bedarf da dann leider einer tieferen Analyse, was denn mit dem Wechsel erreicht werden soll.

Ich muss auch zugeben, dass mich dieser Thread zumindest einiges gelehrt hat;-).

Answer 38

Hallo und Guten Morgen,

mit der Aussage "...dass SQL Server noch immer keine normale Datenbank ist..." tust Du dem Microsoft SQL Server Unrecht. Selbstverständlich ist SQL Server eine "normale" relationale Datenbank, wie auch die anderen von Dir genannten Produkte.

"Der Nachteil ist einfach, dass ein Trigger erst zieht, wenn der Schaden (also der Insert/Update  Geschichte ist) bereits angerichtet ist und ich das nur noch mit dem gesamten Abbruch der Transaktion beheben kann, denn nicht alles lässt sich per Constraints erledigen."

Das ist nicht generell richtig. Du hast - außerhalb von System Versioned Temporal Tables - sehr wohl die Möglichkeit, VOR dem INSERT / UPDATE / DELETE mit Hilfe von INSTEAD OF-Triggern zu arbeiten.

Wie der Name bereits impliziert, werden die Trigger VOR dem eigentlich Schreiben gefeuert. Hierbei wird nur ein Intent Exclusive Lock auf das Objekt selbst gesetzt. Diese Sperre ist mit einem IS-Lock kompatibel und es entstehen keine Blockierungen durch den schreibenden Prozess.

Die Besonderheit eines INSTEAD OF Triggers besteht vor allen Dingen darin, dass er VOR der Prüfung möglicher CONSTRAINTS ausgeführt wird. Das folgende Beispiel soll dieses Verhalten demonstrieren:

USE TEMPDB;
GO

CREATE TABLE dbo.Test
(
	Id	INT			NOT NULL,
	C1	CHAR(100)	NOT NULL,
	D1	DATE		NOT NULL	CHECK (D1 >= '20170101')
);
GO

Die Tabelle besitzt einen CONSTRAINT auf D1 und verhindert, dass ein Datum vor dem 01.01.2017 eingetragen wird. Anschließend werden zwei Trigger erstellt, die jeweils VOR und NACH dem INSERT-Prozess gefeuert werden!

CREATE OR ALTER TRIGGER dbo.trg_test_before_insert
ON dbo.Test
INSTEAD OF INSERT
AS
	SET NOCOUNT ON;

	RAISERROR (N'Before trigger...', 0, 1);

	SELECT	@@TRANCOUNT,
			*
	FROM	sys.dm_tran_locks
	WHERE	request_session_id = @@SPID
			AND resource_type != N'DATABASE';

	RAISERROR (N'Hier könnte ihre laaaaange Werbung stehen...', 0, 1) WITH NOWAIT;
	WAITFOR DELAY '00:00:05';
		
	INSERT INTO dbo.Test
	SELECT Id, C1, CASE WHEN D1 < '20170101' THEN GETDATE() ELSE D1 END
	FROM inserted;

	SELECT	@@TRANCOUNT,
			*
	FROM	sys.dm_tran_locks
	WHERE	request_session_id = @@SPID
			AND resource_type != N'DATABASE';

	SET NOCOUNT OFF;
GO

CREATE OR ALTER TRIGGER dbo.trg_test_after_insert
ON dbo.Test
FOR INSERT
AS
	SET NOCOUNT ON;

	RAISERROR (N'after trigger...', 0, 1) WITH NOWAIT
	SELECT	@@TRANCOUNT,
			*
	FROM	sys.dm_tran_locks
	WHERE	request_session_id = @@SPID
			AND resource_type != N'DATABASE';

	SET NOCOUNT OFF;
GO

In den INSTEAD-OF-Trigger habe ich einfach eine Verzögerung von 5 Sekunden eingebaut, um eine lang laufende Transaktion zu simulieren. Wird nun der erste Datensatz eingetragen, der einer CONSTRAINT-Prüfung nicht standhält, so wird der Trigger dennoch gefeuert - somit kann bewiesen werden, dass der eigentliche Schreibprozess noch nicht begonnen hat. Interessant dabei ist nur, dass die Tabelle selbst mit einem IX-Lock gesperrt wird.

Erst beim Schreibprozess selbst werden auch Datenseite und Datensatz gesperrt:

Sobald der BEFORE-UPDATE-Trigger schreibt, wird auch der INSERT-Trigger gefeuert. Es werden aber keine zusätzlichen Sperren mehr gesetzt und der Prozess ist vollständig in einer in sich abgeschlossenen Transaktion abgesichert.

Deine Vergleiche zwischen RCSI und dem Verfahren in ORACLE hinken aus meiner Sicht etwas. ORACLE verwendet eine vollständig andere Technologie für konkurrierendes Lesen - ORACLE verwendet die standardmäßig vorhandenen UNDO-Segmente für das Lesen. Ich persönlich halte diese Version für deutlich performanter, da - LEIDER - bei vielen SQL Server Systemen die TEMPDB-Datenbank ein eher klägliches Dasein mit zu wenig Beachtung. Zu viele Entwickler sehen in RCSI auch eine "Silver Bullet" die alle Probleme lösen kann. Das ist natürlich falsch!

Meine persönliche Meinung zu SQL Server vs. andere Datenbanken ist die, dass JEDES Produkt seine Vor- und Nachteile hat. ORACLE verliert mehr und mehr Marktanteile an Microsoft nicht unbedingt wegen eines "schlechten" Produkts sondern wegen der unverschämten Preispolitik (insbesondere bei der Virtualisierung!).

Jeder soll mit dem Produkt glücklich werden, das er persönlich für das bessere Produkt hält. Ich würde mir aber nicht anmaßen, bei ORACLE von einer "... nicht normalen Datenbank..." zu sprechen; dazu kenne ich das Produkt nicht so gut wie "meinen" SQL Server. Gleiches solltest Du eventuell auch mal überdenken - aus den vorherigen Antworten kam immer wieder eine Rolle rückwärts von Dir, weil Andere dich davon überzeugen konnten, dass Deine Annahmen auf falschem Kenntnisstand beruhten :).

Um den Kreis zu schließen: System Versioned Temporal Tables können keine BEFORE-Trigger verwenden, da der ANSI-Standard diese "Manipulation" nicht unterstützt:

"Actions are triggered only for actions on open rows, that is, rows that have not been logically deleted from the table". Es gibt jedoch einen Workaround, der es möglich macht und Deine Favorisierung von einem 3-Schichten-Modell unterstützt - die Verwendung von VIEWS mit BEFORE-Triggern :)

Herzliche Grüße aus dem Rhein-Main-Gebiet...

PS: Ich finde die Diskussion immer noch sehr interessant; sie sollte aber auch weiterhin so sachlich geführt werden, wie zuvor.

PPS: Auch ich gestehe, dass ich ein ABSOLUTER FAN von einem 3-Schichten Modell in der Datenbank-Entwicklung bin. Ich habe dazu schon mehrfach einen Vortrag gehalten. Einige Skeptiker konnte ich überzeugen; vielleicht gelingt es Dir ja auch.

---

Uwe Ricken (Blog | Twitter)
Microsoft Certiied Master - SQL Server 2008
Microsoft Certified Solution Master - CHARTER Data Platform
Microsoft Certified Solution Expert - Data Platform
db Berater GmbH
Microsoft SQL Server Blog (german only)

Answer 39

Nun, laut vorherigen Beiträgen ist ein Instead-Of-Trigger aber in einigen Fällen gar nicht erlaubt.
Instead-Of wird i.d.R. verwendet, bei anderen DB's;-), wenn ich das Datenmodell z.B. unabhängig von der Anwendung mal umstellen muss (ggf. Optimierungen), oder in eine View, die normalerweise nicht änderbar ist, per Trigger eben Update/Insert/Delete trotzdem zu ermöglichen.

Nun, der Umweg über eine View und Instead-Of erfordert jedoch trotzdem noch das Lesen der Before-Daten, ja ich weiß, hinterher kann ich sie ja wieder bekommen (inserted/deleted). Also so richtig ist das auch kein Ersatz.

Der Vorteil eines tatsächlichen Before-Triggers ist ja gerade, dass ich Old/New-Variablen habe die ich mir nicht erst mühsam zusammensuchen muss. Aber das ist nun mal ein anderes Konzept, das einfach mit SQL-Server nicht geht.

Answer 40

Nun, laut vorherigen Beiträgen ist ein Instead-Of-Trigger aber in einigen Fällen gar nicht erlaubt.

Mithilfe von INSTEAD OF INSERT-Triggern für eine Sicht oder eine Tabelle kann die Standardaktion der INSERT-Anweisung ersetzt werden. Für "System Versioned Temporal Tables" sind INSTEAD OF -Trigger weder bei der aktuellen noch bei der Verlaufstabelle zulässig, um zu verhindern, dass die DML-Logik ungültig wird.

https://docs.microsoft.com/de-de/sql/relational-databases/tables/temporal-table-considerations-and-limitations

AFTER -Trigger sind nur in der aktuellen Tabelle zulässig. In der Verlaufstabelle werden sie blockiert, um zu vermeiden, dass die DML-Logik blockiert wird.

Das Konzept von Temporal Tables in ORACLE (Flashback-Queries) basiert auf einer ähnlichen Implementation (FLASHBACK Features). Hier weiß ich aber nicht, ob es ebenfalls die Einschränkungen von INSTEAD OF-Triggers gibt.

Daraus folgt für mich, dass es - in Bezug auf "normale" DML-Operationen keine Einschränkungen auf Standard-Benutzer-Tabellenobjekte gibt!

Nun, der Umweg über eine View und Instead-Of erfordert jedoch trotzdem noch das Lesen der Before-Daten

Diesen Hinweis verstehe ich nicht ganz. Wenn ich ein Update auf einen Record mache, dann muss ich auf jeden Fall den betreffenden Datensatz "suchen". Ich habe also - unabhängig von der Art des Triggers - eine IO-Operation auf den Daten. Ist das zu suchende Attribut indexiert, ist der Aufwand vernachlässigbar.

Der Vorteil eines tatsächlichen Before-Triggers ist ja gerade, dass ich Old/New-Variablen habe die ich mir nicht erst mühsam zusammensuchen muss.

Hier - so glaube ich - liegt das Mißverständnis der gesamten Diskussion! Die "Variablen" gibt es selbstverständlich in einem INSTEAD-OF Trigger in SQL Server ebenfalls. ORACLE spricht von "Transaktions-Variablen (:OLD, :NEW), meint aber vom Prinzip nichts anderes als Microsoft SQL Server!

"Bei Oracle gibt es keine Transitionstabellen, nur die Variablen. Alle übrigen Aussagen gelten analog."

Diese "Variablen" sind nichts anderes als Tabellenstrukturen mit den Daten VORHER (deleted | :OLD) und NACHHER (inserted | :NEW). Das nachfolgende Beispiel kann das sehr einfach belegen:

Basierend auf dem ersten Beispiel wird noch ein INSTEAD OF UPDATE-Trigger erstellt, der nicht wirklich Daten einträgt sondern ausschließlich den Inhalt von inserted und deleted ausgibt:

CREATE TRIGGER dbo.trg_test_before_update
ON dbo.test
INSTEAD OF UPDATE
AS
	SET NOCOUNT ON;

	SELECT * FROM inserted;
	SELECT * FROM deleted;

	SET NOCOUNT OFF;
GO

Die Abfrage wird bei jedem UPDATE-Versuch die "Altdaten" und die "Aktualisierungen" zeigen - sie werden nur NIE eingetragen, da der INSTEAD OF-Trigger selbst dafür sorgen muss, dass die Aktualisierungen persistiert werden.

---

Uwe Ricken (Blog | Twitter)
Microsoft Certiied Master - SQL Server 2008
Microsoft Certified Solution Master - CHARTER Data Platform
Microsoft Certified Solution Expert - Data Platform
db Berater GmbH
Microsoft SQL Server Blog (german only)

Answer 41

Siehst du, und genau dies ist ja eben der Unterschied:
Wenn man nochmal in die Doku schaut, dann wird ein Trigger eben gar nicht Satz für Satz (oder Zeile für Zeile) aufgerufen sondern pro Aktion!
D.h, ich muss mit den inserted/deleted-Tabellen arbeiten um eben keinen Satz zu vergessen.
Ein Update, der gleich mehrere Zeilen betrifft (was ja nicht unüblich ist), löst genau 1x den Trigger aus, der sich nun aus den beiden Tabellen die jeweiligen Before/After-Daten selber raussuchen muss und auch keine Zeile der Tabellen vergessen darf.
Dasselbe gilt dann ebenso für einen Insert, wobei hier der Trigger nach einem Bulk-Insert eben erst nach der letzten Zeile aufgerufen wird.
In beiden Fällen, also Update/Insert erfolgt die Nachbearbeitung halt erst, wenn alles bereits in der Datenbank passiert ist, das gilt i.Ü. natürlich auch für den Delete.

Beim Instead-Of-Trigger muss ich mich nun sogar komplett um den Aufbau eines Update/Insert/Delete-SQL kümmern, da mir das ja nun nicht mehr vom SQL-Server abgenommen wird.

Also ist die Bearbeitung mit Old/New je Zeile einfacher als eine nachgelagerte Stapel-Verarbeitung da
a) noch keine Daten in der Tabelle stehen
b) ich nicht mittels weiterer SQL's auf die Before-Werte zugreifen muss.

Nun ja, einfach ein anderes Konzept, dass mir persönlich das Erstellen von BusinessLogik halt ein wenig erschwert. Hier muss ich halt wieder so denken wie zu alten ISAM-Zeiten, als es relationale Datenbanken mit Before-Triggern halt noch nicht gab;-).

Answer 42

Nachtrag zur Lizensierung (OT):
Dies ist zwar eigentlich wieder ein anderes Thema, aber der SQL-Server ist gerade auch im BI-Umfeld nicht gerade preiswert, da ja nun jeder User neben dem Basis-Preis zusätzlich lizensiert werden muss.
Preise im Netz zu finden gestaltet sich als nicht einfach. Das einzige was ich gefunden habe ist eine einzelne User-CAL für 230€!
Bei 100 Usern, die nur mal 1-2 Reports/Tag online abfragen möchten, kostet es den Kunden schon 23.000 Euro!

Kein Wunder, dass es so wenig Online-BI-Anwendungen gibt und man sich eher mit SSIS-Batchreporting herumschlägt um Lizenzen zu sparen. Mit BI hat das nicht wirklich was zu tun, das ist eher klassich Dataware-Housing.

Und was würde michein SQL-Server für eine ERP-Anwendung mit 1000 Usern nun tatsächlich kosten?
Ich hoffe nicht dann 230.000€;-)!

Und kann ich mich mit einem User von einem Gerät mehr als 1x am Server anmelden?

Answer 43

Hi,

bitte hör einfach auf, irgendwelche Vermutungen ohne jegliches Wissen hier zu posten. Das bringt weder dir noch sonst irgendwem etwas.

Wenn Du dich über die Lizenzierung von SQL Server ernsthaft informieren willst, tu das. Aber schreib nicht so einen Schmarrn.

Es gibt natürlich Prozessor/Core Lizenzen. Und auch andere Lizenarten wie die kostenlose Express Edition, die für den Abruf von 100 - 200 Reports am Tag in der Regel auch völlig ausreichen wird. Die Datenbankgröße sollte da auch kein Problem sein.

Im Vergleich mit anderen DBMS ist SQL Server eher noch günstig zu haben, da gibt es ganz andere Kaliber.

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

Answer 44

Ich sagte ja, bzgl. der Lizenzen ist es sehr schwierig sich zu informieren.
Der Express-Server mit 10GB ist wahrlich keine Alternative für ein ERP/BI-System. Das läuft sehr schnell über.
Auch hier finde ich nur Hinweise, dass ich den Express-Server nicht in einer Multi-Userumgebung auf einem Server einsetzen kann. Dazu benötige ich dann einen SQL-Standard mit mindestens Core-Lizensierung.
Ich poste ja auch keine Vermutungen sondern stelle nur Fragen.
Was kostet mich ein SQL-Server für ein ERP-System mit ca. 100GB (wachsend) für 1000 User?
Die Frage möchte ich einfach beantwortet haben, über die Microsoftseiten findet man nur die Lizenzmodelle und so gut wie keine Kosten oder Rechenbeispiele.

Dann zeige mir doch mal bitte die Links, die das eindeutig erklären was nötig ist und nicht was möglich ist.
Entscheidungshilfen gibt es da leider nicht.

Answer 45

Dann zeige mir doch mal bitte die Links, die das eindeutig erklären was nötig ist und nicht was möglich ist.
Entscheidungshilfen gibt es da leider nicht.

https://www.microsoft.com/en-us/sql-server/sql-server-2016-pricing

Wenn Dein ERP-System mit der Standard Edition auskommt, sind es $3,717 per Core unabhängig von der Anzahl der User. Wieviele Cores Du brauchst, musst Du selber wissen, wie bei jedem anderen DBMS auch.

Wenn Du virtualisierst, wird es komplizierter und ggfls. teuerer, aber auch da ist Oracle weit vorne.

Zu all diesen Dingen sagt der "Licensing Guide" alles Wesentliche, den man ebenfalls auf der oben verlinkten Seite herunterladen kann.

---

Evgenij Smirnov

I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> http://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

Answer 46

How to License SQL Server 2016 Using the Per Core Licensing Model
When running SQL Server in a physical OSE, all physical cores on the server must be licensed. Software partitioning does not reduce the number of core licenses required, except when licensing individual virtual machines (VMs). A minimum of four core licenses are required for each physical processor on the server.

D.h., dass auf einer 4-Core-CPU schon mal 4 x 3717$ = 14.868$ fällig sind.
Setze ich den SQL-Server auf einer 64-Core-Hardware ein, muss ich auch 64 Cores lizensieren!

Also bin ich schon mal gezwungen, zu virtualisieren um die Anzahl Cores einzuschränken, wobei folgendes gilt:

To license individual VMs using the Per Core model, customers must purchase a core license for each v-core (or virtual processor, virtual CPU, virtual thread) allocated to the VM, subject to a four core license minimum per VM. For licensing purposes, a v-core maps to a hardware thread.

D.h., unter 15.000$ wird das wohl nichts.
Ab den 4-Cores Minimum kann ich dann in 2er-Schritten á 7434$ aufrüsten.

Wenn meine ERP-Software z.B. für kleine Unternehmen (bis 100Mitarbeitern) nur 2000€ kostet, kann ich da von meinen Kunden nicht verlangen noch 15.000$ für die Datenbank auszugeben (derzeit ca. 12.500€).

Will ich dann auch noch Analytics (BI) wirds dann richtig teuer.

Alternativ lese ich dann, hat man halt die Möglichkeit einen Server zu lizensieren und dann eben per User, wobei eine Software, die der Datenbank gegenüber als ein User auftritt nicht gilt, es müssen a) tatsächliche User und/oder b) Geräte lizensiert werden.

Dann kostet eine Lizenz 931$ (ca. 770€) zzgl. per User/Gerät von (tja wieviel eigentlich genau) ca. 230€.
Also reines Rechenexemple: (12.500 - 770) / 230 = 51 User!

M.a.W., das User-CAL Modell lohnt sich ausschließlich für Firmen mit weniger als ca. 50 Usern, danach wird es teurer als eine Core-Lizenz.

Und Oracle?
Die machen es per Prozessor und nicht per Core!
Da kostet die Standard-Edition für 1 Prozessor (egal wieviele Cores, also auch bei 8 Cores) 17.500$, bie Microsoft kosten 8 Cores bereits knapp 30.000$.

Answer 47

Guten Morgen,

Wenn man nochmal in die Doku schaut, dann wird ein Trigger eben gar nicht Satz für Satz (oder Zeile für Zeile) aufgerufen sondern pro Aktion!

Bei allem Respekt - aber das ist doch genau der Sinn und Zweck der relationalen Paradigmen! Man arbeitet Set-orientiert und nicht Zeilenorientiert. Wenn das tatsächlich der von Dir gewünschte Ansatz ist, dann kannst Du das sehr wohl auch mit Cursors bewerkstelligen. Nur fehlt mir hier der gewünschte Ansatz von "schneller" Bearbeitung.

D.h, ich muss mit den inserted/deleted-Tabellen arbeiten um eben keinen Satz zu vergessen.

Das musst Du doch bei einer zeilenorientierten Bearbeitung auch machen, oder?

Hier mal zwei Beispiele, die den - aus meiner Sicht - gravierenden Unterschied zeigen:

CREATE OR ALTER TRIGGER dbo.trg_test_update
ON dbo.test
FOR UPDATE
AS
	SET NOCOUNT ON;

	DECLARE	@I	INT;
	DECLARE @C	CHAR(100);
	DECLARE @D	DATE;
	DECLARE C CURSOR
	FOR
		SELECT Id, C1, D1 FROM INSERTED;

	OPEN C
	FETCH NEXT FROM C INTO @I, @C, @D
	WHILE @@FETCH_STATUS != -1
	BEGIN
		IF @D < '20170101'
			UPDATE	T
			SET		D1 = '20170101'
			FROM	dbo.Test AS T
			WHERE	Id = @I;
		ELSE
			UPDATE	T
			SET		D1 = @D
			FROM	dbo.Test AS T
			WHERE	Id = @I;

		FETCH NEXT FROM C INTO @I, @C, @D;
	END

	CLOSE C;
	DEALLOCATE C;

	SET NOCOUNT OFF;
GO

Das Beispiel ist selbsterklärend und - aus meiner Sicht - totaler Schwachsinn in einer relationalen Datenbank. Ich möchte damit nicht sagen, dass es Workloads gibt, die sicherlich keine anderen Lösungsansätze bieten aber der Grundgedanke einer relationalen (Set Based) Orientierung geht hier vollständig verloren. Leider sehe ich obige Ansätze viel zu häufig in Anwendungen. Workloads, wie den obigen kann man mit wenigen Umständen in eine weit performantere Lösung transportieren, die dem relationalen Ansatz folgt:

CREATE OR ALTER TRIGGER dbo.trg_test_update
ON dbo.test
FOR UPDATE
AS
	SET NOCOUNT ON;

	UPDATE	T
	SET		D1 = CASE WHEN I.D1 < '20170101'
					  THEN '20170101'
					  ELSE I.D1
				 END
	FROM	dbo.Test AS T INNER JOIN inserted AS I
			ON (T.Id = I.Id)

	SET NOCOUNT OFF;
GO

Das gleiche Ergebnis - nur DEUTLICH performanter. Cursor - btw - benötigen leider auch TEMPDB und sind langsamer als setorientierte Lösungen!

Beim Instead-Of-Trigger muss ich mich nun sogar komplett um den Aufbau eines Update/Insert/Delete-SQL kümmern, da mir das ja nun nicht mehr vom SQL-Server abgenommen wird.

Ja, das stimmt! Aber der Sinn und Zweck eines INSTEAD OF (Da liegt die Intention ja bereits im Namen) soll ja "an Stelle von DML" ausgeführt werden. Dennoch hast Du bereits alle Informationen in den beiden temporären Objekten [inserted] und [deleted] vorhanden. Du kannst also bereits mit der Transformierung beginnen, obwohl Du noch keine Zeilen gesperrt hast!

Nun ja, einfach ein anderes Konzept, dass mir persönlich das Erstellen von BusinessLogik halt ein wenig erschwert

Das sehe ich - siehe oben - ein wenig anders :)

Dies ist zwar eigentlich wieder ein anderes Thema, aber der SQL-Server ist gerade auch im BI-Umfeld nicht gerade preiswert, da ja nun jeder User neben dem Basis-Preis zusätzlich lizensiert werden muss.

Na ja, da spricht dann der Blinde von der Farbe. Du musst die User nur lizensieren, wenn Du eine Serverlizensierung hast, nicht aber, wenn Du eine Core-Lizensierung hast. In diesem Fall kannst Du mit so vielen Usern das System verwenden, wie Du magst. Ein lieber Freund aus den USA (Joe Dantoni) hat darüber mal einen interessanten Blogeintrag gemacht.

https://joeydantoni.com/2016/08/18/please-please-stop-complaining-about-sql-server-licensing-costs-and-complexity/

Ich habe die Zahlen mal einem DBA in der Deutschen Bank hier in Frankfurt gezeigt; sofern kein Enterprise Licensing Modell für ORACLE vorliegt, sind diese Zahlen SEHR zuverlässig! Warum soll ich für 1.300.000 USD ein Produkt lizensieren, dessen Leistung ich auch für 10% des Preises bekommen kann.

Und was würde mich ein SQL-Server für eine ERP-Anwendung mit 1000 Usern nun tatsächlich kosten?
Ich hoffe nicht dann 230.000€;-)!

Natürlich nicht; wäre aber immer noch DEUTLICH preiswerter als eine ORACLE-Lösung. BTW: Was mich bei ORACLE wirklich zutiefst ankotzt, ist die Tatsache, dass Du z. B. eine Standardlizenz erwirbst aber auch Enterprise Features genutzt werden "könnten". Das wird getrackt! Bei einem Audit wird das geprüft und - ZACK - darfst Du die Kosten für eine Enterprise-Edition berappen. Das ist unfair; woher soll ein Junior-DBA wissen, welche Features Enterprise sind oder nicht? Diese Option gibt es bei SQL Server erst garnicht - Du bestellst Standard und bekommst auch nur Features der Standard-Edition; und die haben sich mit SQL 2016 extrem verbessert, da viele Features, die vormals einer Enterprise-Edition vorbehalten waren, nun auch in der Standard-Edition (mit Speicherlimitationen) vorhanden sind!

https://blogs.msdn.microsoft.com/sqlreleaseservices/sql-server-2016-service-pack-1-sp1-released/

Ich glaube aber, dass wir hier abschweifen und es zu einer SQL vs ORACLE-Debatte führen würde. Das ist mir zuwider und ist wie eine Diskussion über Religion :). Also belassen wir es einfach dabei, dass beide RDBMS-Systeme ihre Vor- und Nachteile haben.

Ich sagte ja, bzgl. der Lizenzen ist es sehr schwierig sich zu informieren.

Da gebe ich Dir Recht - insbesondere kannst Du 2 Lizenzexperten fragen und erhältst 3 unterschiedliche Antworten. Dennoch nur einmal bingooglen und schon gefunden:

http://download.microsoft.com/download/9/C/6/9C6EB70A-8D52-48F4-9F04-08970411B7A3/SQL_Server_2016_Licensing_Guide_EN_US.pdf

Der Express-Server mit 10GB ist wahrlich keine Alternative für ein ERP/BI-System. Das läuft sehr schnell über.

Das ist auch nicht die Intention der Express-Edition. Die Express-Edition ist für kleinere Anwendungen gedacht (z. B. Desktop-Anwendungen, Replikationen (Push-Abos), Staging, ...) Ich habe einen Kunden, der hat über 600 Express-Installationen bei den Aussendienstmitarbeitern vor Ort. Diese Lösung kostet keinen Cent und jeder Aussendienstmitarbeiter kann so mit "seinen" Daten zu den Kunden gehen.

Auch hier finde ich nur Hinweise, dass ich den Express-Server nicht in einer Multi-Userumgebung auf einem Server einsetzen kann.

Das ist nicht richtig. Auch mit einer EXPRESS-Edition kannst Du sehr wohl einen Multi-User-Betrieb betreiben. Die Einschränkungen beziehen sich auf die folgenden Punkte:

• Es wird nur ein Prozessor, aber bis zu 4 Prozessorkerne verwendet.
• Nutzt maximal 1 GB Arbeitsspeicher.
• Eine Datenbank darf maximal 10 GB groß sein.
• Die Volltextindexierung und -Suche ist nur in der Edition „Express with Advanced Services“ möglich.
• Der Dienst „SQL Server-Agent“, welcher z. B. die automatische Datensicherung steuert, ist nicht enthalten.

Es gibt keine Einschränkung in Bezug auf die Anzahl der gleichzeitigen Verbindungen. Letztendlich würde diese Einschränkung durch die Anzahl der Cores bereits eingegrenzt (Stichwort: Worker Threads).

Ich poste ja auch keine Vermutungen sondern stelle nur Fragen.

Bitte sehe es mir nach; aber das sind keine Fragen. Du stellst hier Behauptungen auf, die wir mit großem Elan versuchen, zu widerlegen. Ich hoffe, dass uns das auch ein Stück weit gelingt? :)

Was kostet mich ein SQL-Server für ein ERP-System mit ca. 100GB (wachsend) für 1000 User?

Die Größe der Datenbank ist - aus meiner Sicht - vollkommen irrelevant. Aber die Anzahl der Benutzer lässt nur wenig Spielraum für eine Lizenzierung mit 4 Cores. Ich würde hier mit mindestens 8 Cores in einer Standard-Edition beginnen. Wenn Du eine 24x7-Umgebung brauchst, sollte es dann schon die Enterprise-Edition sein, da der besondere Unterschied zwischen Enterprise-Edition und Standard-Edition in der Hochverfügbarkeit (AlwaysOn) liegt.

PS: Vielleicht ergibt sich ja mal die Möglichkeit, Dich auf einer Konferenz (SQL Saturday, IT-Tage Frankfurt, PASS CAMP, ...) zu treffen. Ich glaube, dass eine Diskussion mit Dir wirklich interessant wird.

Alles Gute aus dem Rhein-Main-Gebiet...

---

Uwe Ricken (Blog | Twitter)
Microsoft Certiied Master - SQL Server 2008
Microsoft Certified Solution Master - CHARTER Data Platform
Microsoft Certified Solution Expert - Data Platform
db Berater GmbH
Microsoft SQL Server Blog (german only)

Answer 48

Herzlichen Dank für diese mal wirklich freundlichen Worte;-).
Den License-Guide hatte ich mir ja angesehen, allerdings findet man nur Serverpreise und keine User-CAL's.
Daher weil ich ja Google u. Co. bemühe, kommen ja auch meine Behauptungen und die daraus resultierenden Fragen.

Und was den 8-Core-Vorschlag zu knapp 30.000$ Standard angeht, so kann sich den kaum eine kleine Firma mit 50-100 MA's leisten.

Was auch nicht so ganz aus dem ganzen Lizenzkram hervorgeht:
Wenn ich auf einem Windows-Server einen SQL-Server (oder auch andere) benutze, benötige ich dann auch Windows-Server-User-CAL's da ich ja als User nicht nur die Datenbank in Anspruch nehme (habe ich aus irgendeinem anderen Beitrag entnommen)?
Dann würde es tatsächlich ganz schön durcheinander und fast schon nicht mehr bezahlbar.
Da kann ich die Leute schon verstehen (anderer Thread) die 15 VM's auf einem 2012er-Server laufen haben und nun beim Update auf 2016er an den Lizenzkosten scheitern.

Ich glaube nicht, dass ich an solchen Tagungen irgendwann mal teilnehmen werde, schließlich muss ich die ja selber bezahlen;-). Da gehts mir wie mit den Lizenzen.

Answer 49

Hallo

Setze ich den SQL-Server auf einer 64-Core-Hardware ein, muss ich auch 64 Cores lizensieren!

Leider ja - selbst, wenn Du nur eine Standard-Edition installierst (max 24 Cores). Ist wirklich "schei..."!

Will ich dann auch noch Analytics (BI) wirds dann richtig teuer.

Nein! Der komplette BI-Stack ist bereits in der Standard-Edition enthalten. Diese Features musst Du bei anderen Herstellern extra bezahlen, aber nicht bei Microsoft!

M.a.W., das User-CAL Modell lohnt sich ausschließlich für Firmen mit weniger als ca. 50 Usern, danach wird es teurer als eine Core-Lizenz.

Das ist eine Milchmädchen-Rechnung. Ich könnte ja auch eine Serverlizenz für 24 Cores kaufen und dann kann ich deutlich mehr User damit arbeiten lassen. Aber vom Prinzip ist es richtig; man muss die Kosten gegeneinander aufrechnen und vergleichen!

Da kostet die Standard-Edition für 1 Prozessor (egal wie viele Cores, also auch bei 8 Cores) 17.500$,

Du vergisst hier aber, dass Du gezwungen bist, auch einen Supportvertrag abzuschließen. Die Kosten liegen (bei Deinem Beispiel) bei jährlich 3,850 USD!

Ich glaube nicht, dass ich an solchen Tagungen irgendwann mal teilnehmen werde, schließlich muss ich die ja selber bezahlen;-).

Die SQL Saturdays sind kostenlose Veranstaltungen. In D findet der SQL Saturday immer im Juni in St. Augustin statt.

http://www.sqlsaturday.com

Jede Medaille hat zwei Seiten :)

---

Uwe Ricken (Blog | Twitter)
Microsoft Certiied Master - SQL Server 2008
Microsoft Certified Solution Master - CHARTER Data Platform
Microsoft Certified Solution Expert - Data Platform
db Berater GmbH
Microsoft SQL Server Blog (german only)

Answer 50

Gerade bei Anwendungen mit Frameworks (Entity o.ä.) führt es innerhalb einer Transaktion zu Mehrfachupdates, die dann im beschriebenen Verfahren abgewickelt werden.

Was ist dann an der Verwendung eines Triggers schlechter als die Verwendung von Frameworks?

"Jedes Model hat seine Berechtigung und richtig und falsch, gut oder schlecht ist hier nicht relevant."

Die Grundlegend geht es ja da nicht um ein Framework sondern um die Frage packe ich meine Business Logik in die DB oder in eine APP (bzw. Webservice) und da gibt es schon einige Punkte die dafür Sprechen sie in die APP zu packen.

Skalierbarkeit:

Das es deutlich einfach ist einen Zusätzlichen Client hinzustellen, als einen 2. DB Server und die Datenbanken sich Synchronisieren zu lassen. Hatte ich ja schon angesprochen. Was mir nach euren Preis angaben auch noch eingefallen ist. Auch deutlich günstiger.  

Testbarkeit:

Ja man kann auch automatisierte Tests für eine DB schreiben. Es ist aber meines Wissens deutlich aufwändiger und reine Unit Test kann man glaube ich gar nicht schreiben. 

OOP und Flexibilität

Grade wenn ich DRY umsetzen möchte oder Komplexere Bussiness Regeln habe ist OOP wirklich Mächtig. Und DI und IoC Container sorgen für eine sehr Große Flexibilität. Ich kann die Bussiness Regeln einfach je nach Kunde austauschen.

Bessere Tools

Wenn ich mir anschaue was Visual Studio alles so kann und dann was das SQL Managemant Studio so kann. Wenn ich bei einer Klasse ein Propery umbenenne wird es überall mit umbenannt. Ich müsste jetzt nicht das es funktioniert, das wenn ich eine Tabellen Spalte umbenenne sie in allen Stored Procedures und Triggern mit umbenannt wird. Beim Trigger bin ich mir noch nicht mal sicher ob ich es bei Insert oder so merke.

Ich denke mal das ist ja grundlegend schon einiges.

Answer 51

Und zu guter letzt noch das Deployment (Verteilung der Updates).
Hier muss ich dann auch noch sicherstellen, dass alle Clients die Ergänzungen/Erweiterungen und vor allem die Veränderungen nach Möglichkeit alle gleichzeitig bekommen. Denn ein Weiterarbeiten ist sol lange nicht möglich bis auch der letzte Client seinen Update hat (alles schon mal dagewesen).

Die Skalierbarkeit liegt in der Technologie der Datenbank selber. Nicht umsonst kann man Datenbanken verwalten, die größer als die derzeitigen Platten sind.

Und was das Testen angeht, so ist durch die CLR-Integration das Schreiben von c#/vb-Triggern möglich und auch testbar. Auch VisualStudio gibt hier entsprechende Unterstützung.
https://msdn.microsoft.com/de-de/library/zefbf0t6%28v=vs.100%29.aspx?f=255&MSPPError=-2147217396

Und was das Datenmodell angeht so sollte man bei Namensänderungen in Richtung bestehender Tabellen ganz schön vorsichtig sein, denn das schlägt mitunter auf die Frameworks durch die dann selbstständig anfangen die Tabellen umzuschaufeln und neu zu definieren.

Und gerade was das Testen angeht so hat doch wohl jeder eine entsprechende Testumgebung (ein SQL-Server kann wohl durchaus ja mehrere Datenbanken) bevor man seine Anwendung auf das Echtsystem loslässt.

Und nun sind gerade Trigger, Prozeduren und Funktionen schneller für alle auf einem Server installiert als auf allen Clients, soweit die Änderungen Clients nicht betreffen. Sicherlich gibt es da auch Kombinationen.

Und wir reden hier von einem Datenmodell auf einem SQL-Server und nicht von einem hochkomplexen Berechnungsmodell, dass ich per Multicomputing über 100te oder gar 1000de Rechner verteilen muss um überhaupt fertig zu werden.
Eine ERP-Anwendung über Clients zu skalieren erfordet normalerweise ebenso Mitarbeiter, die diese Clients auch bedienen.

Answer 52

Beim Deployment von Clients mach ich mir keine Sorgen.

Im Intranet kann ich es für Fat Clients, einfach über Click-Onc bereitstellen. Beim Starten der Anwendung wird einfach die aktuelle Version installiert.

Bin ich nicht im Intranet, kann ich es zwar genau so machen. Aber ich würde da grundlegend Zwischen der DB und dem Client einen Service (WebApi) dazwischen legen. Der versionierte Schnittellen hat wenn nötig. Bzw ich habe das eine Webseite.

Da sollte das Deployment aber Automatisch über unser Build System laufen. (Wenns im Netz ist.) Bei uns intern läuft es so (WebSeite). Jede Nacht wird für die QS Automatische ein Build erstellt bei dem Dev, Main und Release intern veröffentlicht werden.

Da die Seiten bei den Kunden Teilweise im Intranet laufen, kann ich das leider nicht so machen.

Grundlegend machen wir es das die Kunden bei Wunsch erst mal, eine 2. Seite an der sie Testen können. Und wenn wir es dann ins Produktive System übernehmen, wird vom alten Stand ein Backup gemacht (Dauert grob 30sec) und dann die neue Version eingespielt (auch noch mal Grob 30sec).

Da hab ich echt keine Angst.

DB Updates mach ich ungern. Auch da mache ich ohne Backup nichts. Das kann bei einem Kunden schon mal eine Stunde dauern (wir erheben Produktions Daten, da kann echt viel Anfallen). Und dann wird die neue Version eingespielt. An der DB Probieren wir eigentlich möglichst wenig zu ändern.

Ich persönlich mach halt lieber Client Updates als DB Updates und da sich Buissnes Logic schon mal häufiger ändert, hab ich sie dann auch lieber in den Clients.

Bei der Skalierbarkeit geht es auch nicht um die Datenmenge. Sondern um die Performance.

Logik zu verarbeiten kostet auch immer Rechenleistung. Und es ist halt deutlich Leichter und günstiger einen zusätzlichen Webserver oder ähnliches Bereitzustellen. Als einen zusätzlichen SQL Server und zwischen den Beiden die Daten Synchronisieren zu lassen.

Was die Unit Tests angeht.

Erstmal ist dein Link fürs Debuggen. Es gibt aber auch Unit Test für SQL.

Dabei handelt es ich aber eher um Integations Test und die sind meist deutlich komplexer und aufwändiger zu schreiben als reine Unit Test.

Wir haben bei uns beides bei CI Build laufen nur die Unit Test, der dauert mit allem drum und dran ca. 5 min. Beim Nightly Build laufen bei und auch die Integrations Test, das dauert dann so 40 min.

Also soweit ich es beurteilen kann sind Test für den Logic auf den SQL Server deutlich komplexer.

Und was mir noch eingefallen ist. Solange ich Vanilla SQL (grob CRUD) befehle benutze. Sind die Funktionsweisen auf allen SQL Servern sehr ähnlich und gleich Performant. Bei Triggern usw. Scheint es ja zwischen den Anbietern einiges an unterschieden zu geben. Ich brauche also weniger Produkt spezifisches wissen. Und Vanilla SQL beherrscht eigentlich jeder Entwickler den ich kenne.

Answer 53

"Und vanilla SQL beherrscht eigentlich jeder Entwickler, den ich kenne."

Und genau deswegen läuft mein Geschäftsmodell auch so gut :)

SCNR...

---

Uwe Ricken (Blog | Twitter)
Microsoft Certiied Master - SQL Server 2008
Microsoft Certified Solution Master - CHARTER Data Platform
Microsoft Certified Solution Expert - Data Platform
db Berater GmbH
Microsoft SQL Server Blog (german only)

Answer 54

Klar kann ich mich auf Vanilla SQL beschränken, aber welche Version ist damit genau gemeint?
https://de.wikipedia.org/wiki/SQL

Je geringer die Basis desto geringer der Leistungsumfang.
Jetzt ist es schon mühsam, genau herauszufinden, was ab welcher Version geht.
Gehört ein Join schon zu Vanilla?
Gehört eine "Derived Table" oder ein sog. "Commom Table Expressen" (CTE) zu Vanilla?
Wie sieht es mit Constraints aus, die es auch erst ab einer Version x gibt?
Was ist mit scalaren Funktionen?
Wenn ich schon alleine an die unterschiedlichen Implementierungen von Substring denke...

Es gibt nur wenige Anwendungen die sich auf Vanilla beschränken um die Datenbank austauschbar zu halten.
Und der kleinste gemeinsame Nenner beschränkt sich da wirklich nur auf Select/Update/Insert/Delete mit ein wenig Grundrechenarten und 5 Aggregaten (Sum/Min/Max/Avg/Count).
Wer kommt ernsthaft damit alleine zurecht?
Was ist mit den ganzen Pivot-Funktionen (Over/Partition) die ebenso unterschiedlich implementiert sind?

Und was das Refactoring angeht, so kann man diesbezüglich alles tun, was intern in den einzelnen Modulen läuft.
Sobald man aber Schnittstellen egal welcher Art nach außen publiziert hat, empfielt sich hier kein Refactoring ohne einen massiven Kompatibilitätsbruch zu riskieren.
Gerade wenn ich an OOP denke und anderen Anbietern Schnittstellen bereitstelle und sogar meine Objekte vererbbar mache, darf ich noch nicht mal Protected-Variablen/Funktionen umbenennen.
Allenfalls muss ich dann Wrapper bereitstellen, Funktionen als "Obsolet" deklarieren und den Drittanbietern eben mitteilen: wenn Du Deine Software nicht an meine neue Version anpasst, dann kann der Kunde Deine AddOn's halt nicht mehr verwenden.
Das ist im Moment genau das, was z.T. durch Microsoft versucht und initiiert wird.

Ich, als kleiner Software-Hersteller kann das meinen Kunden in keinster Weise zumuten.
Der nimmt dann nämlich den Update nicht mit, da damit der Aufwand den Kompatibilitätsbruch auszugleichen nicht auftritt und seine Zusatzsoftware eben weiterläuft.

Das selbe gilt ja ebenso für ein Datenmodell.
Sobald ich dieses ändere muss ich natürlich auch an Drittanbieter, Reportingtools, Schnittstellen usw. denken, und bei Umbenennungen von Spalten, Splitten von Tabellen usw. entspechende Views bereitstellen, die die alte Welt zumindest Übergangsweise bereitstellen und ggf. sogar mit Instead-Of-Triggern die Views in die neue Welt überführen.

Tue ich dies nicht, und 100te Berichte/Reports funktionieren plötzlich nicht mehr, tue ich meinen Kunden keinen Gefallen.
Oder es passiert dann dieses, wie wirklich real einem meiner Kunden vor vielen Jahren, dass das Softwarehaus ein Angebot über 40 Manntage abgegeben hat um zu analysieren, wie groß denn der Aufwand im Endeffekt wird, auf die neue Softwareversion umzustellen. Die Grobschätzung vor der Analyse belief sich schon mal auf mindestens 200 Manntage.
Der Kunde hat daraufhin den Wartungsvertrag gekündigt und fährt heute noch mit seiner Version.

Was die Kompatibilität angeht, so ist das den Kunden zum größten Teil extrem wichtig!
Ich habe mal für Excel97 ein VBA-AddIn entwickelt um Daten aus Excel per SQL in eine Datenbank zu schieben.
Dieses Excel-Addin funktioniert heute noch mit Office2016!
Fehlerbehebungen, die ja durchaus mal nötig sind, mache ich mit Excel2003.

Und dann tauchen da Nachrichten auf wie "Kein VBA mehr bei Office2016 für MAC".
Mal sehen, mit welcher Version das für Windows passieren wird, frei nach dem Motto:
Altes muss raus und Neues (auch wenn es noch so schlecht ist) muss auf jeden Fall rein.

Schließlich kann ja jeder inzwischen mit VisualStudio Express und Interop-Libraries AddOn's zu Office entwickeln.
Mit dem kleinen Nachteil, dass diese Interops halt Versionsspezifisch sind und ein Interop-AddIn für 2007 schon nicht mehr mit 2010 kompatibel ist.
Wieviele Office-Versionen muss ich mir denn da kaufen, die man ja noch nicht mal parallel installieren kann, um alle Kunden von 2003 - 2016ff zufrieden zu stellen?

Und seien wir doch mal ehrlich:
Welche Anwendung beschränkt sich tatsächlich auf Vanilla SQL?

Und was die Skalierung angeht so muss man natürlich 2 Punkte beachten:
a) sind die Datenoperationen zu langsam?
b) ist die Rechenlogik zu langsam?
Eine Datenbank kann über mehrere physischen Platten verteilt werden. Es gibt auch Möglichkeiten, mehrere Disk's zu einer logischen Einheit zusammenzufassen. Schließlich unterstützt ein SQL-Server bis Peta-Bytes!
Um die Datenbank selber effektiver zu machen verteilt man ggf. auf mehr Disks, legt vernünftige Indizes an und benutzt ggf. mehr Cores für Parallelverarbeitung.
Geschäftslogik in der Datenbank beschränkt sich i.W. auf das Verteilen oder Zusammensuchen von Informationen mit möglichst wenig Clientzugriffen (die kosten ja auch Zeit) und einfachen Arithmetiken.
Geschäftslogik als Rechenlogik gehört natürlich nicht in die Datenbank, was ich ja auch nie beauptet habe und dies kann ich sicherlich durch viele Maßnahmen (Multithreads, GPU-Aritmetik, Multi-Core, Mult-Computing, u.v.m) skalieren.

Answer 55

@Uwe Ricken

Ich denke dein Geschäftsmodell läuft so gut, weil du deutlich mehr drauf hast als nur Vanilla SQL. ;)

SCNR...

@bfuerchau

Also nach ihren eigenen Angeben verwendet Stackoverflow, bis auf eine StoredProcedure Vanilla SQL.

Wir verwenden aktuell bis auf 2 Trigger und einen Service Broker, sonst Vanilla SQL.

Vor einigen Jahren hab ich für eine Firma gearbeitet, die Individualsoftware Programmiert hat. An den Projekten an dehnen ich Beteiligt war wurde soweit ich weiß auch nur Vanilla SQL verwendet. (Mag auch daran liegen, das es bei bei beiden Firmen keinen Reinen DB Entwickler gibt/gab).

Dar vor hab ich mal bei einer Firma gearbeitet, die wirklich fast ihre komplette Logic in der DB hatten. Die haben aber auch Cache benutzt ein Objekt-Relationalen DB. (Da konnte man teile wie in C++ Programmieren).

2 von 3 Firmen für die ich bis jetzt gearbeitet hab, also eher Vanilla SQL eingesetzt. Das bei reinen DB Entwicklern, da die Quote anders aussieht. Kann ich gut verstehen.

Schnittstellen nach außen kann ich natürlich auch nicht einfach Ändern. Wir verwenden das bei unserer WebApi Versionen und unterstütze die Letzte/Vorletzte Version noch für einen Übergangszeitraum.

Darum ging es ja auch nicht direkt. Sondern ob ich mal eben intern einfach ein Property bzw. Tabellen Spalte den Namen ändern kann (Wenn du deine 3-Schichten DB Struktur konsequent durchziehst, sollte es das gleiche sein). Und hier werden halt bei den Triggern usw. die Anpassungen nicht Automatisch gemacht.

Und was den AddIn für Excel97, erst mal Respekt das es solange Funktioniert hat. Und wo du sicher auch Recht hast ist das Bestandskunden Änderungen nicht mögen (OK neue Funktionen möchten sie trotzdem gerne nutzen). Neukunden bekomme ich aber meist nur wenn die Software „Up to Date“ ist. Einfach mal Nokia anschauen, was passiert wenn man eine Technische Entwicklung verschläft.

Und was die Skalierung angeht.

Ich hoffe wir können uns einfach darauf einigen. Das es einfacher und Günstiger ist neue Clients hinzuzufügen als neue DB Server.

Answer 56

Nun könnte ich ja da glatt behaupten, dass die Vanilla-Entwickler einfach Angst davor haben, eine Datenbank auszureizen?
Oder steht da grundsätzlich die Anforderung im Raum, jederzeit die Datenbank so wechslen zu können dass es niemand merkt?
Dann sollte man sich eben auf Vanilla beschränken.

Aber sobald man eine Datenbank mit ihren Leistungen konsequent ausnutzen will, kommt man um alle Möglichkeiten die eine SQL-DB bietet nicht herum.
Sicherlich erschwert dies dann irgendwann den Umstieg auf eine andere Datenbank. Aber auch sowas lässt sich durchaus lösen.
Und was ein ERP-System angeht, so gibt es sicherlich ständig Erweiterungen (hinzufügen von Spalten, neue Tabellen) und Verbesserungen auch am Datenmodell, aber eher selten ein Umbenennen von Spalteninformationen oder sogar Änderung des Types einer Spalte. Wie gesagt, wenn man ein externes Berichtssystem auf seine Daten zulässt, dann kann ich den Kunden verstehen, dass der sich weigert wenn ein Großteil seiner Berichte nicht mehr funktionieren wird.

Und noch mal zur Skalierung:
Klar kann ich einem Benutzer der Anwendung einen 2. PC (Client) dazu stellen. Aber wie erkläre ich dem dass er die Auftragserfassung auf Client A und die Lagerwirtschaft auf Client B aufrufen soll?
Ich kenne zumindesten keinen Anwender, der tatsächlich in der Lage ist, auf mehr als 1 Client parallel zu arbeiten;-).

Und ich rede ja auch nicht davon, einen weiteren DB-Server hinzuzufügen, was sicherlich Synchronisationsprobleme wie bereits gesagt mitbringt, sondern die Leistung des einen DB-Servers durch zusätzliche Cores und/oder Hauptspeicher und/oder Festplatten zu steigern um möglichst viele Transaktionen parallel durchzuführen. Dazu gehört ebenso, die Anzahl der Clientaufrufe von und zum SQL-Server zu reduzieren bzw. gering zu halten um damit dann schneller zu werden, sowohl bzgl. des Clients (Wartezeiten) als auch auf dem Server. Lieber einen Insert/Update vom Client, den Rest per Trigger als 2, 3, 4. oder mehr SQL's vom Client initiieren. Wenn ich das in einer Transaktion mache, verlängert sich die Sperrdauer der geänderten Daten, als die paar Millisekunden oder sogar noch weniger native auf dem Server. Alleine die Laufzeit von einem Remoteclient zum Server beträgt da schon durchaus 20 bis 100 Millisekunden je SQL.

Ich hatte gerade gestern eine Anfrage eines Softwareherstellers, der nun vor hat wegen des Lizenzgebarens von Microsoft und Oracle, seine Anwendung auf die Firebird (OpenSource, mit der ich im BI-Umfeld seit 12 Jahren effektiv arbeite) umzuschreiben.
Wenn ich damit einem Kunden (sog. KMU = kleine mittelständische Unternehmen bis 100 MA's) alleine schon mal 12.500€ oder mehr sparen kann wird der das nicht unbedingt ablehnen.
Da ist es ja kein Wunder, dass da draußen immer noch so viele auf 2008/2012 fahren, weil sie einfach das Geld für die 2016er Lizenzen nicht haben.

Wer weiß, vielleicht lizensiert Microsoft demnächst nicht nur Cores sondern auch MHz?
Heute 12.500 bei 3,0 MHz, demnächst dann 25.000 bei 4,0 oder mehr?
Ich könnte mir auch ein Modell nach Transaktionen vorstellen, damit ließe sich so richtig das Geld drucken.
Die Cloud's sind da schon der Ansatz dazu.

Answer 57

Wir "Vanilla-Entwickler" haben keine Angst davor die DB auszureizen. Wir sind halt nur so freundlich sie nicht Grundlos zu reizen. Wir finden es halt gut das wenn 1000 Clients auf eine DB zu greifen. Und dann die DB noch nicht mal ins schwitzen kommt. Weil 1000 Clients eine Berechnung machen und nicht ein Server 1000 Berechnungen. Teile und herrsche.

Und auch wenn es keine Anforderung ist. Jeder Zeit die DB auszutauschen zu können ist ein Vorteil. Eigentlich unterstützen wir nur MSSQL, wir hatten jetzt aber einen Kunden der wollte unbedingt MySQL. Wir haben ihm zwar davon Abgeraten und ihm gesagt das wir da bei Problemen mit der DB keinen Support anbieten. Er hat darauf bestanden. Bis auf ein paar kleine Änderungen war das kein Problem. Ist doch gut wenn man das einen Kunden anbieten kann. Und wenn Microsoft demnächst auf die MHz Lizenzierung geht, werden vielleicht mehrere Kunden davon Gebrauch machen. ;)    

Mit der Skalierung meine ich natürlich nicht, das ein Nutzer an zwei Rechnern arbeitet. Ein Nutzer ist gar nicht in der Lage manuell so viele Daten einzugeben das der Client zum Schwitzen kommt. Wenn aber auf dem Client, noch ein Prozess läuft der Massendaten Validiert, Transformiert und dann in die DB Importiert. Und noch ein Prozess der Automatisch Berichte erzeugt und da zu noch der Benutzer am ihm Arbeitet. Kann der Rechner an seine grenzen kommen. Ich kann dann aber recht einfach und günstig 3 Rechner verwenden. Einen für den Datenimport, einen zur Berichtserstellung und einen für den Benutzer.

Und bei der DB meine ich genau das beim Skalieren. Es kann der Punkt kommen an dem der Physikalische Server die Last nicht mehr Schaft, dann brauche ich einen weiteren. Und der ist nicht so leicht und günstig wie ein zusätzlicher Client hinzuzufügen. Und wenn du meinst, zusätzlich Server wird man nie brauchen schau dir den Link von Stackoverflow an. Die haben ja nicht zum Spaß 6 Server.

Und wenn ich Updates vom Client machen, mache ich ja nicht  3-4 Aufrufe. Wenn ich z.B. EF verwende mache ich meine 3-4 Änderungen Rufe SaveChanges auf und dann wird mir das in einem einzigen SQL Statment als Transaktion zusammen gefasst. Zusätzlich bekomme ich vom EF noch einen Client Seitigen Cache, womit wenn ich möchte die Server abfragen Reduzieren kann.

 

 

Answer 58

Was ist "EF"?
Wenn du da das Entity Framework meinst, dann bist du wohl überrascht, wie viele SQL's die dann mal so auf den Server abschießen. Wenn du mehrere Tabellen hast, was ja nun mal normal ist, benötigts du je Tabelle Updates/Inserts/Deletes, die natürlich vom EF automatisch erzeugt/generiert und ausgeführt werden.
Kein Wunder, wenn dann eine Transaktion mal ein paar Sekunden oder auch gerne etwas länger dauert bis das so alles durch die Leitung gejagt wird. Der Server krault sich derweil an den Füßen.
Aber das ist eben so üblich bei OOP und dem Einsatz von Frameworks.
Wenn ich eine simple DataTable beackere (Zeilen hinzufüge, entferne und bearbeite) und diese dann per UpdateChanges und DataTableAdapter abschließe mache ich zwar 1 Aktion, das Framework aber durchaus 100e.
Bei Verwendung von DataSets mit mehreren Tabellen wird das Ganze noch verschärft.
Was da dann noch performant sein soll...;-).

Ich hatte schon mal eine Beschwerde eines IT-Leiters, wieso ich denn einen Server zu über 80% auslasten könnte. Meine Frage, wozu der denn sonst eigentlich da wäre als 100%tige Leistung zu bringen, blieb er mir die Antwort schuldig.
Wenn eine Hardware im Durchschnitt nur zu 5-10% ausgelastet ist, dann ist sie schlicht überdimensioniert oder ich habe eben noch 90-95% Reserven. Warum soll ich die nicht nutzen dürfen?
Ach ja, ich bin ja in einer VM und nicht alleine.
Auch da gilt für mich die Regel: verteile nicht mehr Ressourcen als du hast.
M.a.W., wenn ich nur 64 CPU's habe kann ich nicht 20 VM's á 4 virtuellen CPU's laufen lassen. Das beißt sich dann halt mal.

Answer 59

Nein ich weiß relative genau wie viele SQL Statements EF (ja Entety Framework), bei welcher Webseiten Aufruf bei uns absetzt.

Wir verwenden dafür ein Profiling Tool und wir sehen auch recht genau wie lange die Aufrufe dauern. Wenn es mehrfach aufrufe von EF gab, waren wir meist schuld daran. Und unsere Aufrufzeiten bis die Seite Angezeigt wird, also Request an den Webserver, der die SQL Abfrage gegen die Datenbank macht, deren Antwort und dann das Senden an den Client, dauern bis auf ein paar ausnahmen unter 500ms. In der Regel liegen wir so bei 100-200ms was auch mit MVC4 und der Razore Engine so unser Ziel ist. Bestwert liegt so bei ca. 40-50ms.

Wir haben ein paar Abfragen, die bei uns mehrere Sekunden dauern. Das sind aber Abfragen gegen eine Tabelle wo „Live“ Produktionsdaten vom Kunden mitgeschrieben werden. Nur die haubt Tabelle ist ca. 1GB groß und hat mehr als 1 Milliarde eintrage (haben wir vom Kunden bekommen) und mit der machen wir noch joins bis auf zu 5 weiteren Tabellen. Und das bei uns wo die DB auf einer VM mit einen Prozessor und 8GB RAM läuft. Ist absichtlich so gewählt, beim Kunden sollte es schneller sein.

Wenn deine Abfrage mit EF also mehrere Sekunden dauert. Liegt es vielleicht daran das du es nicht effektive einsetzt. Es gibt da schon ein paar Stolpersteine.

Und wenn die Hardware (im Produktive System) überdimensioniert ist, ist es gut. Das ist doch kein Grund sie bis zum letzten Auszureizen. Ich programmiere ja im allgemeinen nicht danach was für Hardware mir Verfügung steht, sondern danach was die Anforderungen des Kunden sind. Und das Probiere ich mit Standard Mitteln so effektive wie möglich umzusetzen. Wenn ich dann nur 5-10% Prozessor Auslastung ist das gut.

Ich bin ja kein guter Entwickler wenn ich meine Software dazu bringe, das sie auf eine überdimensionierten System möglichst viele Ressourcen nutzt. Sondern wenn ich es hinbekomme sie auf einen unterdimensionierten System noch einigermaßen zum Laufen zu bringen.

Ich muss ja gestehen ich halten deinen Grunde legenden Ansatz den du hier vertrittst für Falsch.

Der ja ist, nutze Möglichst alle DB spezifischen Funktionen und laste den Server soweit wie möglich aus. Alles andere wäre ja Verschwendung, von den Möglichkeiten die man hat.

Ich halte es für richtiger zu Sagen.

Benutze nur die DB spezifischen Funktionen, die du wirklich brauchst und belaste den Server so wenig wie möglich. Sorgt für ein schlankes System.

Answer 60

Nun, da müssen wir noch mal die unterschiedlichen Begriffe wegen der einheitlichen Bedeutung klären.

Du sprichst hier von einer Web-Anwendung, die sich naturgemäß auf 2 Komponenten stützt:
1. ein Web-Server
2. viele Web-Clients bzw. Frontends

Dein Web-Server ist natürlich aus Sicht der Datenbank der Client, die Web-Clients beschränkens sich da i.W. auf Browser-Frontends die ja gar keinen direkten Zugriff auf die Datenbank haben.
Auch was die Rechenleistung angeht, so liegt die eben nicht im Client sondern im Web-Server, der für dich der Client im Sinne der Datenbank ist.
Nun müssen sich also die vielen 100te oder 1000de Clients den Web-Server in seiner Rechenleistung teilen.
Das der dann unter Umständen dann nicht mehr klarkommt und dann eben skaliert werden muss steht außer Frage.
Nur habe ich dann halt mehrere Web-Server die dann immer noch mit nur einem Datenbank-Server auskommen.
Hier verlagert man also die Rechenleistung wieder auf einen Server und die z.T. nicht unerhebliche Rechenleistung der Web-Clients liegt brach.
Auch was die Laufzeiten der SQL's angeht, so sind diese im lokalen Netz zwischen Web- und DB-Server ja durchaus geringer als über ein WAN.

Denn was hat ein Web-Client denn noch zu leisten?
Ein bisschen JavaScript und HTML-Renderer.
Das schafft inzwischen fast jeder moderne Fernseher.
Zugegeben, ist das natürlich keine schlechte Lösung, da ich damit eine Vielzahl von Endgeräten unterstütze die so gut wie keine Intelligenz oder Rechenleistung vor Ort mehr haben müssen.

Es gibt aber halt auch immer noch Anwendungen, die auf einem Client mit direktem Datenbankzugriff arbeiten.
Auch unter dem Begriff FAT-Clients oder moderner auch Rich-Client (z.B. das inzwischen tote Silverlight, oder bald tote Flash-Anwendungen) bekannt.
Hier benötige ich dann die Rechenleistung auf den Frontend-Clients, die anschließend nur noch mit der Datenbank kommunizieren, wobei ich da eben die Netzlaufzeiten und Anzahl der SQL's berücksichtigen muss.

Diese Clients sind natürlich nicht skalierbar, da die User davor nicht skalierbar sind.

Und was die DB-Anwendung von Stackoverflow angeht so erklärt sich das eben aus der Masse an Daten, die ein einzelner Server derzeit kaum bewältigen kann.

Ich entwickle z.Zt. eine BI-Anwendung, die es im Moment nur als Fat-Client gibt.
Diese teilt sich auf in die DB-Leistung (Abfragen, Aggregierungen, geringe Berechnungen) und die Client-Leistung mit z.T. erheblichen Berechnungen für die Darstellung und Analyse der Daten.
Hier wird vom Client die volle Bandbreite ausgenutzt um schnell zum Ergebnis zu kommen.
Nun gibt es auch Einsätze auf Terminal-Servern, wo eben die Leistung wieder auf dem Server abverlangt wird und die Clients einfach nur per RDP verbunden sind.
Das hier der TS z.T überfordert ist erklärt sich da auch und die Kunden müssen ggf. mehr als einen TS (TS-Farm) vorhalten.
Da aber die meisten ihre Laptops/Notebooks/Desktops draußen haben kann man unsere BI-Anwendung ebenso gut direkt auf den Endgeräten installieren und somit den TS entlasten.
Auch eine Form der Skalierung;-).

Demnächst werden auch wir eine Web-Server-Lösung anbieten und stehen dann vom Grundsatz her vor dem selben Problem wie ein Terminal-Server. Allerdings kann unsere Lösung dann beides, so dass sich die Web-Lösung im Wesentlichen auf Mobilgeräte beschränkt und für alle anderen die Clientleistung verwendet werden kann.

Answer 61

Nun müssen sich also die vielen 100te oder 1000de Clients den Web-Server in seiner Rechenleistung teilen.
Das der dann unter Umständen dann nicht mehr klarkommt und dann eben skaliert werden muss steht außer Frage.
Nur habe ich dann halt mehrere Web-Server die dann immer noch mit nur einem Datenbank-Server auskommen.
Hier verlagert man also die Rechenleistung wieder auf einen Server und die z.T. nicht unerhebliche Rechenleistung der Web-Clients liegt brach.

Rede ich doch die Ganze Zeit von, Clients der DB als z.B. WebServer/Webapi usw. und genau diese Clients skaliere ich. Weil sie einfacher und kostengünstiger zu skalieren sind als die DB.

Und deine letzte Aussage ist schlicht falsch. Nur weil ich die Clients skaliere wird ja jetzt nicht auf irgend eine magische Art ihre Rechenleistung auf dem Server übertragen und sie haben nichts mehr zu tun. 

Answer 62

Auch unter dem Begriff FAT-Clients oder moderner auch Rich-Client (z.B. das inzwischen tote Silverlight, oder bald tote Flash-Anwendungen) bekannt.
Hier benötige ich dann die Rechenleistung auf den Frontend-Clients, die anschließend nur noch mit der Datenbank kommunizieren, wobei ich da eben die Netzlaufzeiten und Anzahl der SQL's berücksichtigen muss.

Weder Silverlight noch Flash-Anwendungen sollten direkt mit der DB kommunizieren. Da gehört ein WebServer dazwischen. 

Answer 63

Ja zugegeben, aber diese Richclients haben dann durchaus die Möglichkeit, die Rechenleistung des Clients zu nutzen, so dass der Web-Dienst sich nur noch um den reinen Datenaustausch kümmern muss, so dass der Web-Server in diesem Fall erheblich mehr Transaktionen durchschleusen kann.
Das dies mitunter nicht passiert liegt halt am Design der Lösung.

Ich stehe halt dazu, Leistung dort zu nutzen wo sie am meisten Sinn macht.

Answer 64

Also der WebServer muss auf jeden Fall noch die Autorisierung und Validierung usw., der an ihn gerichteten Requests machen. Alles andere wäre Fahrlässig.

Bei dem Web Servern ist halt ein wenig das Problem, das man nicht genau weiß welche Rechenleistung die Clients haben und was von ihnen Unterstützt wird. Der Kunde möchte ja mittlerweile Teilweise seine Auswertung auf dem Desktop PC, dem Tablett und dem Handy zur Verfügung haben.

Grundlegend muss man im Endeffekt überprüfen wo für seine Anwendungsfälle der Beste Ort ist um Business Logik (BL) unterzubringen.

Ich bin auch gar nicht böse wenn sich zum Schluss dafür entschieden wird BL in der Datenbank unterzubringen (Dein erster Ansatz war ja sie muss dar rein). Mein Ansatz war es zu zeigen, das es auch anders geht. Und es auch gute Gründe gibt, nur Vanilla SQL zu verwenden.

Answer 65

Bei den Problemen, die SQL-Server mit den Triggern hat (kein Before, kein Aufruf je Zeile) kann ich schon verstehen, dass man die da weniger einsetzt.
Und von muss war nie die Rede, schließlich habe ich auch Anwendungen mit ISAM-Systemen entwickelt, da wusste man noch gar nicht was "relational" heißt und Trigger kannte man nur in der Elektrotechnik;-).
Aber ich bleibe halt dabei, dass man sich beim Businessmodell das Leben nur unnötig schwer macht, wenn man auf Trigger verzichtet. Trigger sollen ja keine komplizierten Rechenmodelle anwenden sondern einfacher das Verteilen von Daten in mehrere Tabellen übernehmen. Wobei natürlich das stackoverflow-Model bei dem was da an Daten anfällt wohl wirklich keine Trigger braucht. Hier werden ja im Wesentlichen nur Texte (Blogs, Foren, usw.) gespeichert, die dann vernünftig indiziert werden müssen.
Wobei sich hier inzwischen Datenbanken etabliert haben, die im Massengeschäft (BigData) für so etwas besser geeignet sind (Stichwort Map/Reduce, verteilite Server, NoSQL, Dokumentorientiert, ...) als der SQL-Server.

Es gibt viel Wege nach Rom. Die einen kurz, die anderen lang, die nächsten beschwerlich oder leicht. Es kommt auf die Fähigkeiten, das KnowHow und die Fitness an, welchen Weg man da letztlich einschlägt.

Answer 66

Hallo und guten Morgen,

"Bei den Problemen, die SQL-Server mit den Triggern hat (kein Before, kein Aufruf je Zeile) kann ich schon verstehen, dass man die da weniger einsetzt."

Das ist schlicht und einfach nicht war, was Du da schreibst:

• Es gibt BEFORE-Trigger
• Du kannst - wenn Du nicht auf Performance stehst - selbstverständlich auch row based arbeiten (ist dann halt nicht so performant.

Das Trigger zu wenig eingesetzt werden - meine persönliche Meinung - liegt eher daran, dass der typische "Datenbankentwickler" aus dem OOP-Umfeld kommt und "meint", es in einer Datenbank genau so zu machen (siehe dazu ja auch Dein Einwand des Fehlens von "by row").

Trigger kann man effizient einsetzen, wenn man versteht, wie sie funktionieren und in welchem Kontext (relational) sie eingesetzt werden müssen.

In diesem Sinne klinke ich mich dann auch hier aus. Ich denke, dass alle Argumente / Gegenargumente ausführlich diskutiert werden. Vom ständigen Wiederholen werden sie auch nicht besser. :)

Herzliche Grüße aus Göteborg...

---

Uwe Ricken (Blog | Twitter)
Microsoft Certiied Master - SQL Server 2008
Microsoft Certified Solution Master - CHARTER Data Platform
Microsoft Certified Solution Expert - Data Platform
db Berater GmbH
Microsoft SQL Server Blog (german only)

Answer 67

Es gibt viel Wege nach Rom. Die einen kurz, die anderen lang, die nächsten beschwerlich oder leicht. Es kommt auf die Fähigkeiten, das KnowHow und die Fitness an, welchen Weg man da letztlich einschlägt.

Genau wenn man das nötige KnowHow hat wie z.B. Stakoverflow. Sagt man nicht ich muss Trigger nutzen, weil sie ja da da sind. 

Oder:

Ich hatte schon mal eine Beschwerde eines IT-Leiters, wieso ich denn einen Server zu über 80% auslasten könnte. Meine Frage, wozu der denn sonst eigentlich da wäre als 100%tige Leistung zu bringen, blieb er mir die Antwort schuldig.

Ich setzte die Leichtere und Effektivere lösung ums.

Answer 68

Und da ist unsere Betrachtungsweise einfach eine andere.
Ich (und mit mir auch andere Datenbank/Entwickler-Fuzzies) halten eben Trigger für die effektivere und leichtere Lösung (eben Datenbanklogik und nicht Rechenlogik).

Zugegeben, ich benötige da mitunter 2 Entwickler, 1x den Datenbankentwickler, der sich eben mit der Datenbank und der Prozedursprache sehr gut auskennt und eben den Middletier- und Frontendentwickler (das sind häufig ja auch schon 2 verschiedene), die sich eben um diesen Part kümmern.
Größere Softwarehäuser haben da durchaus mehrere in der Mannschaft, Einzelkämpfer (wie ich) müssen da halt manchmal etwas mehr können;-).
Wobei ich mich aus den Mobil-Frontends da eher raushalte, da gehören mitunter schon Designfähigkeiten dazu, die mir als Pragmatiker eher fehlen.

Und wenn man noch mal zum Ursprung des Threads zurückkommt:
Trigger sind ebenso wie SQL-Prozeduren und SQL-Funktionen eben mögliche Bestandteile von Business-Logik und keinesfalls Pflaster oder sogar schlechter Programmierstil. Sie erleichtern das Datenbankhandling und können u.U. sogar Entwicklungszeiten verkürzen.

Nachtrag:
Seit der Einführung von CLR im SQL-Server kann ich ja Trigger und Prozeduren auch in C#/VB.NET/C++ entwicklen lassen, die mitunter das Problem der Rechenlastigkeit in T-SQL entschärfen.
Zusätzlich habe ich dann auch die Möglichkeit mittels Message-/Queue-Diensten auch andere Aktionen asynchron auszulösen u.v.m.
Sowas sollte man einfach nicht aus den Augen lassen.