Acties:
  • 0 Henk 'm!

  • michelvosje
  • Registratie: December 2009
  • Laatst online: 13-07 16:25
Hallo Tweakers.

Voor een project op school moeten wij een database ontwerpen in SQL Server 2012. Een onderdeel van het project om te onderzoeken hoe de database geoptimaliseerd kan worden. Zo hebben we ook les gehad in HEAP + HASH + ISAM en B-Tree. Het principe van de werking daarvan is nu wel bekend bij ons. Dit wilden we dan ook toe kunnen passen op de database, maar het probleem is nu dat we er niet uit kom hoe je dit doet.

Op MSDN heb ik al een aantal pagina's zitten door kijken en via google ook. Maar het lijkt er op dat het alleen maar gedaan kan worden door een combinatie te maken van clustered en nonclustered indexes? Bijv. deze pagina: Klik
Daar wordt wel een heleboel heel leuk uitgelegd. Maar ik snap er geen snars van.

Wie o wie kan ons verder helpen?

michelvosje

Edit:
Heb het al gevonden.

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
michelvosje schreef op vrijdag 15 juni 2012 @ 16:55:
Daar wordt wel een heleboel heel leuk uitgelegd. Maar ik snap er geen snars van.
Het helpt als je aangeeft wat je dan precies niet snapt. Ik vind het verhaal waar je naar linkt overigens best duidelijk.
Het is fijn als je je oplossing ook even post; zie onze faq betreffende topiceinde ;)

Even los van dit alles: het is vast een hele leuke academische oefening, maar een SQL server gebruik je juist om dit soort geneuzel over bits/bytes/meest efficiënte manier van opslag en whatnot uit handen te geven en over te laten aan mensen die hier (vele malen) beter in zijn dan jij. Hiermee zeg ik zeker niet dat 't nutteloze informatie is, en het is leuk wat internals te kennen, maar onthou goed dat dit soort implementatiedetails juist geabstraheerd worden voor je zodat jij je daar niet over hoeft te bekommeren. En belangrijker: dat ze bij een volgende implementatie/versie compleet verschilllend kunnen zijn. Juist omdat dit soort dingen wordt weggeabstraheerd boeit het niet en is 't zelfs "levensgevaarlijk" om te vertrouwen op informatie die is afgeleid uit observaties en er van uit te gaan "dat het zo is". Het is nu, op het moment van observatie, zo, maar het kan elk moment (nieuwe versie, bepaalde 'threshold' bij hoeveelheid data, het syteem besluit dat de I/O seek traag is dus beter voor methode Y kan worden gekozen t.o.v. X, en ga zo maar door) veranderen. Het zijn dan ook niet voor niets "internals" ;)

En, ja, om een goede keuze te maken voor een bepaald type index e.d. is het zéker goed als je wat kennis hebt over de verschillen en weet wat er "min-of-meer" achter de schermen gebeurt. Het artikel waar je naar linkt gaat daar, IMHO, voor "normaal" / "doorsnee" (ja, wat is normaal...) gebruik echter wat te diep op in.

[ Voor 9% gewijzigd door RobIII op 16-06-2012 02:00 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • michelvosje
  • Registratie: December 2009
  • Laatst online: 13-07 16:25
Ja sorrie had tijdens het plaatsen van het bericht weinig tijd. Maar ik had dus gisteravond deze conclusies getrokken:

Clustered Tables, Heaps and Indexes
Bij een B-tree zou een tabel een clustered index moeten hebben.
En voor een HEAP mag er geen clustered index zijn

Clustered Index Structures
Waarschijnlijk ISAM omdat:
- Data rows niet gesorteerd zijn opgeslagen op basis van hun primary sleutels
- Alleen index pages en geen data pages zoals bij de leaf pages van B-tree (?)

Partitioning
En ik kwam op internet ook iets tegen over partitionering. Ze gooiden een formule over de primary sleutel, waardoor een gelijkmatige verdeling gemaakt kon worden over de partities. Lijkt dat daardoor dat de records op basis van die HASH opgeslagen worden op de partities.

Verder vind ik het wel weer vreemd dat de termen HASH en ISAM niet echt gebruikt worden op msndn?

Acties:
  • 0 Henk 'm!

  • HeSitated
  • Registratie: April 2009
  • Laatst online: 03-12-2024
michelvosje schreef op zaterdag 16 juni 2012 @ 16:30:
Partitioning
En ik kwam op internet ook iets tegen over partitionering. Ze gooiden een formule over de primary sleutel, waardoor een gelijkmatige verdeling gemaakt kon worden over de partities. Lijkt dat daardoor dat de records op basis van die HASH opgeslagen worden op de partities.
Partitioning heeft niets met B-Tree o.i.d. te maken. Partioning verdeeld alleen de fysieke opslag in meerdere segmenten. Bijvoorbeeld alle orders van jaar 2010 (en ouder) in FileA, jaar 2011 in FileB en 2012 in FileC.
Verder vind ik het wel weer vreemd dat de termen HASH en ISAM niet echt gebruikt worden op msndn?
Omdat zoals RobIII al zegt, het overgrote deel van de dba-ers en al helemaal developers interesseert het geen donder hoe het is opgeslagen, laat SQL Server lekker z'n ding doen en maak daar gebruik van.

Acties:
  • 0 Henk 'm!

  • Remus
  • Registratie: Juli 2000
  • Laatst online: 15-08-2021
michelvosje schreef op zaterdag 16 juni 2012 @ 16:30:
Verder vind ik het wel weer vreemd dat de termen HASH en ISAM niet echt gebruikt worden op msndn?
Waarschijnlijk omdat dat helemaal niet gebruikt wordt in SQL Server. Dat geldt iig voor ISAM (wat een fixed length encoded opslag van data is). Ik weet niet wat je hier met HASH bedoeld (hashing heeft nl nog al wat verschillende toepassingen), dus daar kan ik verder niets over zeggen.