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

[Compu]

Hi,

ich möchte dem Kunden sagen, wieviele Artikel es ingesamt in einer Tabelle gibt.
Ich habe mal auf folgender Seite geguckt:

http://www.php.net/manual/en/ref.mysql.php

Nun bin ich mir nicht sicher welcher Befehl in Betracht kommt.
mysql_get_num_rows ?

Wie muss ich den mysql Befehl dann schreiben?

Danke

[Cheatah]

Hi,

Ich habe mal auf folgender Seite geguckt:

löblich[tm]. Du solltest aber auch mal in der MySQL-Doku nachschlagen, denn schließlich ist es Sache der DB zu wissen, was sie für Inhalte hat, nicht der irgendeiner Technik, die darauf zugreift.

Nun bin ich mir nicht sicher welcher Befehl in Betracht kommt.

Die COUNT()-Funktion.

Cheatah

[Lude]

Hi,

Nun bin ich mir nicht sicher welcher Befehl in Betracht kommt.

Die COUNT()-Funktion.

manchmal macht es Sinn die Information direkt aus einer Systemtabelle des RDB(M)S zu holen: Z.B. beim 'MS SQL Server' aus '<server>.master..sysobjects'. - Ausserdem kann man so komplizierte SQL-Aufrufe wie 'count()' vermeiden.

Gruss,
Lude

[Compu]

Hi,

Danke für die Antworten.
Das Problem ist bei mir ich suche in der Doku immer an der falschen Stelle.

Aber nun habe ich einen Ausstzer.
Wie bekomme ich count() in eine Varible?

$sql = "SELECT COUNT(*) FROM artikeldetails";
$result = mysql_query($sql, $dbConnection);
$row = mysql_ ..... ?

Danke

[Herbalizer]

Hi!

$sql = "SELECT COUNT(*) FROM artikeldetails";
$result = mysql_query($sql, $dbConnection);
$row = mysql_ ..... ?

Mit den üblichen Techniken http://www.php.net/manual/de/ref.mysql.php, zB.:

$row = mysql_fetch_row( $result );
$anzahl = $row[0];

Gruß Herbalizer

[Philipp Hasenfratz]

Halihallo Lude

Nun bin ich mir nicht sicher welcher Befehl in Betracht kommt.
Die COUNT()-Funktion.
manchmal macht es Sinn die Information direkt aus einer Systemtabelle des RDB(M)S zu holen: Z.B. beim 'MS SQL Server' aus '<server>.master..sysobjects'. - Ausserdem kann man so komplizierte SQL-Aufrufe wie 'count()' vermeiden.

Jain. a) gibt es in MySQL (und das wurde geannt!) keine Systemtabellen und b)
wird COUNT(*) diesbezüglich optimiert, dass die Daten sozusagen aus:

"SHOW TABLE STATUS LIKE 'tabellen_name'", Attribut Rows

gesaugt werden (diese Information steht im Table-Header und die DBMS ist somit nicht auf
das Auszählen angewiesen => wird vom QueryOptimizer optimiert, sollte zumindest).

Übrigens: Was ist an SELECT COUNT(*) FROM tabelle kompliziert? :-)

Viele Grüsse

Philipp

[Lude]

Hi,

Übrigens: Was ist an SELECT COUNT(*) FROM tabelle kompliziert? :-)

kann man denn unter MySQL nicht einmal das Schema der Datenbank, sprich u.a. deren Tabellen, abfragen? - Wie wird denn da referentielle Integritaet sichergestellt?

Gruss,
Lude

[Philipp Hasenfratz]

Halihallo Lude

Übrigens: Was ist an SELECT COUNT(*) FROM tabelle kompliziert? :-)
kann man denn unter MySQL nicht einmal das Schema der Datenbank, sprich u.a. deren Tabellen, abfragen? - Wie wird denn da referentielle Integritaet sichergestellt?

Gar nicht. In Sachen Datenintegrität ist MySQL eine Krücke.
Nun, ich hoffe, dass sich dies in Zukunft wirklich ändern wird. Aber im Moment scheinen
diese Anforderungen noch keinen Grosskunden von MySQL zu interessieren :-(

Viele Grüsse

Philipp

[Andreas Korthaus]

Hi!

kann man denn unter MySQL nicht einmal das Schema der Datenbank, sprich u.a. deren Tabellen, abfragen? - Wie wird denn da referentielle Integritaet sichergestellt?

Gar nicht.

War nicht 'SHOW TABLE STATUS' genau das?

In Sachen Datenintegrität ist MySQL eine Krücke.

Meinst Du Fremdschlüssel, referenzielle Integrität? Das kann MySQl seit 3.23.43b: http://www.mysql.com/doc/en/InnoDB_foreign_key_constraints.html. MySQL hat halt verschiedene Tabellen treiber die für verschiedene Anwendungsbereiche gedacht sind.

Nun, ich hoffe, dass sich dies in Zukunft wirklich ändern wird. Aber im Moment scheinen
diese Anforderungen noch keinen Grosskunden von MySQL zu interessieren :-(

Doch. Fremdschlüssel werden wohl auch in MySQl 5.1 in MyIsam Treiber integriert. Und nicht nur das:

Feature                 MySQL version

Subqueries              4.1
Foreign keys            5.1 (3.23 with InnoDB)
Views                   5.1
Stored procedures       5.0
Triggers                5.1
Unions                  4.0
Full outer join         5.1
Constraints             5.1
Cursors                 5.0
R-trees                 4.1 (for MyISAM tables)
Inherited tables        Not planned
Extensible type system  Not planned

und noch viel mehr, Transaktionen gehen ja schon länger mit InnoDB, aber das ist auch gerade das Problem. IMO setzt MySQL irgendwie die falschen Schwerpunkte, es werden ohne Ende Features nachgeschoben, aber die wirklich interessanten lassen noch lange auf sich warten. Auch kann ich den InnoDB Treiber nicht wirklich bewerten, die Features sind halt noch viel neuer als z.B. in PostgreSQL, und ich weiß nicht wie stabil das ganze heute schon ist, aber bisher habe ich  da noch nichts negatives gehört. Nur wenn man mal überlegt wie lange es mit MySQL 4 gedauert hat bis es endlich produktiv wurde, kann man auf 5 vermutlich noch ne ganze Zeit warten, wobei 4.1 dagegen in einigen Monaten stabil werden soll. Naja, man wird sehen, ich denke auch dass durch die Zusammenarbeit mit SAP und dadurch mit den Erfahrungen von SAP DB bzw. ADABAS einiges in dieser Richtung ins rollen kommen wird, aber sowas dauert halt, heute kann man MySQL für viele Zwecke sicher noch nicht einsetzen, aber warten wir mal ab...

Grüße
Andreas

PS: http://www.mysql.com/doc/en/TODO.html

[Philipp Hasenfratz]

Halihallo Andreas

kann man denn unter MySQL nicht einmal das Schema der Datenbank, sprich u.a. deren Tabellen, abfragen? - Wie wird denn da referentielle Integritaet sichergestellt?
Gar nicht.
War nicht 'SHOW TABLE STATUS' genau das?

Wie meinst du das? - SHOW TABLE STATUS zeigt dir etwas, aber sorgt doch nicht für
referenzielle Integrität... ?

In Sachen Datenintegrität ist MySQL eine Krücke.
Meinst Du Fremdschlüssel, referenzielle Integrität? Das kann MySQl seit 3.23.43b: http://www.mysql.com/doc/en/InnoDB_foreign_key_constraints.html. MySQL hat halt verschiedene Tabellen treiber die für verschiedene Anwendungsbereiche gedacht sind.

Nun, Fremdschlüssel sind die Voraussetzung für die referenzielle Integrität. Beispiel:
Du hast zwei Relationen, Kunde und Artikel. Nun fügst du einen neuen Artikel ein,
der jedoch keinem existierenden Kunden zugeordnet wird (referenzielle Integrität)
=> die Datenbank darf die Aktion nicht ausführen.

Nun, ich hoffe, dass sich dies in Zukunft wirklich ändern wird. Aber im Moment scheinen
diese Anforderungen noch keinen Grosskunden von MySQL zu interessieren :-(
Doch. Fremdschlüssel werden wohl auch in MySQl 5.1 in MyIsam Treiber integriert. Und nicht nur das:

OK, ich habe etwas schwarz gemalt :-)
Aber 5.0, hm... bin ein ungeduldiger Mensch :-)

und noch viel mehr, Transaktionen gehen ja schon länger mit InnoDB, aber das ist auch gerade das Problem. IMO setzt MySQL irgendwie die falschen Schwerpunkte, es werden ohne Ende Features nachgeschoben, aber die wirklich interessanten lassen noch lange auf sich warten.

Leider ja.

Auch kann ich den InnoDB Treiber nicht wirklich bewerten, die Features sind halt noch viel neuer als z.B. in PostgreSQL, und ich weiß nicht wie stabil das ganze heute schon ist, aber bisher habe ich  da noch nichts negatives gehört. Nur wenn man mal überlegt wie lange es mit MySQL 4 gedauert hat bis es endlich produktiv wurde, kann man auf 5 vermutlich noch ne ganze Zeit warten, wobei 4.1 dagegen in einigen Monaten stabil werden soll. Naja, man wird sehen, ich denke auch dass durch die Zusammenarbeit mit SAP und dadurch mit den Erfahrungen von SAP DB bzw. ADABAS einiges in dieser Richtung ins rollen kommen wird, aber sowas dauert halt, heute kann man MySQL für viele Zwecke sicher noch nicht einsetzen, aber warten wir mal ab...

Nun, ich weiss nicht, wie sehr MySQL auf die Integritäten setzt, es gibt ja noch weitaus
mehr als die referenzielle (wobei ja einige auch schon durch MySQL implementiert sind,
das muss ich fairerweise auch erwähnen)... Die 5-er Version scheint schon etwas in dieser
Richtung zu ändern.

PS: http://www.mysql.com/doc/en/TODO.html

eben :-))

Viele Grüsse

Philipp

[Andreas Korthaus]

Hi!

kann man denn unter MySQL nicht einmal das Schema der Datenbank, sprich u.a. deren Tabellen, abfragen? - Wie wird denn da referentielle Integritaet sichergestellt?
Gar nicht.
War nicht 'SHOW TABLE STATUS' genau das?

Wie meinst du das? - SHOW TABLE STATUS zeigt dir etwas, aber sorgt doch nicht für
referenzielle Integrität... ?

Nein, aber man kann damit "das Schema der DB, sprich u.a. deren Tabellen abfragen", oder?

Nun, ich hoffe, dass sich dies in Zukunft wirklich ändern wird. Aber im Moment scheinen
diese Anforderungen noch keinen Grosskunden von MySQL zu interessieren :-(
Doch. Fremdschlüssel werden wohl auch in MySQl 5.1 in MyIsam Treiber integriert. Und nicht nur das:

OK, ich habe etwas schwarz gemalt :-)
Aber 5.0, hm... bin ein ungeduldiger Mensch :-)

Ich auch ;-)
Aber wenn man InnoDB Tabellen verwendet kann man Fremdschlüssel schon länger einsetzen, im Gegensatz zu MyIsam wo die Schlüssel nur da sind und nichts machen.

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Wie meinst du das? - SHOW TABLE STATUS zeigt dir etwas, aber sorgt doch nicht für
referenzielle Integrität... ?
Nein, aber man kann damit "das Schema der DB, sprich u.a. deren Tabellen abfragen", oder?

Die Ausgaben von SHOW TABLE STATUS sind bedürftig:
http://www.mysql.com/doc/en/SHOW_TABLE_STATUS.html
die Ursprungsfrage war ja, wieviele Datensätze es gibt und diese Information findet
man darin. Was du meinst, ist wohl:
http://www.mysql.com/doc/en/SHOW_DATABASE_INFO.html
(SHOW COLUMNS FROM table) dort wird wenn, dann der Foreign Key stehen.

OK, ich habe etwas schwarz gemalt :-)
Aber 5.0, hm... bin ein ungeduldiger Mensch :-)
Aber wenn man InnoDB Tabellen verwendet kann man Fremdschlüssel schon länger einsetzen, im Gegensatz zu MyIsam wo die Schlüssel nur da sind und nichts machen.

Ja, was aber nicht heisst, dass damit Integritätstests ausgeführt werden. Das ist wie
schon gesagt, lediglich die "Grundlage" um überhaupt referenzielle Integrität
sicherzustellen. Ob das MySQL tut oder nicht, weiss ich leider nicht.

Viele Grüsse

Philipp

[Andreas Korthaus]

Hi Philipp!

Die Ausgaben von SHOW TABLE STATUS sind bedürftig:
http://www.mysql.com/doc/en/SHOW_TABLE_STATUS.html
die Ursprungsfrage war ja, wieviele Datensätze es gibt und diese Information findet
man darin. Was du meinst, ist wohl:
http://www.mysql.com/doc/en/SHOW_DATABASE_INFO.html
(SHOW COLUMNS FROM table) dort wird wenn, dann der Foreign Key stehen.

Ich weiß halt nicht welche Infos Lude genau vermisst ;-)
Und ich weiß auch nicht was diese Infos direkt mit referenzieller Integrität zu tun haben, ich weiß nur das InnoDB Tabellen dies beherrschen, wie mysql das jetzt im einzelnen macht/speichert weiß ich nicht.

OK, ich habe etwas schwarz gemalt :-)
Aber 5.0, hm... bin ein ungeduldiger Mensch :-)
Aber wenn man InnoDB Tabellen verwendet kann man Fremdschlüssel schon länger einsetzen, im Gegensatz zu MyIsam wo die Schlüssel nur da sind und nichts machen.

Ja, was aber nicht heisst, dass damit Integritätstests ausgeführt werden. Das ist wie
schon gesagt, lediglich die "Grundlage" um überhaupt referenzielle Integrität
sicherzustellen. Ob das MySQL tut oder nicht, weiss ich leider nicht.

Das interessiert mich jetzt, also nochmal der Link:
http://www.mysql.com/doc/en/InnoDB_foreign_key_constraints.html ;-)

Und hier(http://www.mysql.com/doc/en/ANSI_diff_Foreign_Keys.html) steht folgendes:
"1.8.4.5 Foreign Keys

In MySQL Server 3.23.44 and up, InnoDB tables support checking of foreign key constraints, including CASCADE, ON DELETE, and ON UPDATE. See section 7.5.5.2 Foreign Key Constraints.

For other table types, MySQL Server only parses the FOREIGN KEY syntax in CREATE TABLE commands, but does not use/store this info."

Und unter obigem Link ist genau erklärt wie das funkitoniert. Ist das jetzt referenzielle Integrität oder nicht? Ich habe es noch nie verwendet, will das aber demnächst mal machen, aber zur Zeit habe ich keinen Server der InnoDB - Tabellen anbietet...

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Ich weiß halt nicht welche Infos Lude genau vermisst ;-)
Und ich weiß auch nicht was diese Infos direkt mit referenzieller Integrität zu tun haben, ich weiß nur das InnoDB Tabellen dies beherrschen, wie mysql das jetzt im einzelnen macht/speichert weiß ich nicht.

shame on me, ich sollte mehr Doku lesen. Dass Foreign Keys und auch einfache
Constraints definiert werden können, war mir bewusst, aber dass die Funktionen schon
so ausgereift sind habe ich übersehen.

Und unter obigem Link ist genau erklärt wie das funkitoniert. Ist das jetzt referenzielle Integrität oder nicht? Ich habe es noch nie verwendet, will das aber demnächst mal machen, aber zur Zeit habe ich keinen Server der InnoDB - Tabellen anbietet...

*ARGS* ich habe mein schlaues SQL-Buch (SQL the complete reference) vorgestern nach
Hause verlegt und habe somit mein externes Hirn verloren, daher kann ich grad nicht
wirklich fundiert und wissend aussagen. :-)

Aber ja, ich glaube die Constraints dürften die referenzielle Integrität sicherstellen,
soweit ich das jetzt beurteilen kann. Ich werde es morgen mitnehmen, dann kann ich
ggf. noch andere Integritäten nennen (die kenne ich jetzt nicht alle auswendig).
Nun, ich will jetzt ja auch nicht den Glauben verbreiten, dass referenzielle Integrität
genau definiert ist; es ist IMHO ein Sammelbegriff für eine mögliche Anomalie.

Viele Grüsse

Philipp

[Andreas Korthaus]

Hi Philipp!

shame on me, ich sollte mehr Doku lesen.

;-)

Dass Foreign Keys und auch einfache
Constraints definiert werden können, war mir bewusst, aber dass die Funktionen schon
so ausgereift sind habe ich übersehen.

Ja, in MyISAM sind sie nur aus Kompatibilitätsgründen mit ODBC-Treibern drin, aber sie haben keinerlei Funktions, sie sind nur da, machen aber nichts.

Und unter obigem Link ist genau erklärt wie das funkitoniert. Ist das jetzt referenzielle Integrität oder nicht? Ich habe es noch nie verwendet, will das aber demnächst mal machen, aber zur Zeit habe ich keinen Server der InnoDB - Tabellen anbietet...

*ARGS* ich habe mein schlaues SQL-Buch (SQL the complete reference) vorgestern nach
Hause verlegt und habe somit mein externes Hirn verloren, daher kann ich grad nicht
wirklich fundiert und wissend aussagen. :-)

Sollte ich mir vielleicht auch mal zulegen, die einziegn Bücher die ich habe sind ++ber PERL und C++, aber wirklich durchgearbeitet habe ich die noch nicht ;-)

Aber ja, ich glaube die Constraints dürften die referenzielle Integrität sicherstellen,
soweit ich das jetzt beurteilen kann. Ich werde es morgen mitnehmen, dann kann ich
ggf. noch andere Integritäten nennen (die kenne ich jetzt nicht alle auswendig).

Das weiß ich auch nicht, aber es besteht die Möglichkeit beim Löschen eines Datensatzes aus der Parent-Tabelle automatisch alle referenzierten Datensätze aus der/den Child-Tabellen zu löschen. Das ist doch schonmal was, das könnte ich _sehr_ gut gebrauchen!

Naja, wenn ich das richtig verstehe kann das MySQL also grundlegend bei InnoDB Tabellen, aber noch lange nicht so ausgefeilt wie Oracle & Co., Wobei mir das eigentlich fürs erste reicht...

• so nebenbei - SHOW INNODB STATUS könnte die von Lude gewünschten Infos enthalten...

Nun, ich will jetzt ja auch nicht den Glauben verbreiten, dass referenzielle Integrität
genau definiert ist; es ist IMHO ein Sammelbegriff für eine mögliche Anomalie.

Wie gesagt habe ich davon wenig Ahnung, aber mein Verständnis davon ist, dass referenzielle Integrität einfach bedeutet, dass verknüpfte Datensätze nicht isoliert betrachtet werden müssen, sondern dass wie oben beschreiben wenn ein Datensatz gelöscht wird alle verknüpften ebenfalls gelöscht werden. Oder geht das noch weiter? Ich bin gespannt was Dein schlaues Buch dazu sagt ;-))

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

*ARGS* ich habe mein schlaues SQL-Buch (SQL the complete reference) vorgestern nach
Hause verlegt und habe somit mein externes Hirn verloren, daher kann ich grad nicht
wirklich fundiert und wissend aussagen. :-)
Sollte ich mir vielleicht auch mal zulegen, die einziegn Bücher die ich habe sind ++ber PERL und C++, aber wirklich durchgearbeitet habe ich die noch nicht ;-)

Ja, also die "SQL the complete reference"
http://www.amazon.de/exec/obidos/ASIN/0072225599/qid=1054826978/sr=2-2/ref=sr_aps_prod_2_1/302-2941283-6201631
ist sehr empfehlenswert. Manchmal ist es aber auch wirklich für Laien
geschreiben, wie mir scheint... Aber es ist doch sehr ausführlich und nicht zu letzt,
ziemlich dick :-)

Aber ja, ich glaube die Constraints dürften die referenzielle Integrität sicherstellen,
soweit ich das jetzt beurteilen kann. Ich werde es morgen mitnehmen, dann kann ich
ggf. noch andere Integritäten nennen (die kenne ich jetzt nicht alle auswendig).

Das weiß ich auch nicht, aber es besteht die Möglichkeit beim Löschen eines Datensatzes aus der Parent-Tabelle automatisch alle referenzierten Datensätze aus der/den Child-Tabellen zu löschen. Das ist doch schonmal was, das könnte ich _sehr_ gut gebrauchen!

Oh, mir kam in den Sinn, dass ich mir das mit den Integritäten mal aufgeschrieben habe:
 Valid Column Integrity (Welche Daten werden überhaupt unterstützt?)
 Required Data Integrity (Welche Daten müssen unbedingt vorhanden sein?)
 Data validity Integrity (Ist der Datentyp und inhalt OK?)
 Entity integrity ( ist der Primärschlüssel wirklich unique?; implizit durch Datenbank gegeben )
 Referential integrity ( sind die Foreignkeys existent? - Foreign muss Primary der Foreign-Tabelle sein )
 Business Rule integrity ( unterstützt der Account überhaupt Funktion A,B,C )
 Consistency integrity ( sind die Daten konsistent?  z.B. wenn Datum für
letzten Gebrauch gewechselt wurde, muss letzer Check auch geändert werden)

Wie man sieht, sind es wirklich nur "Oberbegriffe" für viele Arten der Anomalien.

Naja, wenn ich das richtig verstehe kann das MySQL also grundlegend bei InnoDB Tabellen, aber noch lange nicht so ausgefeilt wie Oracle & Co., Wobei mir das eigentlich fürs erste reicht...

Ja, denke ich auch. Für die meisten Anwendungen dürfte es wirklich reichen. Alles
weitere kann dann von mir aus in MySQL 6.x kommen :-)

• so nebenbei - SHOW INNODB STATUS könnte die von Lude gewünschten Infos enthalten...

SHOW INNODB STATUS??? - Meine Güte du liest genau! - Das versteckte sich ja irgendwo
in der Foreign_key_constraints. Aber wirklich eine Doku dazu habe ich noch nicht
gefunden. Oder suche ich falsch? (das ist eine rhetorische Frage! *g*)

Nun, ich will jetzt ja auch nicht den Glauben verbreiten, dass referenzielle Integrität
genau definiert ist; es ist IMHO ein Sammelbegriff für eine mögliche Anomalie.
Wie gesagt habe ich davon wenig Ahnung, aber mein Verständnis davon ist, dass referenzielle Integrität einfach bedeutet, dass verknüpfte Datensätze nicht isoliert betrachtet werden müssen, sondern dass wie oben beschreiben wenn ein Datensatz gelöscht wird alle verknüpften ebenfalls gelöscht werden. Oder geht das noch weiter? Ich bin gespannt was Dein schlaues Buch dazu sagt ;-))

Genaueres als das oben kann ich im Moment nicht sagen, aber ich glaube, dass es auch
nicht näher erleutert wurde. Ich nehme an, dass sich hinter der
"Referenziellen Integrität" wirklich nur das verbirgt (ich werd mal noch nachsehen,
vielleicht ist es ja doch schlauer, dieses Buch *g*).

Viele Grüsse

Philipp

[Lude]

Hi,

Nun, ich weiss nicht, wie sehr MySQL auf die Integritäten setzt, es gibt ja noch weitaus
mehr als die referenzielle

wie heissen denn die anderen Integritaeten?

Gruss,
Lude

[Philipp Hasenfratz]

Halihallo Lude

Nun, ich weiss nicht, wie sehr MySQL auf die Integritäten setzt, es gibt ja noch weitaus
mehr als die referenzielle
wie heissen denn die anderen Integritaeten?

Hab sie irgendwo in meinen alten Dokumenten doch schon früher wiedergefunden:
[pref:t=48662&m=266748].

Viele Grüsse

Philipp

[Lude]

Hi,

sehr schlau, mit einem Posting gleich zwei Fragesteller zufriednzustellen. (Mein Traum war es immer mit einer Antwort alle jemals gestellten Fragen beantworten zu koennen)

ich zerpfluecke das mal etwas:

Oh, mir kam in den Sinn, dass ich mir das mit den Integritäten mal aufgeschrieben habe:

Valid Column Integrity (Welche Daten werden überhaupt unterstützt?)

Da gibt es unter 'MSSQLSrv' die Regeln und die Datentypen.

Required Data Integrity (Welche Daten müssen unbedingt vorhanden sein?)

Spielt das auf NULL-Werte an?

Data validity Integrity (Ist der Datentyp und inhalt OK?)

Validieren gegen ein Schema. Dafuer gibt's XML-Schema.

Entity integrity ( ist der Primärschlüssel wirklich unique?; implizit durch Datenbank gegeben )

.

Referential integrity ( sind die Foreignkeys existent? - Foreign muss Primary der Foreign-Tabelle sein )

schon besprochen.

Business Rule integrity ( unterstützt der Account überhaupt Funktion A,B,C )

Na, und wo liegt die Geschaeftslogik? - Vielleicht in der umgebenden Programmlogik?

Consistency integrity ( sind die Daten konsistent?  z.B. wenn Datum für

letzten Gebrauch gewechselt wurde, muss letzer Check auch geändert werden)

Datenkonsistenz ist dann gegeben, wenn die Information auf genau eine Art und Weise aus dem Datenbestand gewonnen werden kann. (Dr.B.)

Besten Dank fuer Deine Beitraege!

Gruss,
Lude

[Philipp Hasenfratz]

Halihallo Lude

sehr schlau, mit einem Posting gleich zwei Fragesteller zufriednzustellen. (Mein Traum war es immer mit einer Antwort alle jemals gestellten Fragen beantworten zu koennen)

Oh da bist du nicht alleine: Du suchst nach der "Theory of everything" (TOE). Eine
Theorie mit der man alles erklären kann... Einsteinanhänger und Quantentheoretiker sind
schon lange auf der Suche danach :-)

Valid Column Integrity (Welche Daten werden überhaupt unterstützt?)
Da gibt es unter 'MSSQLSrv' die Regeln und die Datentypen.

Ja, eigentlich bei den meisten Datenbanken, die die "basics" können. Es geht hier um
das definieren von CONSTRAINTS bzw. CHECK.

Required Data Integrity (Welche Daten müssen unbedingt vorhanden sein?)
Spielt das auf NULL-Werte an?

Ich glaube nicht nur. Nehmen wir an, dass mehrere Attribute required sind und somit beim
INSERT/UPDATE mit NOT NULL Werten gefüllt werden müssen, so müssten diese natürlich mit
NOT NULL definiert sein, nur haben wir dann das Problem, dass der Defaultwert eben auch
nicht NULL sein darf und somit liesse sich das 'required' nicht mehr ohne CHECK checken,
weil ja jedes nicht gesetzte Attribut mit einem gültigen NOT NULL Wert gefüllt wird und
die Rule nicht verletzt werden würde.

Data validity Integrity (Ist der Datentyp und inhalt OK?)
Validieren gegen ein Schema. Dafuer gibt's XML-Schema.

Glaube nicht, dass damit dies gemeint war :-)
Ich schätze mal, dass _diese_ Integrität von allen RDBMS implizit durch Datentyp-
deklaration beim CREATE erfüllt ist, obwohl auch hier ein Check des Inhaltes zur
vollständigkeit durchgeführt werden müsste. Z.B. wäre die Datenvalidität bei einem
UPDATE test (int_value) VALUES ('123test'); nicht sichergestellt, da '123test' nicht
dem transformierten Integer '123' entspricht.

Entity integrity ( ist der Primärschlüssel wirklich unique?; implizit durch Datenbank gegeben )
.

Ja, Punkt. :-)

Business Rule integrity ( unterstützt der Account überhaupt Funktion A,B,C )
Na, und wo liegt die Geschaeftslogik? - Vielleicht in der umgebenden Programmlogik?

Nun, das möchte man genau verhindern. Stell dir ein Informationssystem von einer
grossen Bank vor. Tausende von Clients, seien dies nun EC-Bankomaten, Filialrechner,
oder der Mainframe selber greifen auf dieselbe Datenbank zu (das ist zwar _nie_ so,
aber dennoch taugt es als Beispiel). Stell dir vor, dass nur ein einziges System ein
Security-Leak hätte und die Business Rules nicht genau umsetzt... Milliardenschäden!

Es geht darum, die Datenintegrität an einem und nur einem Ort sicherzustellen und dieser
Ort ist genau da, wo alles koordiniert wird: Bei der RDBMS selber.

Consistency integrity ( sind die Daten konsistent?  z.B. wenn Datum für
letzten Gebrauch gewechselt wurde, muss letzer Check auch geändert werden)
Datenkonsistenz ist dann gegeben, wenn die Information auf genau eine Art und Weise aus dem Datenbestand gewonnen werden kann. (Dr.B.)

Nun, das ist zwar richtig und spielt IMHO auf die Normalformen an, aber oftmals ist
eine Datenbank eben nicht ganz redundanzfrei (zwecks Performance) und dann ist es eben
möglich Daten auf verschiedene weisen aus der DB zu extrahieren und die Konsistenz
dieser redundanten Information muss eben stets gegeben sein (ansonsten wieder Mil-
liardenschäden).

---

Puh, krasse Geschichte mit den Datenbanken :-)

Viele Grüsse

Philipp

[Lude]

Hi,

Business Rule integrity ( unterstützt der Account überhaupt Funktion A,B,C )
Na, und wo liegt die Geschaeftslogik? - Vielleicht in der umgebenden Programmlogik?

Nun, das möchte man genau verhindern. Stell dir ein Informationssystem von einer
grossen Bank vor. Tausende von Clients, seien dies nun EC-Bankomaten, Filialrechner,
oder der Mainframe selber greifen auf dieselbe Datenbank zu (das ist zwar _nie_ so,
aber dennoch taugt es als Beispiel). Stell dir vor, dass nur ein einziges System ein
Security-Leak hätte und die Business Rules nicht genau umsetzt... Milliardenschäden!

ich versuche seit Jahren Geschaeftslogik von Datenzugriffslogik zu trennen (im MSSQL-RDB(M)S). Es misslingt. Neueste Erkenntnisse deuten darauf hin, dass es nicht geht. Denn fuer geschaeftslogische Datenzugriffe braucht man halt verschiedene JOINts ueber etliche Tabellen. Und damit waere eine Trennung unmoeglich.

Gruss,
Lude

[Philipp Hasenfratz]

Halihallo Lude

Nun, das möchte man genau verhindern. Stell dir ein Informationssystem von einer
grossen Bank vor. Tausende von Clients, seien dies nun EC-Bankomaten, Filialrechner,
oder der Mainframe selber greifen auf dieselbe Datenbank zu (das ist zwar _nie_ so,
aber dennoch taugt es als Beispiel). Stell dir vor, dass nur ein einziges System ein
Security-Leak hätte und die Business Rules nicht genau umsetzt... Milliardenschäden!

ich versuche seit Jahren Geschaeftslogik von Datenzugriffslogik zu trennen (im MSSQL-RDB(M)S). Es misslingt. Neueste Erkenntnisse deuten darauf hin, dass es nicht geht. Denn fuer geschaeftslogische Datenzugriffe braucht man halt verschiedene JOINts ueber etliche Tabellen. Und damit waere eine Trennung unmoeglich.

Hm, das verstehe ich nicht ganz. Warum ist eine Trennung unmöglich?
Es geht ja nicht darum alles auf die Datenbank auszulagern, sondern sinnvolle (auch in
Hinsicht auf die Performance) VIEWS zu bilden (u.a.), sodass z.B. ein EC-Bankomat -
wenn ich das Beispiel kurz wiederverwerten darf - wirklich nur Konten "sieht", die
auch per EC-Karte "ansprechbar" sind. Egal, ob die Business Rule im Bankomaten richtig
oder falsch umgesetzt ist, wird der Bankomat keinen Zugriff auf Konten ohne EC-Karte
ermöglichen, da er diese gar nicht erst sieht. Natürlich kann man das etwas "weit"
treiben und dann werden die Queries gigantisch komplex, sowas sollte man ggf. wirklich
dem Programm überlassen. Dass komplexe Joins in VIEWS starke Konsequenzen auf die
Performance haben ist klar, denn die Datenbank muss einen INSERT/UPDATE auf einen VIEW
immer in eine SQL-Abfrage bezogen auf den "normalen" Datenbestand transformieren (
und diese Abfragen werden dann meist noch komplexer).

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

Viele Grüsse

Philipp

[Lude]

Hi,

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

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.

[VIEWS]

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

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.

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.

Gruss,
Lude

[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

[Lude]

Hi, Philipp,

nur eine gnz kurze Antwort, weil die Threadbeitraege schon zu weit rechts stehen. - Ist es Dir schon mal gelungen Geschaeftslogik und Datenzugriffslogik "sauber" zu trennen? btw - Deine Website folgt welcher genauen Geschaeftsidee?

Gruss,
Lude

[Philipp Hasenfratz]

Halihallo Lude

nur eine gnz kurze Antwort, weil die Threadbeitraege schon zu weit rechts stehen. - Ist es Dir schon mal gelungen Geschaeftslogik und Datenzugriffslogik "sauber" zu trennen?

Davon war IMHO gar nicht die Rede, im Gegenteil, diese beiden sollten "verschmelzen".
Die Geschäftsidee gibt die Geschäftslogik und die Datenzugriffslogik vor, beide müssen
miteinander abgestimmt werden und im Optimum redundante Integritätstests haben.
Aber ja, es ist mir gelungen die Geschäftslogik und den Datenzugriff sauber zu trennen,
aber ich weiss nicht, ob wir hier vom selben reden. Kurzes Statement dazu:
GUI-Programm - ObjectControl - Datenbank Abstraktion mit Integritätstests - SQL-
Statement - Datenbank. Die GUI-Programme greifen lediglich auf ObjectControls zu, diese
steuern die "Business Rules", weitergeleitet wird dann an die Datenbank Abstraktion,
welche die SQL-Statements generiert und Integritätstests durchführt und erst dann kommt
die Datenbank zum Zuge. Es ist jedoch so, dass das meiste eben programmtechnisch
Umgesetzt ist, so ist es jedenfalls bei den meisten meiner Projekte.

btw - Deine Website folgt welcher genauen Geschaeftsidee?

admazing.ch meinst du? - Das ist nicht meine, sondern die der Firma :-)
Geschäftsidee ist a) Admanagement für Websites und b) Vermittlung von Internetwerbung
zwischen Websitebetreibern und Advertisern (Werbende). Kurz zusammengefasst.

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo zusammen

Aus "SQL The Complete Reference", s. 292ff

Required data:
Some columns in a database must contain a valid data value in every row; they are not
allowed to contain missing or NULL values. In the sample database, every order must have
an associated customer who placed the oder. Therefore, the CUST column in the ORDERS
table is a required column. The DBMS can be asked to prevent NULL values in this column.

validity checking:
Every column in a database has a domain, a set of data values that are legal for that
column. The sample database uses order numbers that begin at 100,001, so the domain of
the ORDER_NUM column is positive integers greater than 100,000. Similarly, employee
numbers in the EMPL_NUM column must fall within the numeric range of 101 to 999. The
DBMS can be asked to prevent other data values in these columns.

Entity integrity:
The primary key of a table must contain a unique value in each row, which is different
from the values in all other rows. For example, each row of the PRODUCTS table has a
unique set of values in its MFR_ID and PRODUCT_ID columns, which uniquely identifies the
product represented by that row. Duplicate values are illegal, because they wouldn't
allow the database to distinguish one product from another. The DBMS can be asked to
enforce this unique values constraint.

Referential integrity:
A foreign key in a relational database links each row in the child table containing the
foreign key to the row of the parent table containing the matching primary key value. In
the sample database, the value in the REP_OFFICE column of each SALESREPS row links the
salesperson represented by that row to the office where he or she works. The REP_OFFICE
column must contain a valid value from the OFFICE column of the OFFICES table, or the
salesperson will be assigned to an invalid office. The DBMS can be asked to enforce this
foreign key/primary key constraint.

Other data relationships:
The real-world situation modeled by a database will often have additional constraints
that govern the legal data values that may appear in the database. For example, in the
sample database, the sales vice president may want to insure that the quota target for
each office does not exceed the total of the quota targets for the salespeople in that
office. The DBMS can be asked to check modifications to the office and salesperson quota
targets to make sure that their values are constrained in this way.

Business rules:
Updates to a database may be constrained by business rules governing the real-world
transactions that are represented by the updates. For example, the company using the
sample database may have a business rule that forbids accepting an order for which there
is an inadequate product inventory. The DBMS can be asked to check each new row added to
the ORDERS table to make sure that the value in its QTY column does not violate this
business rule.

Consistency:
Many real-world transactions cause multiple updates to a database. For example,
accepting a customer order may involve adding a row to the ORDERS table, increasing the
SALES column in the SALESREPS table for the person who took the order, and increasing
the SALES column in the OFFICES table for the office where that salesperson is assigned.
The INSERT and both UPDATEs must all take place in order for the database to remain in a
consistent, correct state. The DBMS can be asked to enforce this type of consistency
rule or to support applications that implement such rules.

Man möge mir die falschen Interpretationen und Aussagen aufgrund Gedächtnisverlust
verzeihen :-)

Viele Grüsse

Philipp