Frage zu 70-431 (OMT)

[nightflight71 10]

Hallo liebe SQL Gemeinde,

 

beim durcharbeiten des OMT zu 431 sind mir ja schon einige ärgerliche Syntaxfehler in den Beispiel-Codes im Buch aufgefallen, aber was ich gerade eben in Kapitel 4 gefunden habe, bringt mich doch etwas durcheinander.

 

Seite 145:

Wichtig: Physische Anordnung

Es wird oft fälschlicherweise angenommen, ein gruppierter Index führe zu einer physischen Sortierung der Tabellendaten. Das stimmt so nicht. Ein gruppierter Index führt dazu, dass die Zeilen der Tabelle und die Datenseiten in der doppelt verknüpften Liste, in der alle Tabellendaten gespeichert sind, anhand des Gruppenschlüssels geordnet werden. Dabei handelt es sich jedoch um eine logische Anordnung. DieTabellenzeilen können überall auf den physischen Plattenebenen abgelegt sein. Würde ein gruppierter Index eine physische Sortierung der Daten auf dem Datenträger bewirken, käme es zu Plattenzugriffen in untragbarem Umfang.

 

So weit so gut, das klingt ja auch nachvollziehbar, jetzt kommt jenes was mich völlig von den Socken haut.

 

Seite 150:

 

Lernzielkontrolle

1. Welche Art von Index ordnet die Zeilen einer Tabelle physisch?

 

a. Der eindeutige Index

b. Der gruppierte Index

c. Der nicht gruppierte Index

d. Der Fremdschlüssel

 

Seite 832:

Anworten - Richtige Antwort: b

Ein gruppierter Index bewirkt eine physische Reihenfolge der Zeilen in der Tabelle aufgrund der Indexdefinition :shock:

 

:confused: Was denn nun? Haben da mehrere Autoren aneinander vorbei geschrieben, oder bin ich zu **** zum Lesen?

 

Gruß Torsten

[Oppossum 10]

Hi,

 

Du liegst definitiv richtig. Ich mache gerade auch die 70-431 und bin genauso verwirrt. Ganz offensichtlich handelt es sich um einen Flüchtigkeitsfehler, der nicht bemerkt oder berichtigt wurde. Interessant wird sein, ob es im englischen Original genauso falsch ist. Ich bin demnächst schlauer, wenn ich das englische Corepack zum MCITP erhalte. (70-431, 70-440, 70-441 sind enthalten 140€ bei MSPress Versand)

 

Gruß

Das Oppossum

[patrick210778 10]

Ein gruppierter Index bewirkt eine physische Reihenfolge der Zeilen in der Tabelle aufgrund der Indexdefinition :shock:

 

 

Ich bin kein SQL Spezialist, allerdings ist diese Erklärung für mich plausible, ein Index wird garantiert Physisch geschrieben… entweder auf die Platte oder in den RAM je nach Datenbank Model!

In meiner Buchstabensalat Datenbank habe ich über eine Milliondatensätze gespeichert. Und schnelle Treffer sind nur mit einer Indizierung zu erreichen. Darüber hinaus wird durch das setzten eines Index auf eine Spalte die Datenbank signifikant größer! Also müssen die Daten Psychisch geschrieben werden, würde sonst ja auch keinen Sinn ergeben, weil die Daten nun mal indiziert werden müssen um schnell wieder gefunden werden zu können. Und dieser Index verbraucht Speicherplatz, hat allerdings den Vorteil dass jetzt nicht mehr die ganze Datenbank abgefragt werden muss. Wie die Indizierung im Detail genau funktioniert weiß ich nicht, es wird wahrscheinlich das Prinzip des Patriziabaums angewendet.

 

Zumindest ist das bei MySQL so ;-) sollte sich von MS vom Prinzip her aber nicht unterscheiden.

 

Gruß

 

EDIT: Hups habe etwas zu schnell gedacht... ein gruppierter Index ist ja was spezielles. :rolleyes: Habe das gruppierte ganz überlesen, weil ein Index allgemein eine Gruppierung darstellt. Ich meine natürlich das ganz triviale setzen eines Index benötigt selbstverständlich Plattenplatz.

[Oppossum 10]

Hi Gemeinde,

 

ganz offensichtlich hat das Buch zur 70-431 noch einige Fehler, oder ich interpretiere folgenden SQL Code falsch. Es ist ein Beispiel aus Kapitel 2 Seite 77 ff des 70-431 SQL Buches von MSPress zum MCTS für SQL 2005.:

 

Wir erstellen einen User "Peter" mit dem Passwort "Pa$$w0rd". Er soll auf das Objekt "Employee" in "HumanResources" Zugriff erhalten.

 

CREATE LOGIN Peter WITH PASSWORD='Pa$$w0rd'

GO

USE AdventureWorks

GO

CREATE USER Peter FROM LOGIN Peter

 

...soweit so gut nun noch die Berechtigung SELECT für HumanResources

 

GRANT SELECT ON SCHEMA :: [HumanResources] TO [Peter]

 

...dann eine neue Abfrage und die Verbindung auf SQL Server Anmeldung ändern und mit "Peter" und "Pa$$w0rd" anmelden...

 

Wenn man nun mit:

 

USE AdventureWorks

GO

SELECT * FROM Employee

 

testet, ob Peter Zugriff auf "Employee" in HumanResources hat, muss das Ergebnis negativ sein, da Peter nicht die erforderliche Berechtigung hat, um auf "Employee" zuzugreifen.

 

Also eine neue Abfrage, um Peter diese Berechtigung zu geben:

 

ALTER USER Peter WITH DEFAULT_SCHEMA=HumanResources

 

Wenn man jetzt die Abfrage von oben wiederholt müsste es eigentlich laufen, tut es aber nicht. Bin ich **** oder was geht? Codemäßig müsste die Sache laufen als Fehlermeldung kommt trotzdem immer nur:

 

Meldung 208, Ebene 16, Status 1, Zeile 1

Ungültiger Objektname 'Employee'.

 

Offensichtlich wird das Objekt "Employee" nicht gefunden und das obwohl alle vorherigen Abfragen ohne murren und fehlerfrei ablaufen. Hat jemand eine Idee? Ach ja ich habe den SQL Server 2005 Enterprise unter Server 2003 Enterprise laufen, jeweils auf dem neusten Patchlevel.

 

Für Ideen bin ich immer dankbar!

 

Gruß

Das Oppossum

[nightflight71 10]

also die Sache mit dem User Peter läuft bei mir, ich vermute da ist mit der Berechtigung bei dir etwas falsch gelaufen.

 

Schmeiss den nochmal raus und trage ihn erneut ein

[Oppossum 10]

Hi zusammen,

 

manchmal hilft es auch einfach mal die Kiste auszumachen, Rotwein zu trinken und es am nächsten Tag noch einmal zu versuchen. Ich habs so gemacht und nun ein richtiges Abfrageergebnis bekommen. Offensichtlich muss irgendwo in der Syntax ein Tippfehler gewesen sein. Man ist halt nicht perfekt.........;)

 

Gruß vom Oppossum