[55344] in SAPr3-news
Re: Primärindex vs. Sekundärindex
daemon@ATHENA.MIT.EDU (Christian Knappke)
Wed Aug 31 08:50:14 2005
To: sapr3-news@mit.edu
Date: Wed, 31 Aug 2005 12:30:18 +0000 (UTC)
From: Christian Knappke <chknews@gmx.net>
Message-ID: <Xns96C3938DF62AEHZqjX8Z9@news.sap-ag.de>
From the keyboard of "Sascha Kiefer" <Kiefer.Sascha.Spam@web.de>:
> Hallo,
>
> ich hatte neulich folgende Diskussion:
> Ist es sinnvoller eine Tabelle mit einer GUID als
> Primärschlüssel anzulegen und somit alle semantischen Attribute
> unabhängig vom Schlüssel (und somit z.B. leichter änderbar zu
> machen) und einen Sekundärindex über den "semantischen
> Schlüssel" zu erzeugen, oder ist ein Design, wie es im R/3
> meistens vorkommt einen semantischen Schlüssel (Bsp.
> Materialnummer) zu nehmen besser.
>
> Ein Kollege meinet, der semantische Schlüssel sei performanter,
> da der Zugriff über Primärindizes schneller sei, weil diese
> anders verwaltet werden würden. Ich konnte das eigentlich nicht
> glauben (und nach allem was ich über Oracle weiß ergibt diese
> Aussage IMHO auch keinen Sinn). Die Suche im Netz zu diesem
> Thema war auch nicht sehr ergiebig. Was mich nur irritiert hatte
> war, dass ein anderer Kollege ebenfalls meinte, er hätte im
> Performanckurs mal sowas gehört.
>
> Kann einer von euch darüber eine Aussge machen?
Ich versuch's mal.
Üblicherweise soll der Primärschlüssel (Beispiel MARA:
MANDT+MATNR) auch eine Eindeutigkeit der Schlüsselfelder(-
kombination) über seine UNIQUE-Eigenschaft sicherstellen. Damit
ist hier auf jeden Fall ein unique Index erforderlich, ob jetzt
ein GUID-Feld existiert oder nicht. Außerdem ist ein Datenmodell
nach der Implementierung statisch, so dass das Argument "leichter
änderbar" IMHO nicht zieht.
Bei MaxDB/SAP DB liegt eine Besonderheit in der Architektur vor.
Hier ist nämlich jede Tabelle nach dem Primärschlüssel sortiert
gespeichert (aka Clustered Index). Das bedeutet, dass INSERTs
ggfs. Umsortierungen und Page-Splits erfordern. Das gilt
besonders, wenn der GUID-Algorithmus gleichverteilte und keine
stetig aufsteigenden Werte liefert. Bei Masseninserts können dann
Performanceprobleme auftreten. Vielleicht meinte der Kollege das?
Bei DBMSen, die INSERTs einfach hinten anhängen, spielt das
natürlich keine Rolle. Auch sind die Pimärschlüssel den
Sekundärindizes in keiner Weise bevorrechtigt, abgesehen von
semantischen Überlegungen.
Ebenso könnte bei MaxDB/SAP DB die Tabelle ohne Primärschlüssel
angelegt werden, dann wird für die Tabelle ein interner
Primärschlüssel (SYSKEY, 64 bit INT) generiert, der für jedes
INSERT einfach hochgezählt wird. Ein semantischer
"Primärschlüssel" ist dann einfach ein (unique) Sekundärindex.
HTH
Christian
--
#include <std_disclaimer.h>
/* The opinions stated above are my own and not
necessarily those of my employer. */
Das Musical-Projekt zum Mitmachen: http://www.mitmachmusical.de/
