Domino 9 und frühere Versionen > ND6: Administration & Userprobleme

Grundsätzliche Frage zur DocumentUniqueID und Speicherkonflikten

<< < (4/5) > >>

Semeaphoros:
Richtig, Matthias, dankt der "Unstrukturiertheit" von Notes ist es nicht wirklich möglich, Doclinks zu 100% zu finden. Bei den starren Strukturen von relationalen DBs ist das deutlich einfacher.

Axel: Leider steckt in der UNID mehr drin als nur ein eindeutiger Key. In der API-Doku und im exzellenten Buch von Normunds LS to C-API ( http://www.ls2capi.com ) ist das genauer erklärt.

Marinero Atlántico:
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. 

--- Zitat ---@Marinero:
Und was nützt das im praktischen und gerade besprochenen Umfeld, Axel ?

--- Ende Zitat ---
Nur ein Vergleich auf ein anderes System.

--- Zitat ---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

--- Ende Zitat ---
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:

--- Code: ---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");


--- Ende Code ---
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.

Semeaphoros:
Genau darin liegt ein Problem, dass die UNID Mehrfachnutzen aufweist, ich will das aber nicht als Vorwurf an die Architekten des Systems sehen, das ist historisch gewachsen und als man das System entwarf, waren die Kenntnisse noch nicht so weit gefestigt. Man darf dabei nicht vergessen, dass es für diese Art von Datenhaltung keine Tradition vor Notes gibt, im Gegensatz zur relationalen Datenhaltung.

MrMagoo:
Ui das sind ja viele antworten, danke erstmal

MrMagoo:
so jetzt sieht die welt schon etwas klarer aus, aber leider nur etwas. Das $ref Feld des ersten Konfliktes verweißt auf den zweiten Konflikt. Aber das $ref Feld des zweiten Konfliktes verweißt auf sich selber. Wie ist das möglich?   

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete