mysql/php4 - Wieviele Datensätze gibt es in einer Tabelle

[Philipp Hasenfratz]

Halihallo Lude

nur ein paar Anmerkungen (zu mehr traue ich mich nicht):

"zu mehr traue ich mich nicht", nun, wenn's nicht wegen mir ist, OK :-)

Hm, das verstehe ich nicht ganz. Warum ist eine Trennung unmöglich?
Eine Trennung koennte zum Beispiel mit irgendwelchen ".NET-Objekten" ins Auge gefasst werden: Objekte fuer die Geschaeftslogik, SPs fuer den "primitiven" Datenzugriff (CRUDL). Wenn die Geschaeftslogikobjekte aber das Schema nicht wirklich kennen (sollen), dann duerfen diese nicht JOINen. Konsequenz: sehr viel Traffic.

Das verstehe ich noch nicht ganz. Also, wenn die Business Rule durch die RDBMS
gesetzt wird und ein Geschäftslogikobjekt das Schema/die Rules nicht genau kennt,
dann wird einfach eine Error-Message ausgegeben (die DB weigert sich). Soviel ist
schätze ich klar. Wieso soll durch das "unwissen" der Geschäftslogikobjecte (GLO kürze
ich mal ab) der Traffic steigen? - Emulierst du den Join über die GLO-Logik (z.B. auf
der Ebene der SPs) um die Business Rule zu umgehen? - Eine Anpassung der GLO wäre
IMHO in diesem Fall klüger und auch sinnvoller, denn die GLO sollten ja genau das tun,
was an Integrität bereits von der Datenbank geprüft wird. Wie bereits gesagt können
VIEWS (u.a.) hier sehr nützlich sein, denn die GLO's haben dann gar keinen anderen
Datenbestand mehr als der, dem sie "zugeteilt" sind.

Ich begreife nicht ganz, wieso dies mehr Traffic verursacht, also irgendwie verstehe
ich die ganze Aussage nicht ganz, aber das könnte damit zusammenhängen, dass ich
absolut nix von .NET verstehe.

[VIEWS]
Diese habe ich fuer "meine" Zwecke noch nicht ernsthaft ins Auge gefasst. (Muss mal meditieren, was das bringen kann)

Och, kann ganz nützlich werden... Aber eben: Performance leided...

Ich bin auch der Meinung, dass die Business Rule vom Programm definiert werden soll,
denn Daten haben mit der Verarbeitung nichts zu tun; das sind zwei Einheiten.
Ich nicht. M.E. ist das Programm idealerweise nur eine Praesentationsschicht, die Benutzeranforderungen an die Business-Objekte, die wiederum an die Datenzugriffsobjekte weiterleitet. Geschaeftslogik laeuft am besten serverseitig.

Öh, wer programmiert die Geschäftslogik auf Javascript (clientseitig)? :-))
OK, wieder ernster: Da bin ich absolut deiner Meinung.

Ich denke
jedoch, dass es bei wirklich sensitiven Applikationen (wie z.B. Bank) durchaus sinnvoll
sein kann, wenn das selbe zweimal umgesetzt ist (diese Redundanz erhöht die Sicherheit
und Stabilität des Gesamtsystems).
Glaube ich auch nicht. btw - Ich kenne nicht so viele sinnvollen Redundanzen. - Da faellt mir datenseitig eigentlich "auf die Schnelle" nur OLAP oder auch Redundanzen wegen Site-Autonomie oder auch Redundanzen wegen (teilweise abstruser) Performanceueberlegungen ein. "Logikseitig" muss ich "auf die Schnelle" ganz passen.

Dass Redundanzen nicht oft vorkommen ist lobenswert, aber _wenn_ sie vorkommen, muss
zu jeder Zeit gewährleistet sein, dass die mehrfachen Abbildungen stets konsistent
sind an sonsten verliert das System an Integrität und Sicherheit.

Viele Grüsse

Philipp