Hallo !

Ich habe noch einmal eine Frage an euch, die sich speziell um das Thema SQL dreht. Ich habe das folgende SQL Beispiel:

Frage 1: Ist es hier möglich für das [Feld 1] einen komplexen Subselect mit From-, Where-, Groupby- und Having-Klausel zu bauen, wenn dieser nur einen Wert zurückliefert?

Frage 2: Innerhalb der Where-Klausel kann man ja mittels In-Operator die gesamte Ergebnismenge einschränken. Analog zu meiner ersten Frage wäre es hier interessant zu wissen, ob ich in dem gesamten In Operator ein Subselect einbauen kann, welches evtl. mehrere Ergebnisfelder in ihrer Selectklausel beinhaltet? Oder muss dieses Subselect ebenfalls zwingend ein Ergebnisfeld zurückgeben?

Viele Grüße
--Kossy--

Moderiert von Th69: SQL-Tags hinzugefügt

Frage 1: In vielen Datenbanken ja.

Frage 2: Ich denke das das in allen Datenbanken funktioniert. Aber nur mit einem Subselect das genau eine Spalte liefert(Die Anzahl Ergebniszeilen sind egal).

Hi Ralf !

Ralf Jansen hat folgendes geschrieben :

Aber nur mit einem Subselect das genau eine Spalte liefert(Die Anzahl Ergebniszeilen sind egal).

Aber müsste das in einem In Operator nicht evtl. eine Ergebnismenge aus meheren Spalten, die jeweile nur eine Ergebniszeile beinhalten?



Bei einer Having-Klausel müsste ein Subselect doch eine Spalte mit einer Ergebniszeile zurückliefern, richtig?

Danke für deine Antwort !

Viele Grüße
--Kossy--

Kossy hat folgendes geschrieben :

Hi Ralf ! Ralf Jansen hat folgendes geschrieben : Aber nur mit einem Subselect das genau eine Spalte liefert(Die Anzahl Ergebniszeilen sind egal). Aber müsste das in einem In Operator nicht evtl. eine Ergebnismenge aus meheren Spalten, die jeweile nur eine Ergebniszeile beinhalten?

Ich kenne keine Datenbank die das zulässt. Wenn ich denn den Sinn des Satzes richtig erraten habe. Die Implementierung eines solchen Features stell ich mir auch schwierig und fehleranfällig vor. Immerhin müsste dann auch jede Spalte den selben Typ zurück liefern um vergleichbar zu sein.

Zitat:

Bei einer Having-Klausel müsste ein Subselect doch eine Spalte mit einer Ergebniszeile zurückliefern, richtig?

Ein Having beinhaltet einen Vergleich wie in der Where-Klausel nur eben einen Vergleich der nach der Ausführung einer Aggregatfunktion stattfindet. Es gilt also methodisch das gleiche wie in der Where-Klausel. Bei einer IN-Operation gekoppelt mit einem Subselect könnte dieser also beliebig viele Ergebnissätze liefern.

Vielen Dank für deine Antwort Ralf !

Hi nochmal !

Es hat sich gerade für mich nochmal eine andere Frage ergeben, zu der ich gerne eure Meinung hören würde.

Kann ich eigentlich eine Truncate Anweisung innerhalb einer explizit von mir geöffneten Transaktion ausführen, oder macht so etwas keinen Sinn (evtl. weil bei Truncate nicht wie bei einem Delete oder Insert automatisch vom DBMS porotokolliert wird)?

Viele Grüße
--Kossy--

Truncate ist ein ganz normale transaktionale Funktion und kann gerollbacked werden. Insofern macht es Sinn die auch mit anderen Dingen zusammen in einer Transaktion zu haben.
Truncate wird auch protokolliert sonst könnte man die Transaktion nicht rollbacken. Aber es wird nur der Gesamtevorgang geloggt. Du wirst im Transaktionlog also keine einzelnen Rows finden.

Hallo Ralf !

Vielen Dank nochmal für deinen Beitrag, das hilft mir sehr weiter.



Ich hätte aber nochmal eine Frage zu dem Thema Datenbanken, genauer gesagt geht es um das Thema Optmistisches- und pessimisstisches Sperrverfahren.

Ich habe mir zu beiden mal den dazugehörigen Wikipediaartikel durchgelesen. Hier:

de.wikipedia.org

Beide für sich alleine können doch in der harten Praxis kaum funktionieren. Optimischtisches S.V. kann dafür sorgen, dass man veraltete Daten liest und das pessimisstische S.V. ist zu hart, weil es wirklich alles abblockiert und isoliert, was gerade von nem anderen User geöffnet ist.

Nun stellt sich für mich die Frage, wie man in heutigen DBMS´s einen Kompromiss eingeht. Muss ich so etwas explizit selbst programmieren? Gibt es dafür bereits gängige und etablierte Lösungen, die diesen Kompromiss eingehen?

Viele Grüße
--Kossy--

Hallo Ralf !

Magst Du meine zuletzt gestellte Frage noch beantworten?

Viele Grüße
--Kossy--

Optimistisch oder Pessimistisch ist eine Entscheidung die du treffen musst. Einen Kompromiss der irgendwie die Vorteile kombiniert ohne sich die Nachteile beider und/oder neue Nachteile reinzuholen kenne ich nicht. Denke auch das das logisch nicht möglich. Bei der Entscheidung rechts oder links abzubiegen hilft es nicht einfach geradeaus zu fahren. Und beide Wege zu nehmen ist nun mal auch keine Option.

Pessimistisch oder Optimistisches Locking ist aber eigentlich kein Thema eines DBMS (außer das dazu vielliecht di eLocks des DBMS verwendet werden) sondern eher der Zugriffsmethode und wi eman die einsetzt. In ADO.Net ist es aufgrund der disconnected Architektur natürlicher optimistisches Locking zu verwenden. Pessimistisches Locking müsstest du explizit ausprogrogrammieren und selber Locks setzen.