Citace Původně odeslal Marty Zobrazit příspěvek
Ono jak tak koukám nejsou clusterovaný indexy nikde, což je dost na nic - minimálně zavedením clusterovanýho indexu snížíš počet fyzických IO operací při čtení o 1, a to je při tabulce do 8 mld záznamů z 4 na 3, při <4 mil. záznamů pak z 3 na 2 !

BTW bacha na to, všespásný to není - negeneruj clusterovaný indexy nad blbejma typama sloupců. Ideální je to mít nad int / auto increment, což v případě cislo_subjektu popř. cislo_objektu nad např. lcs.sk_polozka je - sice asi aplikační logikou, ale to není v zásadě podstatný. V opačným případě dochází k page splitům v indexu a nutnosti přeorganizovat celej index při insertu hodnoty, která není na konci již existujících hodnot v klíči indexu.
Ano, z vlastní zkušenosti souhlasím, je to obecný problém architektury tříd v Helios Green. Helios Green používá "posun do META", kdy všechny hlavičkové záznamy v jsou subjekty, tím získává datový návrh značně na flexibilitě, ale klesá také silně výkonnost databázového stroje. Pokud tabulky jako subjekty nebo sk_polozka narostou do desetimilionovych řádů, pak dochází k vzájemné blokaci uživatelů při určitých operacích, pracujícíh s větší množinou záznamů. Je vcelku jedno, jestli uživatelů je 100 nebo 5, blokuje se tabulka subjekty a treba take sk_polozka a vyrobce na to ma specialni udelatko, kterym blokovani presahujic rozumny cas odstreluje, jinak je treba restart SQL Serveru.
Řëšením by měla být dle mého názoru archivace záznamů do archivní databáze. Pro opravdu veliké projekty, kde vznikají miliony záznamů skladových pohybů relativně rychle, se myslím Helios Green nehodí, pro střední firmu ale je OK.