Office: Primärschlüssel in jeder Tabelle zwingend?

Code:

Das stimmt und daher ist es egal ob der surrogate key eine GUID ist oder ein aufsteigender Wert ohne 'Lücken'
http://www.hs-augsburg.de/~mweiss/ap...e.shower2.html

 

Ich hätte angenommen, dass beim Clustered Index weniger Seiten-Verschiebungen auftreten.

 

"Verschiebungen" kannst Du bedingt mit der Eigenschaft PadIndex und FillFactor des Indexes verhindern.

Die Füllfaktoroption wird zur erweiterten Leistungsoptimierung beim Speichern von Indexdaten bereitgestellt. Wenn ein Index
erstellt oder neu erstellt wird, bestimmt der Füllfaktorwert den Speicherplatzanteil, der auf jeder Blattebenenseite mit Daten gefüllt werden
soll, und damit, wieviel Speicherplatz für zukünftige Vergrößerungen reserviert werden soll. Wenn Sie beispielsweise einen Füllfaktorwert von 80 angeben, bedeutet dies, dass 20 Prozent jeder Seite auf der Blattebene leer gelassen werden, um Speicherplatz für zukünftige Indexerweiterungen bereitzustellen, während der zugrunde liegenden Tabelle Daten hinzugefügt werden.

Der Wert des Füllfaktors ist ein Prozentsatz von 1 bis 100. Der serverweite Standardwert von 0 ist jedoch in den meisten Situationen der
am besten geeignete Wert. Wenn der Füllfaktor auf 0 festgelegt wird, wird die Blattebene vollständig aufgefüllt.

Wenn einer vollen Indexseite eine neue Zeile hinzugefügt wird, verschiebt Datenbankmodul ungefähr die Hälfte der Zeilen auf eine neue
Seite, um Platz für die neue Zeile bereitzustellen. Diese Neuorganisation wird auch Seitenteilung genannt. Eine Seitenteilung schafft Platz
für neue Datensätze, beansprucht jedoch Zeit und Ressourcen. Seitenteilungen können auch Fragmentierungen verursachen, die zu
vermehrten E/A-Vorgängen führen. Mit einem richtig ausgewählten Füllfaktor kann das Risiko von Seitenteilungen verringert werden, indem genug Speicherplatz für Indexerweiterungen bereitgestellt wird, während der dem Index zugrunde liegenden Tabelle Daten hinzugefügt werden.

Bei häufigen Seitenteilungen kann der Index neu erstellt und dabei ein neuer oder bereits vorhandener Füllfaktor verwendet werden, um die
Daten neu zu verteilen. Weitere Informationen finden Sie unter Neuorganisieren und Neuerstellen von Indizes.

Ein niedriger Füllfaktor (über 0) kann zwar beim Vergrößern des Indexes die Seitenteilung reduzieren; der Index erfordert dann jedoch mehr
Speicherplatz, was die Leseleistung verringern kann. Sogar im Fall einer Anwendung, die sehr viele Einfügungen und Aktualisierungen
vornimmt, treten Datenbanklesevorgänge in der Regel fünf- bis zehnmal häufiger auf als Schreibvorgänge in der Datenbank. Aus diesem
Grund kann das Ändern des Standardfüllfaktors die Leistung von Datenbanklesevorgängen in einem Umfang mindern, der umgekehrt
proportional zur Füllfaktoreinstellung ist. Ein Füllfaktorwert von 50 Prozent kann z. B. dazu führen, dass die Dauer von Datenbanklesevorgängen verdoppelt wird. Die Leseleistung verringert sich, weil der Index eine größere Anzahl an Seiten enthält und daher
die zum Abrufen der Daten erforderlichen Datenträger-E/A-Vorgänge zunehmen.


ABER :

Die Füllfaktoreinstellung wird nur verwendet, wenn der Index erstellt oder neu erstellt wird. SQL Server 2005 Database Engine
(Datenbankmodul) hält den angegebenen Prozentsatz des Speicherplatzes nicht dynamisch auf den Seiten frei. Das Aufrechterhalten des
zusätzlichen Speicherplatzes auf den Datenseiten würde dem Zweck der ursprünglichen Implementierung des Füllfaktors zuwiderlaufen, da
Datenbankmodul Seitenteilungen vornehmen müsste, um den Prozentsatz des freien Speicherplatzes, der durch den Füllfaktor angegeben
wird, weiterhin beizubehalten, wenn Daten eingegeben werden.

Daher auch eine Reindexierung über einen DB - Wartungs Job der bsp. wöchentlich läuft.

 

\@Strausto:
Den Link zum Treebalancer habe ich gespeichert. Erklärt mehr als 1000 Worte. Thx!

*happy

 

Wie funktioniert das bei Jet?

 

\@Josef:

gar nicht. Jet gibt das nicht her.

Aber wenns so dicke kommt, ist eh ein richtiges RDBMS gefragt.

HTH

 

In Jet gibt es auch keinen Clustered Index....

 

Nur eins verstehe ich grundsätzlich nicht!
Warum nutzen hier eigentlich wenig Entwickler die MSDE als Backend für Access?
Die Vorteile überwiegen in meinen Augen ....
Access ist ja keine echte Datenbank die MSDE schon.

 

Ich vermute mal, die MSDE ist einfach zu unbekannt und gegenüber dem echten Sqlserver zu beschränkt.

 

Doch. Der PK ist automatisch der custered index.

[OT]

Ich glaube du hast meine "Frage" falsch verstanden. Damit wollte ich nur darauf hinweisen, dass nicht alles mit Jet möglich ist - der Ausgangspunkt dieses Threads war meiner Meinung nach eine Jet-DB.

zur MSDE bzw. SQL-Express:
Das kann ich auch nur empfehlen - nutzte sogar selbst überhaupt keine Jet-DB (Ausnahme: lokale Temp-DB), da mir die Datensicherheit (vor allem die Ausfallsicherheit) zu niedrig ist.

Ich stelle aber immer wieder fest, dass Jet-Datenbanken sehr oft eingesetzt werden, wenn sich jemand mal "schnell eine DB zusammenbastelt", die IT aber kein System zur Verfügung stellen will. (oftmals auch zurecht, da heterogene Systeme aus meiner Sicht nicht besonders klug sind) ... wenn das dann aber mittels Jet-Db umgangen wird, ist das noch "unklüger". *Smilie

... darauf basiert meiner Meinung nach auch der "schlechte Ruf" von Access unter vielen "Nicht-Kennern", da Access nicht als Entwicklungsumgebung sondern als DB-System angesehen wird.

Die MSDE (Mini-SQL2000-Server) würde ich auch nicht mehr einsetzen.
Der SQL-Express (2005) ist aber um einige näher am "richtigen" SQL-Server.
siehe: http://www.microsoft.com/germany/sql...n/default.mspx

 

Ich denke das liegt daran, weil man es anfänglich gar nicht kennt. Oder auch weil wieder ein paar Fallstricke mehr liegen und das Handling mit einer MDB-Backend anfänglich einfacher ist. Zusätzlich gibts in den Foren massig Probleme mit ODBC und ähnlichem. Rückspielung einer DB ist das kopieren einer einzigen Datei. Backup erstellen ebenso. Man muss diese wie in SQL-Express nicht erst abhängen, sichern, wieder neu starten usw. (Bei MSDE aber glaub auch ned oder?)

Auch lassen sich die Tabellen, Designänderungen so in einer Software machen, erst noch mit einer GUI, die fast keine Kenntnisse benötigt (so scheint es zumindest, auch wenn die Wahrheit anders ist).
Zusätzlich war es, früher zumindest, in den Datenbanken nicht so easy wie in Access mit GUI die Tabellen zu erstellen, verknüpfen usw. Mit der aktuellen SQL-Express mit Visual Studio jedoch auch ein Kinderspiel.

Denke damit das ein Anfänger auch von Anfang an in Angriff nimmt, müsste dazu eine einfache Anleitung existieren. Später, wenn er mehr Anhnung hat, ist das Programm zu aufwendig um einfach so mal eben umzustellen. Das geht mir leider genauso. Der einzige Grund warum ich noch eine MDB als Backend verwende für unsere Hauptanwendung in der Produktion, hat sich einfach mit den Jahren so ergeben.

 

Code:

Ist das in Jet wirklich so?
Code:

Gegenüber dem SQL Server ja - aber im Vergleich zur JetEngine doch deutlich überlegen!
Code:

Das stimmt natürlich!

 

Ist das in Jet wirklich so?

Ich kenne mich selbst mit Jet nicht besonders gut aus, da ich ein Freund von aktiven DBMS bin. Ich vertraue hier auf Michael Zimmermann, der sich damit für einen AEK-Vortrag detaillierter auseinandersetzte.
Details: AEK8-Skript "Performance in Abfragen" von Michael Zimmermann. (im AEK-Downloadbereich von www.donkarl.com)

 

Mal angenommen ich würde gerne mal testen wollen, ob ich mit einem Express SQL Server "vertehe":

Was brauche ich genau, um über GUI meine Tabellen zu verknüpfen und zu erstellen. Visual Studio...... ?*frown.gif*

Oder geht soetwas auch mit dem kostenlosen DBDesigner?

 

Dafür gibt es das "SQL Server Management Studio Express".
Damit kannst du Datenbanken erstellen, Tabellen per GUI erstellen oder auch SQL-Anweisungen als Text schreiben und ausführen ... eben alles was das Herz eines Dantenbänkler begehrt.