Hallo zusammen,

ich habe mal zwei grundsätzliche Fragen zur SQL-Anwendung:

1) Update über Joins
Ich möchte Updates in relationalen Tabellen veranlassen und habe dazu eine SQL-Klausel mit "exists + joins" getestet. Das funktionierte überraschender Weise auf Anhieb

zusammenfalten · markieren

Delphi-Quellcode:

procedure SetGamePlayerState(GameId, State: String);
var
  IBSql: TIBSql;
begin
  ...
  IBSql := Querys.IBSql;
  IBSql.Close;
  IBSql.SQL.Clear;
  IBSql.SQL.Add('update States s set State = :State ');
  IBSql.SQL.Add('where exists( ');
  IBSql.SQL.Add(' select st.gid as gid from states st ');
  IBSql.SQL.Add(' left join persons p on (p.stateid = st.gid) ');
  IBSql.SQL.Add(' left join gamepartyplayers gpp on (gpp.personid = p.gid) ');
  IBSql.SQL.Add(' left join gamepartys gp on (gpp.gamepartyid = gp.gid) ');
  IBSql.SQL.Add(' left join games g on (gp.gameid = g.gid) ');
  IBSql.SQL.Add(' where (g.gid = :GameId) and (st.gid = s.gid) ');
  IBSql.SQL.Add(' ) ');
  IBSql.ParamByName('State').AsString := State;
  IBSql.ParamByName('GameId').AsString := GameId;
  IBSql.ExecQuery;
  Querys.FreeQuery(IBSql);
end;

Ein Spiel enthält in dem Fall zwei Spielparteien und diese wiederum 2 Spieler, die wiederum auf eine Person verbinden, welche den eigentlichen Status enthält.

Meine Frage: Ist das der korrekte Weg? Sollte man noch etwas optimieren oder grundsätzlich besser eine StoreProcedure benutzen?
Sehr viele Datensätze sind nicht enthalten, maximal einige hundert Spiele und Spieler.


2) BusinessLogic in Datenbank oder Exe
Ich hatte angefangen, einen Großteil der Geschäftslogik über StoreProcedure in die Datenbank zu integrieren. Das funktioniert jedoch nur bedingt und es ist schwierig, dabei die Verbindung zur Exe aufrecht zu erhalten, da dort auch noch Änderungen bearbeitet werden müssen (z.B. nach Einfügen eines Datensatzes auf die neu erzeugte ID zu reagieren).
Daher beabsichtige ich jetzt doch wieder, die Datenbank weitestgehend als "reinen Datenspeicher" zu verwenden und die Datenbearbeitung komplett aus dem Programm heraus (mittlere Schicht zwischen GUI und DB) zu realisieren. So würden z.B. neue ID´s für neue Datensätze direkt vom Programm vergeben und den betreffenden Tabellen zugewiesen und nicht mehr durch Trigger der DB.
Ich denke, dadurch ist eine flexiblere Handhabe der Daten möglich.
Und der Punkt, weshalb ich im Forum frage:
Außerdem sehe ich sonst Probleme bei späteren Änderungen von Abläufen. Diese wären ja sonst in einer Datenbank fest integriert. Wenn ein Nutzer eine ältere Datenbank öffnet wären ja dort auch die veralteten Abläufe festgelegt, die möglicherweise gar nicht mehr zur aktuellen Exe passen...
Wenn die Geschäftslogik aber komplett in der Exe steckt, müssen die zu öffnenden Datenbanken lediglich die aktuell benötigten Tabellen und Felder enthalten um korrekt benutzt zu werden.
Eine Weiterentwicklung der Software bzw. Fehlerkorrektur wäre m.E. wesentlich unproblematischer.

Wie seht Ihr das? Wieviel Logik gehört in eine SQL-DB?
(Mein Projekt ist kein "normales" DB-Projekt mit DBGrids etc. sondern erzeugt aus den DB-Daten Objekte, mit denen der Nutzer dann arbeiten kann (Drag&Drop etc).
Datenbanken kann der Nutzer selbst anlegen, beliebig speichern und später wieder öffnen. Es gibt also nicht eine zentrale DB für das Projekt).


Stahli

Ich glaube, Du denkst zu kompliziert. Wenn Änderungen an der DB gemacht werden, dann müssen die auch im Programm gemacht werden. Umgekehrt genauso. Wenn einer mit altem Programm auf neue geänderte DB zugreift, dann wirds an den relevanten Stellen wohl krachen. Dasselbe gilt aber auch für neues Programm, das auf alte DB zugreift. Das muss alles genau passen, sonst nützt alles nichts. Die Frage "Was wäre wenn altes Programm und inzwischen geänderte DB..." etc. ist überflüssig.

Jetzt zur Praxis und Deinem Quelltext : bei mir sucht man solche Konstrukte vergeblich. Im Programm wird höchstens hier und da mal ein SelectSQL in diesem Stil zusammengebaut. Z.B. wenn der User die Checkbox "alphabetisch sortieren" anklickt, dann kommt eben noch ein "ORDER BY..." ans Ende des SQL-Strings. Oder er wählt speziell anzuzeigende Felder aus. Für Insert, Update etc. gibt es Methoden, das braucht man also nicht selber zusammenzubauen. Dein Beispiej, das würde bei mir wohl definitiv in SP landen, damit der Delphi-Quelltext lesbar bleibt. SQL ist ja schon so gesehen, ein gewisser Fremdkörper im Delphi Programm. IMHO ist es deshalb besser, seinen Delphi-Quelltext nicht mit SQL-Quelltext zu überfrachten. Und lasse mal die ganzen Leerzeichen in dem String weg. Das Add macht notfalls selber ein Leerzeichen zur Wörtertrennung. Das ist ja entsetzlich.

Hallo Hansa,

danke für Deine Info. Nach längerer Überlegung werde ich aber doch bei meinem angedachten Konzept bleiben.

Die SQL-Funktionen kann ich ja in eigene Units auslagern, wodurch die Übersichtlichkeit des Projektes erhalten bleibt.
Wenn die Funktionen alle in der Datenbank stehen ist diese eben dafür unübersichtlicher.

Wahrscheinlich ist es Geschmackssache, ich denke jedoch inzwischen, dass ICH die Funktionen im Delphi-Quelltext flexibler unterbringen kann.

Gruß
Stahli


PS: Die Update-Klausel mit dem exists scheint ja dann zumindest "in Ordnung" zu sein