API zur Datenbankmodelierung?

Gerade wenn die Datenbank auch Online- Suchmaschine und -Shopsystem für den Endverbraucher werden soll, reichen Views eben nicht aus, sondern es kommen auch noch Formatier-Sachen, Bilddarstellung etc. hinzu.

Bild-Darstellung?

Also, ähm, eher nicht. Ich weiß, daß sich eine Reihe von Leuten bei der FOSDEM drüber unterhalten haben, in pl/pgsql einen Webserver zu bauen, aber Bilddarstellung?

Die Frage ist dann immer was man auf Datenbank-Seite und was auf Anwendungs-Seite macht. Weil ich mit Anwendungs-Programmierung mehr Erfahrung habe als mit RDMS tendiere ich dazu zu viel auf der Anwendungsseite machen zu wollen. Daran Views zu benutzen habe ich gar nicht gedacht und Trigger erschienen mir unnötig kompliziert.

Man kann in der Tat jede Menge in einer (modernen) DB machen, mit Triggern, Stored Proceduren, Constraints, Views und was sonst noch so 'richtige' Datenbanken können. Da die DB deutlich näher an den Daten ist als z.B. eine PHP-Applikation kann das auch deutliche Vorteile bringen.
 
Werbung:
So wie ich es wahrnehme, kann SQL sehr viel aber nicht alles, wie eben eine richtige objektorientierte Programmiersprache.

Gerade dann wenn es um die Umformung und Verarbeitung von Daten geht wirst du mit PHP nie die gleiche Geschwindigkeit erreichen. Davon abgesehen kannst du eine vernünftigen Datenbank um zusätzliche Funktionen erweitern. Den Möglichkeiten sind da nur sehr wenige Grenzen gesetzt.

Trigger sind eine feine Sache wenn man sie begriffen hat. Und im Grunde auch nicht komplizierter als ein IF ... THEN

Dazu benötigst du allerdings eben eine Datenbank die den Namen verdient. Wenn du mit MySQL arbeiten willst bleib bei deinem Ansatz da Vieles einfach nicht unterstützt wird.

Ich persönlich bevorzuge PostgreSQL. Zum Beispiel Oracle oder MS-SQL sollten selbst in den kostenfreien Editionen das Gleiche leisten können. Genaueres kann ich dazu aber nicht sagen.
 
Gerade wenn die Datenbank auch Online- Suchmaschine und -Shopsystem für den Endverbraucher werden soll, reichen Views eben nicht aus, sondern es kommen auch noch Formatier-Sachen, Bilddarstellung etc. hinzu. Die Frage ist dann immer was man auf Datenbank-Seite und was auf Anwendungs-Seite macht.
Formatierung und Darstellung gehört meiner Meinung nach in die Anwendung. Datenbanken können natürlich auch ein Datum oder Zahlen entsprechend den lokalen Gegebenheiten formatieren. Ich bin mir aber recht sicher, dass sich dadurch weder die Geschwindigkeit noch die Last insgesamt positiv beeinflussen lassen.

Außerdem gibt es Datenmanipulationen die sich nicht mal eben in der Datenbank erledigen lassen. Entweder weil externe Dienste oder bestimmte Bibliotheken notwendig sind. Was nicht bedeuten soll, dass es zum Beispiel nicht grundsätzlich machbar sein sollte Grafiken in der Datenbank zu manipulieren.

Bei Berechnungen und Vergleichen wirst du mit PHP kaum eine Datenbank schlagen können. Dafür sind Datenbanken zu sehr spezialisiert und Programmiersprachen zu generell.

Weil ich mit Anwendungs-Programmierung mehr Erfahrung habe als mit RDMS tendiere ich dazu zu viel auf der Anwendungsseite machen zu wollen.
Kenne ich. Ich kann mich noch erinnern wie ich alle Daten abgerufen und einfache Joins in der Anwendung nachgebaut habe. Funktioniert gut als Lasttest des Webservers.
 
Das Problem von Triggern (wie auch von if...then statements) ist, dass sie alle einzeln definiert werden müssen. Bei einem durchdachten, sinnvollen Klassenmodell kann man sich diese automatisch dynamisch generieren lassen - so glaube ich es im Moment zummindest.

Weiter wäre es natürlich auch schön vom Datenbanksystem unabhängig zu sein. Wenn ich alles selbst in php modelliere geht das...

Und ich weiss, dass möglichst alle Abfragen DBMS-seitig ausgeführt werden sollen, da diese Systeme über Jahrzehnte in der Performance und Speicherbedarf optimiert wurden.


Ich denke es lohnt sich daher doch mein Vorhaben zummindest mal vollständig aufzuzeichnen, um zu sehen ob sich eine Implementierung dann wirklich lohnt. Ich bin aber sehr froh um euren Input, denn mir fehlt einfach der Praxisbezug und viele aufgezählten Möglichkeiten waren mir einfach nicht so präsent...
 
Weiter wäre es natürlich auch schön vom Datenbanksystem unabhängig zu sein. Wenn ich alles selbst in php modelliere geht das...

Und ich weiss, dass möglichst alle Abfragen DBMS-seitig ausgeführt werden sollen, da diese Systeme über Jahrzehnte in der Performance und Speicherbedarf optimiert wurden.

Das ist halt das Problem: wenn Du anfängst, es so zu machen, daß es von der DB-Plattform unabhängig sein soll, orientierst Du Dich am 'kleinsten gemeinsammen Nenner', was die Fähigkeiten der DB anbelangt. Kann man machen, hat sicher auch Vorteile. Ich finde aber, noch mehr Nachteile.
 
Weiter wäre es natürlich auch schön vom Datenbanksystem unabhängig zu sein. Wenn ich alles selbst in php modelliere geht das...

Ein frommer Wunsch der praktisch nie erreicht wird. Die meisten Projekte bauen auf MySQL auf und passen die Abfragen dann vielleicht noch an andere Datenbanken an. Damit nimmt man alle Nachteile aber keinerlei Vorteile mit.

Unabhängigkeit spielt doch sowieso nur bei OSS eine Rolle da viele verschiedene Anwender mit genauso vielen verschiedenen Konfigurationen die Software nutzen sollen.

Ich selbst verzichte mittlerweile auf zusätzliche und unnötige Abstraktion. Ein Projekt bekommt eine Datenbankklasse die die Abfragen hinter einem zur Anwendung passenden Interface kapselt. Sollte tatsächlich einmal ein Wechsel nötig sein kann ich immer noch einen neuen "Treiber" schreiben und sämtliche Vorteile des neuen Systems mitnehmen. Ist mir bisher nur einmal passiert. Von SQLite auf PostgreSQL. Allerdings hätte ich die alte Klasse ebenfalls weiterentwickeln müssen, da ich zusätzliche Funktionen verwenden wollte.

Dadurch spare ich mir im Einzelfall viel unnötige Arbeit. Nebenbei spare ich aber auch Ressourcen und habe deutliche Geschwindigkeitsvorteile. Der Einwand der fehlenden Wiederverwendbarkeit wäre natürlich richtig; allerdings nur dann voll gültig wenn jede Anwendung das gleiche Schema verwenden würde.
 
Was haltet ihr eigentlich von Object Relational Mapping wie z.B. Doctrine. Das müsste ja eigentlich genau die Abbildung auf Klassen/Objekte übernehmen. Aber irgendwie habe ich das Gefühl dass das mehr Arbeit generiert als erspart...
 
Werbung:
Zurück
Oben