Schnelle Bestimmung der Anzahl von Datensätzen in Tabelle

[Robert_G]

Ich bin generell der Meinung, dass ein PK IMMER numerisch und IMMER keinerlei Bezug zu den Informationen in der Tabelle haben sollte. (Also die gute alte Sequence.NextVal-Geschichte. ).
Dein Problem ist nämlich, dass Ora bei einem SELECT Count(*) bzw. SELECT Count(PK) versucht einfach die Anzahl der verknüpften RowIds am Index des PKs auszugeben.
Indizes sind in Ora eigentlich "nur" nested tables, deshalb könnte er wortwörtlich die Count Methode der Index collection aufrufen (PK heißt ja eine Rowid pro Index wert ).

Bei so vielen Datensätzen solltest du die Tabelle am besten auch noch partitionieren (nach Projektnmmer, Hersteller, whatever,...).
Auf die Art würden Abfragen innerhalb eines Projektes, Herstellers, whatever,... so schnell laufen als gäbe es nur diese Datensätze.

[Bernhard Geyer]

Zitat von Robert_G:

Ich bin generell der Meinung, dass ein PK IMMER numerisch und IMMER keinerlei Bezug zu den Informationen in der Tabelle haben sollte. (Also die gute alte Sequence.NextVal-Geschichte. ).

Umstellen geht aufgrund von 3 Gründen nicht:
1, große Installierte Basis
2, PK-Schlüssel sind reale Eindeutige Nummern (z.B. Materialnummern mit Versionen bzw. Mandantennummern)
3, Installierte Daten mittels "Differnz-Update" aktualisiert werden müssen, auch wenn in der Ursprungsdatenbank evtl. Primärschlüsseleinträge zwischenzeitlich gelöscht wurden.

Zitat von Robert_G:

Dein Problem ist nämlich, dass Ora bei einem SELECT Count(*) bzw. SELECT Count(PK) versucht einfach die Anzahl der verknüpften RowIds am Index des PKs auszugeben.

Für M$ SQL-Server wurde diese Info (Anzahl Datensätze in Tabelle) noch in einer Systemtabelle gehalten. Für Oracle gibt es scheinbar sowas nur (aktuell) wenn eine spezieller Statistikdurchlauf gelaufen ist.

Zitat von Robert_G:

Bei so vielen Datensätzen solltest du die Tabelle am besten auch noch partitionieren (nach Projektnmmer, Hersteller, whatever,...).
Auf die Art würden Abfragen innerhalb eines Projektes, Herstellers, whatever,... so schnell laufen als gäbe es nur diese Datensätze.

Das wird hoffentlich von den Oracle-Admins auch durchgeführt. Selbst kann ich das in der Anwendung nicht vorsehen, da ich ja nicht weiß wie "schmal" oder "breit" die Daten ankommen und welche Partitionierung optimal wäre.

[mschaefer]

Moin, Spätmoin,

tja also hier muß ich Robert mal deutlich zustimmen. Der Primärindex sollte nichts mit den Daten zu tun haben, auch wenn die Materialnummern eindeutig sind. Hintergrund ist die wesentlich schnellere Einsortierung und vor allem indexierte-Suche. Und genau hier liegt Dein Problem! Bei einem Zähler kann das DBMS mit Suchstrategien (z.B: Bisektionsverfahren/Newtonverfahren, usw...) auf die Datensätze zugreifen. Zudem hat das DBMS nur den Integer-Ausdruck und nicht den Stringausdruck auszuwerten. Was definitiv schneller ist.

FAZIT: Besser ein eindeutiges Integerfeld als Prmärindex zusätzlich, als ein Stringindex.
Das ist sicherlich auch unabhängig vom DBMS.

Grüße // Martin

[Bernhard Geyer]

Zitat von mschaefer:

tja also hier muß ich Robert mal deutlich zustimmen. Der Primärindex sollte nichts mit den Daten zu tun haben, auch wenn die Materialnummern eindeutig sind. Hintergrund ist die wesentlich schnellere Einsortierung und vor allem indexierte-Suche. Und genau hier liegt Dein Problem! Bei einem Zähler kann das DBMS mit Suchstrategien (z.B: Bisektionsverfahren/Newtonverfahren, usw...) auf die Datensätze zugreifen. Zudem hat das DBMS nur den Integer-Ausdruck und nicht den Stringausdruck auszuwerten. Was definitiv schneller ist.

FAZIT: Besser ein eindeutiges Integerfeld als Prmärindex zusätzlich, als ein Stringindex.
Das ist sicherlich auch unabhängig vom DBMS.

Das mag schon stimmen das die DBMS mit Integerwerten schneller zurecht kommen. Aber das Programm wird definitiv umgestellt, da es schon ziemlich groß ist (1 Mio. Quellzeilen mit Fremkomponenten) als auch schon so weit optimiert ist, das alle anderen Aktionen so weit SQL-Technisch (Primärschlüssel z.B. als Clustered Index, zusätzliche Indexe, SQL-Queries, ...) optimiert sind das auch bei 4 Mio. Datensätze immer akzeptable Antwortzeiten vorhanden sind.

Ich versteh jedoch nicht das für dieses simple Bestimmung der Anzahl der Datensätze es relevant sein soll welchen Datentyp der Primärschlüssel hat. Bei MS-SQL Server kann ich mittels

SQL-Code:

SELECT Max(idx.rows) FROM dbo.sysindexes as idx inner join dbo.sysobjects as obj on idx.id = obj.id
WHERE ( obj.name = 'Table1')

praktisch ohne Wartezeit die Anzahl der Records einer Tabelle bestimmen. Und dies sollte auch bei Oracle und MySQL möglich sein.

Meine Testdatenbank konnte ich noch nicht aktualisieren, da beim Import heute auf dem Testrechner die Festplatte vollgelaufen ist.