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
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