Datenbankviews für Abfragen in Berichten
verwendetes Datenbanksystem: SQL-Server 2008 - 2012
Hallo zusammen,
wir haben in unserer Software aus Altbeständen immer noch einige Views, die die Daten zur Anzeige in verschiedenen Formularen sammeln. Diese werden dann über ADO.NET abgefragt und an ein GridView gebunden.
Bei Neuentwicklungen machen wir die Abfragen über meist 3 - 4 beteiligte Tabellen in der Regel direkt im Code.
Jetzt mal die Frage zum Softwaredesign. Wer von euch macht erst die Views in der Datenbank, um die Abfragen im Code zu vereinfachen und wer macht die Abfragen direkt? Und sind euch noch Vorteile für das eine oder andere bekannt?
Funktionieren tut's beides, ich wollte nur mal Meinungen hören was besser ist...
VG
Wir arbeiten mit gespeicherten Prozeduren, welche intern möglicherweise noch Views verwenden.
Das bringt aus meiner Sicht erhebliche Vorteile, vorallem weil sich die Anwendung nicht um die Datenherkunft kümmern muss.
Nehmen wir mal an du hättest einen dynamischen Bericht, der abhängig von den Spalten mehr Daten anzeigen kann wenn das Select geändert wird. Dann müsstest du bei direktem Select im Code immer eine neue Anwendung kompilieren. Bei Verwendung einer gespeicherten Prozedur reicht die Änderung der Prozedur und ein unnötiges Ausliefern der Anwendung an den Kunden entfällt.
Da ihr MSSQL benutzt würde ich auch dazu raten auf gespeicherte Prozeduren umzusteigen. Ich denke ihr werdet schnell merken, dass dies Vorteile bringt.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
ich verwende Views wenn ich das Ergebnis nochmal sortieren möchte, wenn es mit sort by nicht geht.
Ansonsten wird es im SQL erledigt.
SP kann ich nicht benutzen weil wir auch MySQL, Oracle und PostgreSQL unterstützen.
Grüße Bernd
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3
SP kann ich nicht benutzen weil wir auch MySQL, Oracle und PostgreSQL unterstützen.
In so einem Fall ist es natürlich sinnvoll die Select-Statements im Programm zu hinterlegen. Da d.gierse aber speziell geschrieben hat, dass MSSQL im Einsatz ist und kein weiteres DBMS angegeben hat ist es denk ich eine gute Option StoredProcedures zu verwenden.
Ich würde zumindest versuchen so wenig wie möglich SQL-Code im Programm selbst zu hinterlegen. Bei Standalone Datenbanken sieht das dann natürlich anders aus. Dort gehts ja nicht ohne.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Ich würde das auf keinen Fall so pauschalisieren.
Wenn man in grösseren Firmen arbeitet die eigene DBA's haben, muss man meist sowieso mit SP's und Views arbeiten.
Wenn man alleine ( oder kleines Team ) auf der DB arbeitet würde ich da eher von abraten.
Warum soll man jetzt einen Teil der Businesslogik in einer anderen Sprache und einem anderen Umfeld implementieren und das gesamte Testumfeld neu machen?