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.