Status berechnen oder als Wert speichern?

[Humml87]

Hallo Zusammen,

ich bin mir sicher, dass es für diese Frage im Netz bestimmt schon Antworten und Beiträge gibt, aber leider fehlen mir die richtigen Suchbegriffe.

Ich bin mir nicht sicher was bei einem SQL Server mit der Geschwindigkeit passiert, Wenn man komplexe Abfragen laufen lässt um einen Status für bestimmte Einträge zu ermitteln.
Im Anhang habe ich ein Bild angehängt um meine Frage darzustellen, ich hoffe Ihr versteht was ich damit meine:
Statusprinzip.jpg
Soll ich der Tabelle Zeitanforderung eine zusätzliche Spalte "Status" anfügen und immer wenn ein Eintrag in der Tabelle Zeitstempel hinzugefügt/geändert wird diesen Status vom Programm berechnen lassen und "hart" in die Spalte schreiben?
Oder soll ich über eine etwas komplexere Abfrage mir den Status berechnen lassen (währe vom Grundsatz her mein Favorit).

Ich habe Angst, dass wenn die Tabellen mit einer Menge im 7-Stellingen Bereich ankommt das Berechnen eine Abfrage langsam macht.
P.S. Meine Abfrage beziehen sich jetzt nicht nur auf diese 2 Tabellen, sonder ich arbeite mit C# und mache meine Abfragen mit Linq. Dort beziehe ich ungefähr 10 weitere solcher Szenarien ein und setzte eine große Abfrage ab.

Ich hoffe ihr könnt meine Frage erkennen :/ und mir einen Tipp geben.

Gruß Christian.

[Ralf Jansen]

Wenn du die Datenbasis im Griff hast also verhindern kannst das andere diese Daten an deiner Software vorbei ~administrieren~ kannst du das tun. Die Natur von Linq bedingt nunmal das man da nicht mit hochoptimierten SQL rechnen kann insofern ist es möglich da in Probleme zu kommen obwohl man ein wohloptimiertes Datenbankschema hat.

Wenn du in der Breite deiner Anwendung mit solchen Problemen rechnest würde ich mich eher Fragen ob die Wahl eines ORM (so viel produktiver das im Standardfall auch immer sein mag), das mich in der Optimierbarkeit der Abfragen zumindest begrenzt, die richtige Entscheidung ist. Wenn das ein rein lesender Zugriff ist solltest du dich fragen ob man das besser an LINQ vorbei mit klassischem handoptimierten SQL macht.

[hwoess]

Hallo,

ich würde für das einen Trigger schreiben, der bei Änderung der "minimalen Zeitanforderung" in der Tabelle "Zeitanforderung" bzw. bei Insert/Update/Delete eines Eintrages in Tabelle "Zeitstempel" den Status berechnet und fix speichert. Denn wenn du wirklich mal so viele Datensätze in einer Anfrage durcharbeiten musst, wird es sehr, sehr zäh.

bye,
Helmut

[Humml87]

Hallo dank euch Zweien für die Antworten!

Die Idee mit den Triggern finde ich super... so werde ich das erstmal versuchen umzusetzen.
Keine Ahnung warum ich da gerade nicht drauf gekommen bin. Manchmal sieht man den Wald vor lauter Bäumen nicht.

Nochmal vielen vielen Dank!

[Ralf Jansen]

Die Idee mit den Triggern finde ich super... so werde ich das erstmal versuchen umzusetzen.

Triggern? Sei Vorsichtig mit der Kombination aus intelligentem ORM und intelligenter Datenbank. Aus Performance <gesichtigpunkten kann das notwendig sein an bestimmten Stellen mal einen Trigger zu benutzen. Als Allheilmittel aber tödlich. Von den ganzen Änderungen durch die Trigger wird der ORM nichts mitbekommen und dir dann regelmäßig Concurrency Exceptions um die Ohren hauen. Das Hilfsmittel Trigger vorsichtig einsetzen.

[Humml87]

Hallo Ralf,

ich arbeite mit dem EF das auf einem Service platziert ist. Wenn der Client eine Service Methode aufruft wird jedes mal ein neuer DB Context erzeugt. Von dieser Seite betrachtet wäre glaub ich die Trigger variante schon möglich.
Ich habe meine Datenbankstruktur komplett "logisch" aufgebaut, mein Grundgedanke war eben, dass ich mir jeden Status über die vorhandenen Werte berechnen lasse.

Ich kann nur leider nicht einschätzen wie der SQL Server mit einer recht komplexen Abfrage (gebündelt in einer SELECT-Anweisung) Performance technisch umgeht. Vielleicht mache ich mir auch völlig unnötig Gedanken über dieses Problem und ein SQL Server spielt sich ganz locker mit solchen Anweisungen. Ich habe jetzt auch nochmal meine Situation nachgerechnet und ich werde vermutlich über 5 Jahre ca. 2.000.000 Einträge pro Tabelle schreiben und es sind ca 20 Tabellen die alle über Beziehungen miteinander in Verbindung stehen wovon für ein SELECT Ergebnis ungefähr von 10 Tabellen Daten ermittelt und Ausgewertet werden.

Wie ist das eigentlich, wird ein SQL Server langsamer wenn ich im vergleich einmal 10.000.000 Datensätze und einmal 5000 Datensätze in der Datenbank habe und ich mach eine Abfrage die z.B. in der Spalte_A nach 'Hallo' sucht und dann von allen gefunden Datensätze die Spalte_B summiert. Macht es Sinn, Datensätze in einen Art Archivserver zu schieben wenn diese vermutlich nicht mehr gebracht werden? Facebook und Google müssen ja mit ganz anderen Dimensionen von Datensätzen umgehen und die werden ja auch nicht für jeden Status eine eigene Spalte anlegen oder?

Denn was ich bisher immer so gelesen habe (jedoch nur im 'kleinen' Stiel z.B. für Access) soll man ja reine Datentabellen machen und dann Views erstellen um Auswertungen zu erhalten. Views kann ich ja von mir aus auch auf dem SQL Server machen aber im Hintergrund passiert doch dann das gleiche als wenn ich einfach eine etwas komplexere Abfrage lostrete, oder irre ich mich da?

Gruß Christian

[Ralf Jansen]

Ich arbeite mit dem EF das auf einem Service platziert ist. Wenn der Client eine Service Methode aufruft wird jedes mal ein neuer DB Context erzeugt. Von dieser Seite betrachtet wäre glaub ich die Trigger variante schon möglich.

Ich lese das gerade so als würdest du EF verwenden ohne irgendein Feature von EF zu verwenden. EF ist 'ne tolle Sache aber nicht unbedingt hilfreich wenn man einfach nur singuläres möglichst optimales SQLs absondern will. Unter den genannten Umständen ist dann aber der Trigger natürlich problemlos einsetzbar. Zumindest wird es nicht zu Problemen aufgrund irgendwelcher Wechselwirkungen zwischen der Logik in EF und der Datenbank kommen.


Ansonsten sollten die von dir genannten Datenmengen eigentlich (Designfehler mal ausgenommen) dem SQL Server nur ein müdes lächeln abnötigen. Natürlich wird die Datenbank mit mehr Daten langsamer aber nicht linear und schon gar nicht in relevanter-weise in den von dir genannten Regionen (außer natürlich wieder bei einem eklatanten Designfehler). Ob View oder direkte Abfrage sollten keinen Unterschied ausmachen außer du hast eine Struktur wo ein tabellenübergreifender Index Vorteile bringt oder wo es hilft ein berechnetes Feld mit in einen Index aufzunehmen. Klingt hier aber eigentlich nicht so.

[Humml87]

Hi,

Ich lese das gerade so als würdest du EF verwenden ohne irgendein Feature von EF zu verwenden.

Mir geht es bei der Verwendung von EF Hauptsächlich um die POCO Geschichte was ich sehr komfortabel finde. Und zum anderem nutze ich LINQ was ebenfalls mit dem EF einfach hervorragend funktioniert um mir (relativ simpel) dynamische Anweisungen zur Laufzeit ermöglicht.
Das einzige was ich nicht nutze ist ein single Instanz des DB-Contextes. Vielleicht bin ich da auch falsch gewickelt aber vom Bauch raus ist das schon ganz OK so. Oder?

Ansonsten sollten die von dir genannten Datenmengen eigentlich (Designfehler mal ausgenommen) dem SQL Server nur ein müdes lächeln abnötigen.

Diese Aussage tut schon mal recht gut.

Vielen Dank für Deine Mühe. Ich denke das hat mir schon ein Stückchen weitergeholfen.

Gruß Christian