Mailinglisten-Archive |
Hi Sebastian, > Mir fehlt etwas die Fantasie zu verstehen wo für die Datenkonsistenz > Trigger nicht ausreichen in normalisierten DB? Ich denke das hängt von der Struktur ab. Normalisiert sollte sie schon sein, allerdings gibts selbst in normalisierten Datenbanken Konstrukte, die nicht ganz einfach sind. Wenn man bislang nur mit Datenbanken ohne z.B. Foreign Keys gearbeitet hat, ist man sicherlich noch nicht in diese Probleme gerannt, aber wenn es dann kniffliger wird, sollte man dann schon trigger bemühen. Übrigens, weil du unten Views erwähntest. In Views kann man lediglich lesen, das Schreiben wird (unter Postgres) über Trigger erledigt, wenn es sich um Views über mehrere Tables handelt. > eine DB soll: einfügen, anzeigen, löschen, oder? Was auf Webanwendungen auch zutrifft, da macht man auch nichts anderes damit. U.a. könnte man diese Probleme auch prima mit Excel lösen (Die Performance geht dabei zwar etwas in die Knie, aber gehen sollte es). :) Nicht umsonst gibts ja sqlite. > Den Rest (Auswertung, Analyse, Presentation, ...) sollte eigentlich > alles die Anwendung machen. Nö, stimmt nicht. Es gibt schon gute Gründe, warum man das nicht der Applikation überläßt. Warum sollte ich bei Millarden von Datensätzen, diese auf eine Applikation schaufeln, sie analysieren und dann zurückschreiben. Mach das mal in einem Webseitenaufruf, da dürfte man das dann deutlich erkennen. > Duplizierung von Code wird durch die Verwendung von Klassen > entgegengewirkt, wird ein Frontend in einer anderen Sprache > geschrieben > muss man wohl in den sauren Apfel beißen. Stimmt, der Duplizierung von Code kann man so entgegenwirken, aber warum sollte man Dinge nicht an der Stelle machen, die dafür ggf. sogar entwickelt worden ist. (Zum Beispiel Postgres mit "r") > Ein was sinnvolles in diesem Zusammenhang wären so gennante 'Views', > die > sollten wirklich in der DB gespeichert werden können, Werden sie ja auch. > z. B. statt 'SELECT ... ein superlanges select mit 20 joins ...' > > einfach: 'SELECT * meinview WHERE ' Views halte ich aus Performancegründen für Webseiten für eine Bremse. In der Regel gibts du, wie oben geschrieben dein Select ab. Dieses führt dann das Select aus, mit dem die View die Daten zusammenstellt und zurückgibt. D.h. aus Bequemlichkeit ein SELECT zu viel. Man kann zwar mittels EXPLAIN einiges optimieren, aber wenn man wert auf Performance legt sicherlich nicht optimal. > aber eigentlich auch alles egal, es ändert ja nichts an meiner Aussage Gruß Marc -- Marc Ende me at e-beyond.de
php::bar PHP Wiki - Listenarchive