In einer Datenbank wie MySQL kann man sich Selects als Pseudotabellen anlegen und dann selbst wieder über den diese Tabelle einen Select bauen. So etwas nennt man einen View.
Beispiel:
SELECT a.vorname,a.name,b.beruf as beruf FROM Personen as a,Berufe as b WHERE a.berufsid=b.id;
Wenn man diesen Select als View anlegt, hat man drei Felder : Vorname,Name,Beruf
Nennen wir den View mal Test, wäre dieser Select möglich :
SELECT vorname,name FROM Test WHERE beruf = „Bäcker“;
Wenn man nun versucht den VIEW mit UPDATE zu ändern, geht das eigentlich nicht, weil es eine nicht eindeutige Beziehung der Datensätze untereinander ist.
Für mein aktuelles Pandora Projekt habe ich nun einen View gebaut, bei dem das Update tatsächlich möglich ist:
select `pa`.`id` AS `id`,`pa`.`vorname` AS `vorname`,`pa`.`nachname` AS `nachname`,`pa`.`server` AS `server`,`pc`.`value` AS `friendmode` from (`pandora`.`pandora_config` `pc` join `pandora`.`pandora_account` `pa`) where ((`pa`.`id` = `pc`.`uid`) and (`pc`.`name` = ‚michsuchen‘))
Das funktioniert aufgrund dieser Beziehung „((`pa`.`id` = `pc`.`uid`)“ , denn in beiden Tabellen gibt es exakt einen eindeutigen Datensatz. d.b. :
Für jede Person gibt es exakt einen Config Eintrag in der anderen Tabelle. Damit kann der Datenbankserver jetzt die logische Verbindung der Datensätze „rückwärts“ auflösen und in der richtigen Tabelle den richtigen Eintrag ändern:
UPDATE `pandora_userliste` SET friendmode = ‚erlauben‘ WHERE vorname =’meinvorname‘;
Damit ist der View Read/Writeable geworden was es man mit Hilfe des ORDB Frameworks ausnutzen kann, denn Views werden ein Java Datenobjekte erzeugt. Über Views lassen sich schlanke Strukturen und Datenbankobjekte erzeugen, die dazu noch updatefähig sein können (aber nicht müssen). Als Folge davon erhält man übersichtliche Datenbankstrukturen, die von einem Menschen leicht gelesen und verstanden werden können, aber trotzdem Datenbanktechnisch höchst performant gestaltet sein können.
