DB-Queries mit vielen optionalen Parametern
Hallo,
ich habe hier eine SQL Server 2008-Datenbank, in der sich einige Tabellen mit relativ vielen Spalten befinden. Aus diesem Tabellen möchte ich Datensätze selektieren, wobei bestimmte Kriterien immer angegeben werden müssen (z.B. Start- und Ende-Zeitstempel). Der Rest der Spalten (alles unterschiedliche Datentypen, von nvarchar bis bit...) soll optional mit Kriterien versehen werden können.
Habe ich z.B. eine Spalte Message, dann kann der Anwender dafür ein Selektionskriterium eingeben, muss aber nicht.
Ich verwende in meiner Anwendung typisierte DataSets und für die Abfragen StoredProcedures. Wie kriege ich es denn am besten hin, mit solchen optionalen Parametern zu arbeiten? Dadurch dass die Parameter optional sind, kriege ich ja eine riesen Anzahl an möglichen Parameterkombinationen zusammen.. Für jede Kombination eine Procedure zu erstellen kann ja nicht die Lösung sein, oder? Wie löst man so was denn elegant?
VG
Indem man nicht nur TableAdapter benutzt, sondern versteht was dahinter steckt.
Versuche den TabelAdapter eher als Codemonster zu sehen das du zu einem DAL erweitern kannst.
Deswegen sind alle Klassen als Partial ausgelegt, können also in einer extra Datei erweitert werden.
Warum nicht eine Funktion machen die ein Dictionary<string,object> erhält und daraus dann den entsprechenden Sql Text erzeugt.
Wenn du die protected machst, kann sie im eigenen Partialen Code ja mit den verschiedenen DefaultParametern versehen werden.
Und warum SP's?
Die haben ihre Berechtigung, werden aber sehr häufig unnötig oder falsch eingesetzt.
Hallo,
keine Angst, meine TableAdapter werden schon richtig eingesetzt ... (sind durchaus sofern sinnvoll erweitert) 😉
Warum nicht den SqlText dynamisch erzeugen? Weil FxCop was anderes sagt 😉 Scherz beiseite... Sql dynmaisch zu erzeugen ist selbstverständlich eine Lösung - für mich hat sich aber die Frage gestellt, ob man so was nicht irgendwie anders machen könnte...
Das mit den SP's steht leider erst mal nicht zur Debatte. Die sind an anderer Stelle u.a. aus Performancegründen vorgegeben. Sofern möglich sollte dann auch eine Mischung aus SP's und "normalen" Abfragen vermieden werden...
Du sollst den String nicht zusammenfrickeln, sondern schon die ParameterCollection benutzen.
Du kannst noch per T4 scripte schreiben lassen, aber sonst ist es nur dynamisch möglich.
Und wie gesagt, SP's haben manchmal ihren Sinn ( Security z.b. ) aber Geschwindigkeit ist selten ein Grund.
Und wie hier schön zu sehen entsteht gleich eine "schöne" Barriere mit verschiedenen Stellen an denen Business Logik steht.
Werte an Queries übergebe ich sowieso grundsätzlich nur über Parameter...
Mit T4 habe ich mich bisher noch nicht beschäftigt. Sieht aber interessant aus... Vielen Dank für den Tipp!
Hi,
einzige möglichkeit was wir gefunden haben:
Du sollst ein Gesp. Proc machen mit Parametr's:
@tablename varchar(256),
@columndef nvarchar(max),
@tablejoin nvarchar(max),
@tablewhere nvarchar(max),
@groupby nvarchar(max) = '',
@orderby nvarchar(max) = ''
evntl. weiteren steurungsparameter
dann aus Parameter's soll einen sql-string erstellt werden und über
exec sp_executesql
ausgeführt werden.