Ich verstehe nicht, was Du an meiner Aussage kritisierst und wieso Du diese Bemerkungen von Dir gibst...
Schlüssel sind per definitionem eindeutig. Ob Du das als Anwender mitbekommst, oder nicht, ist für die Definition unerheblich. Im Übrigen ist es auch unerheblich, ob bei einem Index die RecID nun explizit oder implizit mit angegeben ist. Implizit ("Clustered Index" heisst das bei
MSSQL) bedeutet hier z.B., das die gesammte Tabelle ('Datenmenge') anhand eines Index sortiert abgelegt ist. Dann kannst Du auf Binärbebene suchen bis der Arzt kommt, ein Tupel (Key/RecID) wirst du natürlich so nicht finden, aber da die RecID des Key im Index = RecID des Datensatzes ist, haben wir wieder die Zuordnung. Und auch wenn dieser Index (=Schlüssel) für sich gesehen nicht eindeutig ist, ist die Kombination (Schlüssel-RecordID) natürlich eindeutig.
Wenn Du den B-Baum (oder welche Struktur auch immer Du meinst) auf Binärebene kennst, und dann keine (logische?) Zuordnung zum Datensatz siehst, dann erkläre mir bitte, wie die
DB-Engine beim Suchen nach dem 'Sekundärindex' "Müller" auf die Datensätze 1234, 5678 und 98765 kommt? Wie schafft sie das nur?
Dessenungeachtet benötigt nun mal jede
DB eine total Ordnung ("gleich" gibts nicht) auf den Schlüsseln, ja selbst auf den Datensätzen selbst.
SQL macht hier natürlich auf der User-Seite (DQL, DML) mit Absicht nicht mit, weil eine Datenmenge (auch 'per definitionem') keine Ordnung aufweist. Intern haben die Datensätze logischerweise eine Record-ID, bei
IB/
FB z.B. gibt es dafür sogar irgendso eine "$xxx" Krücke.
Gerade weil (und nur weil) die Schlüssel (Fremd-, 'Sekundär'(wo ist die Def.?), Komposite, Kandidaten-) eindeutig sind, funktionieren Datenbankapplikationen überhaupt, auch die aus den 80er Jahren.
So... und nun zum Kleinkram...
Zitat von
Reinhard Kern:
das mag eine (für dich) wünschenwerte Theorie sein, das, was ich beschrieben habe, ist aber Realität und seit mehr als 20 Jahren so problemlos in der Industrie im Einsatz:
Es ist für mich keine wünschenswerte Theorie, sondern Realität, das Schlüssel eindeutig sind. Immer und überall. Soweit ich weiss, sogar seit bald 40 Jahren (1970, Codd)
Zitat von
Reinhard Kern:
2. Eine Folge davon ist, dass die Tabelle AbteilungMitglieder überhaupt nicht gebraucht wird. Ein (nicht eindeutiger) Index über die Spalte Abteilung in der Tabelle Mitglieder liefert das Gewünschte.
Aber wie stellst Du dann dar, das Müller in Abteilung X und gleichzeitig in Abteilung Y ist (m:n)?
Zitat von
Reinhard Kern:
Das mag nach
Paradox klingen (wäre das eine Schande?),
Ja.
, aber ich meinte eher, das ich den Terminus "Sekundärindex" so nicht kenne, sondern nur in Verbindung mit
Paradox. Und deswegen klingt
mir das eben zusehr nach
Paradox.
Zitat von
Reinhard Kern:
gilt aber für die meisten Datenbanken der 80iger Jahre. Deine Behauptung, das wäre alles funktionsunfähig...
Wo hab ich das gemacht? Finde ich nicht.
Zitat von
Reinhard Kern:
...Wenn du nur sagen willst, der grösste Teil der heute existierenden Software wäre deiner Meinung nach falsch programmiert, damit könnte man leben.
Eine Studie (USA, wo sonst) bescheinigt 60% aller laufenden C/S
DB-Applikationen eine den Grundregeln (1-3 Semester) des
DB-Designs widersprechende Architektur. Man muss damit leben, aber wohl ist mir dabei nicht. Das ist aber nicht die Aussage meines Posts...
Abschließend sei noch Eins gesagt: "Schlüssel" können aus der Anwendersicht natürlich mehrdeutig sein (Deine Behauptung), sie sind es aber aus
DB-Sicht nicht (meine Behauptung). Da ist kein Widerspruch drin, sondern jeweils nur eine Erweiterung Deiner/Meiner Definition.