Ich hab an die anderen Bereiche, wo Domino die UniversalID benutzt nicht gedacht.
Ja klar.
Lotus hätte für solche weiteren, mehr Anwendungs-Service-orientierten (oh was ein Wort
) Features besser eine zweite, universell eindeutige ID verwenden sollen, isn't it? Ist ja einfach nur ein Algorythmus.
@Marinero:
Und was nützt das im praktischen und gerade besprochenen Umfeld, Axel ?
Nur ein Vergleich auf ein anderes System.
ABC GmbH, 1230 Testhausen, Goethestrasse 4
bekommst Du einen separaten Primary Key wie auch für
ABC AG, 1234 Testhausen / Gewerbegebiet, Goethe-Strasse 4-25
Nicht ganz klar, ob du das meinst, aber man kann auf Datenbank-Definitionsebene "natürliche" Eindeutigkeits-Constraints einbauen.
Unter der Annahme, das Namen von Firmen eindeutig sind, kann man das auf der Ebene der Datenbank abfangen. (S. unique Constraint)
Falls das jemand diskutieren will, können wir das in einen neuen Thread umpacken.
Vorschlag:
CREATE TABLE Customer (
ID BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1, NO CACHE ),
name VARCHAR(50),
plz char(5),
city varchar(50),
street varchar (80)
);
CREATE UNIQUE INDEX "i_Cust_Name" ON Customer (name);
ALTER TABLE Customer ADD CONSTRAINT "PKEY_USER" PRIMARY KEY ("ID");
Btw. sehe ich starke Parallelen zu der oben geführte Debatte zu UniversalID.
Leute, die das als Best Practice vorschlagen, sagen dass der Primary Key 1 und nur genau 1 Aufgabe hat und genau dafür optimiert werden soll.
Aufgabe: Eindeutigkeit.
Eigenschaften: Performance (als Datentyp ist LongInt für selects, joins, etc. am schnellsten).
Andere Aufgaben packt man nicht da rein.
Dafür nimmt man andere Elemente.
Beispiel: Für die "natürliche" Eindeutigkeit belegt man sogenannte "natural keys" mit einem Unique Constraint.
Thema: Grundsätzliche Frage zur DocumentUniqueID und Speicherkonflikten (Gelesen 6507 mal)