Dynamische Datenbankabfrage in asp.net c#

[azubi-tigerente]

Hallo zusammen,

möchte gerne eine dynamische datenbank abfrage machen. Blos wie geht das.

meinen Select-befehl usw habe ich und funktioniert auch.

Aber ich möchte nun aus Text-Felden, welches die Suchkriterien sind, einen Suchstring entwickeln.

selcect * from testtabelle where variabele

variable =" name = 'mueller' and plz > 0 and plz < 100"

Ist das ein Sicherheitsrisiko? Was wäre empfehlenswert???

[lbm1305]

Moin,

zuerst die Frage(n): Könntest Du ein O/R Mapper nutzen bzw. welches .NET Framework nutzt Du?

Falls nicht, würde ich Abfragen generell mit Parametern durchführen. Damit umgehst Du das sogenannte SQL-Injection.

Einen SQL-String kannst Du Dir auch zusammen schnippeln. Immer schön die Strings aneinander addieren :-)

Bearbeitet 23. Juli 2010 von lbm1305

[Mcolli]

So wie ich das verstanden habe lässt sich das durch 2 Möglichkeiten gut realisieren.

1. Stored Procedure in der Datenbank.

Letzten Endes hast Du ja "x" Felder in deiner Suchabfrage, die für das Filtern der Datensätze ("Where"-Clausel) in Frage kommen. Und somit hast Du auch "x" Textboxen oder Ähnliches in der Maske für den User.

Die Stored Procedure in der Datenbank legst Du mit "x" Parametern + einen "Out Parameter"(der die Daten am Ende beinhaltet" an.

Dann holst Du Dir in dem Part wo das Suchen gestartet wird die "Stored Procedure" aus der Datenbank und füllst die Parameter mit den Usereingaben bzw. leeren Strings / Zahlen.

In der Stored Procedure schreibst Du auf Datenbankebene dann die Abfrage so, dass nur die nicht leeren Parameter zum Filtern verwendet werden.

Der ganze Zirkus hat den Vorteil dass Veränderung in der Tabellenstruktur oder Suchlogik nicht zwangsläufig zum Neu-Ausrollen der Software führen.

2. Du abreitest in deiner Suchabfrage mit Parametern

Siehe dazu z.B.:

Formatting Strings

[lbm1305]

Stored Procedures würde ich nicht als Zirkus bezeichnen :roll:

Zum Thema SQL-Parameter:

SqlParameter-Klasse (System.Data.SqlClient)

gibt es auch für OleDb.

[Mcolli]

Stored Procedures würde ich nicht als Zirkus bezeichnen :roll:

Zum Thema SQL-Parameter:

SqlParameter-Klasse (System.Data.SqlClient)

gibt es auch für OleDb.

war auch mehr eine Verunglimpfung des Ganzes um jemandem, der das ganze noch nicht kennt, die sache ein bischen schmackhaft zu machen .... rein rethorisch.

Stored Procedures sind - meiner bescheidenen Meinung nach - das Mittel der Wahl wenn es um wiederkehrende Datenbankabfragen bzw. Datenmanipulationen in objektorientierten Sprachen geht.

Leider stößt das sehr oft auf Ablehnung weil es nunmal einfacher ist in der gewohnten Programmiersprache mittels Komfort-funktionen was Zeichenketten anbelangt das ganze zu realisieren.

Dafür kann man auch (wenn man die Enterprise Library benutzt) das ganze Mittels App.cofig und Stored Procedures so gestallten, dass man einfach von Access auf MySql auf Oracle und zum schluss beispielshalber auf MS-SQL Server, oder wie auch immer, migrieren kann.

[lbm1305]

Ok, dann verstehe ich, wie Du es gemeint hast ;-)

Die Entprise Library benötige ich nicht, um einen zwischen verschieden DBMS zu wechseln. Es reicht, wenn ich bspw. die Datenzugriffsschicht austausche. Dafür ist es aber unerlässlich, mit Interfaces zu entwickeln.

[azubi-tigerente]

Also Variante 1 sagt mir zu. Blos bei der Umsetzung gibt es noch Probleme.

Eine Prozedur muss ich auf Datenbankebene erstellen, kann ich also nicht dynamisch in meinem Programm erstellen. Sprich als C# Code.

1. Stored Procedure in der Datenbank.

Letzten Endes hast Du ja "x" Felder in deiner Suchabfrage, die für das Filtern der Datensätze ("Where"-Clausel) in Frage kommen. Und somit hast Du auch "x" Textboxen oder Ähnliches in der Maske für den User.

Die Stored Procedure in der Datenbank legst Du mit "x" Parametern + einen "Out Parameter"(der die Daten am Ende beinhaltet" an.

Dann holst Du Dir in dem Part wo das Suchen gestartet wird die "Stored Procedure" aus der Datenbank und füllst die Parameter mit den Usereingaben bzw. leeren Strings / Zahlen.

In der Stored Procedure schreibst Du auf Datenbankebene dann die Abfrage so, dass nur die nicht leeren Parameter zum Filtern verwendet werden.

Gibt es dafür eine Funktion, die mir die leeren Felder herausfiltert??

While in meiner Where-Klausel stehen ja alle Felder.

Es gibt ja auch die Möglichkeit z.B bei PLZ Feldern nach einer ganzen PLZ zu suchen, oder nach mehreren PLZ oder PLZ-Range.

Wie filtere ich sowas heraus bzw füge ich ein. Denn in einer Prozedur gebe ich ja genau die Suchfelder in meiner Where-Klausel ein, obwohl sich diese ändern können.

Der ganze Zirkus hat den Vorteil dass Veränderung in der Tabellenstruktur oder Suchlogik nicht zwangsläufig zum Neu-Ausrollen der Software führen.

Wäre eine saubere und sicherere Lösung.

2. Du abreitest in deiner Suchabfrage mit Parametern

Siehe dazu z.B.:

Formatting Strings

Ich habe mal gelesen Strings wären nicht so sicher.

[azubi-tigerente]

Prozeduren müssen auf der Datenbank erstellt werden. Habe etwas über Verweisbezogene Übergabe gelesen. Aber das ist nicht wirklich das richtige für dynamische Abfragen.

Sehe ich das richtig, dass ich sozusagen if-Else Abfragen in der prozedur erstellen muss, damit ich vorher die Felder herausselektiere, die keine Werte haben?

[lbm1305]

Gibt es dafür eine Funktion, die mir die leeren Felder herausfiltert??

While in meiner Where-Klausel stehen ja alle Felder.

Im Ergebnis? Die SQL-Afrage gibt alle Entitäten zurück, die zur WHERE-Klausel passen. Sollte irgendwo ein leeres Feld dabei sein, wird dies mit zurückgegeben.

Es gibt ja auch die Möglichkeit z.B bei PLZ Feldern nach einer ganzen PLZ zu suchen, oder nach mehreren PLZ oder PLZ-Range.

Eine Range wäre möglich, dafür müsste man die Procedure um einen weiteren Übergabeparameter erweitern und die Anfrage anpassen.

Wie filtere ich sowas heraus bzw füge ich ein. Denn in einer Prozedur gebe ich ja genau die Suchfelder in meiner Where-Klausel ein, obwohl sich diese ändern können.

Normalerweise legt man für jede benötigte Abfrage ein Procedure an und schnippelt nicht alles zusammen.

Ich habe mal gelesen Strings wären nicht so sicher.

Siehe Post weiter oben --> SqlParameter-Klasse

Mit einem O/R Mapper wärst Du etwas flexibler. Aber da fehlt mir Deine Antwort.

[azubi-tigerente]

Besipiel einer Prozedure nur für mein Verständnis:

Create Procedure spKunden

@PLZ

@nachname

@Vorname

As

Select * From tbl_Kunden

Where PLZ = @PLZ, nachname = @nachname;

So wird ja eine Prozedur erstellt Nun kann es aber sein das PLZ eine Range ist

sprich PLZ < 70 and PLZ > 60. Oder der @nachname wurde nicht angegeben...

Ich muss ja da meine where-Klausel irgendwie in der Prozedur dynamisch gestalten.

[lbm1305]

Sehe ich das richtig, dass ich sozusagen if-Else Abfragen in der prozedur erstellen muss, damit ich vorher die Felder herausselektiere, die keine Werte haben?

Hier ein wenig C#-Code, mit dem DbParameter an ein Command übergeben werden. Kann man auch mit Sttrings in ähnlicher Form machen:

public virtual void AddParameters(DbCommand command, IEnumerable<DbParameter> parameters)

        {

            if(parameters!=null)

            {

                foreach (DbParameter parameter in parameters)

                {

                    command.Parameters.Add(parameter);

                }

            }

        }

[lbm1305]

Besipiel einer Prozedure nur für mein Verständnis:

Create Procedure spKunden

@PLZ

@nachname

@Vorname

As

Select * From tbl_Kunden

Where PLZ = @PLZ, nachname = @nachname;

So wird ja eine Prozedur erstellt Nun kann es aber sein das PLZ eine Range ist

sprich PLZ < 70 and PLZ > 60. Oder der @nachname wurde nicht angegeben...

Ich muss ja da meine where-Klausel irgendwie in der Prozedur dynamisch gestalten.

Diese wird so mit Sql nicht möglich sein.

Für jedes Szenario EINE Procedure.

PseudoCode:

Procedure1(@plz)

...where plz = @plz1;

Procedure2(@plz1, @plz2)

...where plz between @plz1 and @plz2

[azubi-tigerente]

Im Ergebnis? Die SQL-Afrage gibt alle Entitäten zurück, die zur WHERE-Klausel passen. Sollte irgendwo ein leeres Feld dabei sein, wird dies mit zurückgegeben.

Würde aber das Ergebnis verfälschen, denn es würden ja alle leere Felder ausgewählt und gesucht.

Eine Range wäre möglich, dafür müsste man die Procedure um einen weiteren Übergabeparameter erweitern und die Anfrage anpassen.

Normalerweise legt man für jede benötigte Abfrage ein Procedure an und schnippelt nicht alles zusammen.

Aber für eine ´Suchabfrage mit 20 Feldern oder mehr, werden ja eine Menge Proceduren benötigt.

Da wird das ganze ja unübersichtlich.

Siehe Post weiter oben --> SqlParameter-Klasse

Muss ich mir nochmal in Ruhe anschauen, das habe ich nicht so verstanden

Mit einem O/R Mapper wärst Du etwas flexibler. Aber da fehlt mir Deine Antwort.

Was ist ein O7R Mapper???

[lbm1305]

Wer übergibt den 20 Suchparameter?

Weder in Deiner Variante noch in einer SQL-Variante kann man verhindern, dass Ergebnisse zurückgegeben werden, in dem sich leere Felder befinden.

Persons (Vorname, Name, GebDat)

Falls also der Vorname nicht vorhanden sein sollte, darf dieser Datensatz nicht zurück gegeben werden, obwohl das Geburtsdatum in die Suchabfrage passen würde?

Man kann sich Ergebnisse zurückgeben lassen und dann speziell im Programm nochmals Filtern.

[Rookian]

Was ist ein O7R Mapper???

Ein Objektrelationaler Mapper ist ein Framework, welches dir hilft Tabellen und Objekte zu verknüpfen. Dabei ist der Vorteil, dass du du für Standardabfragen keinen bis kaum SQL Code schreiben musst, da der OR-Mapper dir den SQL Code selber erzeugt. Ebenso musst du dich nicht direkt kümmern um Datenbankverbindungen.

OR-Mapper sind bspw. NHibernate, Entity Framework oder LINQ to SQL.

Empfehlenswert ist aus meiner Sicht NHibernate.

Für deinen einfachen Fall würde ich dir raten einer der beiden MS ORM Frameworks (EF, LINQ2SQL) zu nutzen, da man dort eine grafische GUI als Hilfe hat um sich die Objekte zu erstellen Ansonsten würde auch NHibernate mit der FluentNHibernate Bibliothek funktionieren, du müsstest dich dort aber erstmal einlesen.