Tabele bez klucza podstawowego

Mając do czynienia z indeksami, musisz określić, do czego będzie używana twoja tabela. Jeśli najpierw wstawiasz 1000 wierszy na sekundę i nie wykonujesz żadnych zapytań, to klastrowy indeks jest uderzeniem W wydajność. Jeśli wykonujesz 1000 zapytań na sekundę, Brak Indeksu doprowadzi do bardzo złej wydajności. Najlepszą rzeczą do zrobienia podczas próby dostrojenia zapytań/indeksów jest użycie analizatora planu zapytań i SQL profilera w SQL Server. To pokaże ci, gdzie jesteś uruchomiony w kosztowne skanowanie tabeli lub inne blokery wydajności.

Jeśli chodzi o argument GUID vs ID, w sieci można znaleźć ludzi, którzy przeklinają oba. Zawsze uczono mnie używać GUIDs, chyba że mam naprawdę dobry powód, żeby tego nie robić. Jeff ma dobry post, który mówi o powodach używania GUID: https://blog.codinghorror.com/primary-keys-ids-versus-guids/.

Jak w przypadku większości rzeczy związanych z rozwojem, jeśli chcesz poprawić wydajność, nie ma jednej, jednej właściwej odpowiedzi. To naprawdę zależy od tego, co próbujesz osiągnąć i jak wdrażasz rozwiązanie. Jedyną prawdziwą odpowiedzią jest Testowanie, Testowanie i testowanie ponownie pod kątem wskaźników wydajności, aby upewnić się, że osiągasz swoje cele.

[Edytuj] @Matt, po dalszych badaniach nad dyskusją o GUID/ID natknąłem się na ten post. Jak wspomniałem wcześniej, nie ma prawdziwej dobrej lub złej odpowiedzi. To zależy od twoich konkretnych potrzeb wdrożeniowych. Ale są to dość ważne powody, aby używać GUIDs jako klucz główny:

Na przykład istnieje problem znany jako "hotspot", w którym pewne strony danych w tabeli są w stosunkowo wysokim sporze walutowym. Zasadniczo, to, co się dzieje, to większość ruchu na stole (a tym samym blokada na poziomie strony)występuje na małym obszarze tabeli, pod koniec. Nowe rekordy zawsze trafią do tego hotspotu, ponieważ tożsamość jest generatorem liczb sekwencyjnych. Te wstawki są kłopotliwe, ponieważ wymagają wyjątkowej blokady strony na strona, do której są dodawane (hotspot). Dzięki mechanizmowi blokowania stron wszystkie wkładki są skutecznie serializowane do tabeli. Nevid () z drugiej strony nie cierpi na hotspoty. Wartości generowane za pomocą funkcji Nevid() są sekwencyjne tylko dla krótkich serii wstawek (gdzie funkcja jest wywoływana bardzo szybko, na przykład podczas wstawiania wielowarstwowego), co powoduje, że wstawione wiersze są losowo rozłożone na stronach danych tabeli zamiast wszystkich na końcu-eliminując w ten sposób hotspot z wkładek.

Ponadto, ponieważ wkładki są losowo rozmieszczone, szansa na podział stron jest znacznie zmniejszona. Chociaż strona podzielona tu i tam nie jest tak źle, efekty szybko się sumują. W przypadku tożsamości współczynnik wypełnienia strony jest dość bezużyteczny jako mechanizm strojenia i równie dobrze może być ustawiony na 100% - wiersze nigdy nie zostaną wstawione na żadnej stronie, ale na ostatniej. Dzięki Nevid (), możesz użyć Fill Factor jako narzędzia wspomagającego wydajność. Współczynnik wypełnienia można ustawić na poziomie to przybliża szacowany wzrost wolumenu między odbudowaniami indeksu, a następnie zaplanuje odbudowę w godzinach poza szczytem za pomocą dbcc reindex. To skutecznie opóźnia wydajność odsłon podziałów stron aż do czasów poza szczytem.

Jeśli nawet myślisz możesz potrzebować włączyć replikację dla danej tabeli - równie dobrze możesz uczynić PK uniqueidentifier i oznaczyć pole guid jako ROWGUIDCOL. Replikacja będzie wymagała unikatowego pola guid z tym atrybutem, a to doda jeden, jeśli nie istnieje. Jeśli istnieje odpowiednie pole, to po prostu użyje tego, które tam jest.

Kolejną ogromną zaletą korzystania z GUID dla PKs jest fakt, że wartość jest rzeczywiście gwarantowana unikalna - nie tylko wśród wszystkich wartości generowanych przez ten Serwer, ale wszystkie wartości generowane przez wszystkie komputery-czy to serwer db, serwer WWW, serwer aplikacji lub maszyna kliencka. Prawie każdy współczesny język ma możliwość generowania poprawnego guid teraz - w. NET można użyć System.Guid.NewGuid. Jest to bardzo przydatne szczególnie w przypadku buforowanych zbiorów danych typu master-detail. Nie musisz zatrudniać szalonych tymczasowych programów keying tylko po to, aby powiązać swoje rekordy razem, zanim zostaną one popełnione. Po prostu pobierasz nowy identyfikator Guid z systemu operacyjnego dla stałej wartości klucza każdego nowego rekordu w momencie jego utworzenia.

Http://forums.asp.net/t/264350.aspx