zawyżanie wielkości pola w projekcie bazy danych

11

Mam pewne tabele dla moich tabel, które są ciągami, a obecnie większość wielkości pola ma dość wysokie limity znaków. Na przykład 100 znaków dla nazwy ulicy. Czy istnieje kara za użycie dużego pola? Jeśli na przykład zmienię limit na 30 znaków dla tego pola, to czy będzie wzrost wydajności lub wydajność z rozmiarem? Byłoby około 50 pól, które mogłyby być kandydatami na skurcz.

Dziękuję za twoje sugestie.

sql-server

W przypadku char przestrzeń jest zawsze używana w bazie danych, ale w przypadku varchara, choć kara będzie mniejsza, potrzeba większej przestrzeni zarezerwowanej podczas operacji, których tak naprawdę potrzebujesz, może również sprawić, że będzie nieco mniej wydajna. Nie przejmowałbym się kolumnami varchar, chyba że są one bardzo duże - jak zawsze przy użyciu varchar (max) lub varchar (1000).

— Cade Roux,

Należy pamiętać o przekroczeniu rozmiaru jednej strony (8k), ponieważ wpłynie to na wydajność. Sprawdź ten post: stackoverflow.com/questions/2518922/...

Biorąc pod uwagę niski koszt dysków twardych, w dzisiejszych czasach nie martwię się o wydajność pamięci. Jak mówi JNK, ma to wpływ na indeksowanie bardzo dużych pól - zdecydowanie warto o tym pamiętać. Ból związany ze zmianą aplikacji, ponieważ przydzielono zbyt mało miejsca, jest znacznie większy niż koszt kilku dodatkowych bajtów w tabeli bazy danych.

— Neville Kuyt,

3

Myślę, że ignorowanie pamięci masowej, ponieważ jest tanie, to zły pomysł. Każdy bajt na dysku musi zostać pobrany i przetworzony, a najwolniejszą częścią niemal każdej instalacji programu SQL Server jest pamięć dyskowa. Mniej bajtów = szybsze zapytania.

— JNK

1

Jeśli 100 MB spowoduje, że 20% mniej danych zmieści się w pamięci podręcznej kontrolera dysku 512 MB, będzie to absolutnie miało znaczenie (głos doświadczenia).

— Eric J.

16

Jeśli mówisz, varchara nvarcharnastępnie nie, nie ma kary za zezwolenie na większą długość pola.

Należy jednak pamiętać o kilku zastrzeżeniach:

Na wiersz o zmiennej długości (na pole) przypada 2 bajty narzutów na wiersz . Jeśli masz bardzo krótkie pole, bardziej sensowne może być użycie CHAR. Varchar(2)na przykład faktycznie używa od 2 do 4 bajtów na wiersz, podczas gdy CHAR(2)zawsze używa 2.
Bardzo długie pola nie mogą być indeksowane. Maksymalna długość wszystkich pól w zestawie kluczy indeksu wynosi 900 bajtów.
Jeśli zezwolisz na więcej danych, niż się spodziewasz, w końcu otrzymasz nieoczekiwane wyniki. Jeśli wpiszesz 100 znaków dla nazwy ulicy, w pewnym momencie inne dane prawdopodobnie dostaną się do tego pola bez Twojej wiedzy (na przykład cały adres). Jeśli miałby odpowiednio dobrany rozmiar, prawdopodobnie pojawiłby się błąd wstawiania.
Zezwolenie na bardzo szerokie wiersze może prowadzić do podziału strony i fragmentacji. Jeśli masz wiersz dłuższy niż 8 KB, konieczne będzie podzielenie go na wiele stron danych. Wiele z nich może naprawdę zaszkodzić wydajności. Ogólnie węższy jest bardziej wydajny.

— JNK
źródło

1

Możesz dodać zastrzeżenia do skrótu również do tej odpowiedzi, np. Upewnij się, że kolumna jest co najmniej wystarczająco duża: adres varchar (30) nie może poradzić sobie z Bolderwood Arboretum Ornamental Drive lub Northeast Kentucky Industrial Parkway .

@Aleksi - bardzo prawdziwe. Sądzę jednak, że są one bardziej oczywiste i dlatego OP na początku używa szerokich pól.

— JNK

„w pewnym momencie inne dane prawdopodobnie przedostaną się do tego pola, nie zdając sobie z tego sprawy”. Ciekawy punkt. Widziałem wiele systemów, w których użytkownicy wzięli dowolne pole, które nie miało zastosowania do obecnego rekordu, jako pole komentarza ogólnego przeznaczenia.

2

Może być kara

— Martin Smith,

2

Jeśli masz na myśli: „Czy istnieje kara za zadeklarowanie rozmiaru pola większego niż jakiekolwiek wartości, które są w nim faktycznie zapisane?”, To tak długo, jak jest on deklarowany jako varchar, odpowiedź brzmi „nie”. Każdy silnik SQL DB, który znam, przechowuje tylko liczbę znaków faktycznie podanych w danych (plus wartość długości). Jeśli więc zdefiniujesz pole jako varchar (100), ale zapiszesz w nim tylko 10 znaków, to zajmie tylko 10 znaków na dysku (plus 2 bajty dla długości). W razie wątpliwości rutynowo robię moje pola varcharowe absurdalnie duże.

Jeśli masz na myśli „Czy istnieje kara za przechowywanie długich pól postaci”, odpowiedź brzmi „tak”. Dzisiejsze miejsce na dysku jest tanie, ale nie jest darmowe, więc nie chcesz go marnować bez powodu. Prawdopodobnie ważniejsze jest, że odczyt danych z dysku zajmuje trochę czasu, więc im dłuższe są pola danych, tym wolniej działa program. Jeśli pole jest indeksowane, może to naprawdę spowolnić pobieranie, ponieważ każde czytanie będzie musiało porównać kluczową wartość z tym dużym, długim polem.

Pamiętaj, że jeśli dasz użytkownikowi pole do wprowadzania dużych danych, użyje go wcześniej lub później.

To powiedziawszy, pomyliłbym się po stronie zbyt dużej, a nie zbyt małej. Miejsce na dysku jest na tyle tanie, że nie chcesz zmuszać użytkowników do wymyślania skrótów w locie, ponieważ nie mogą zmieścić rzeczywistych danych w dostępnym polu. System, nad którym dziś pracuję, ma pole opisu produktu, które jest zbyt małe dla wielu prawdziwych nazw naszych produktów, więc użytkownicy muszą skracać. I oczywiście każdy użytkownik skraca inaczej, więc mamy dwadzieścia różnych sposobów, aby powiedzieć to samo.

— Sójka
źródło

2

Każdy, kto twierdzi, że nie ma kary za zadeklarowanie większego pola niż to, co faktycznie będzie przechowywane w tabeli, jest niepoprawny. Rzeczywisty rozmiar danych (plus ten 2 bajtowy narzut) jest rzeczywiście przechowywany, ale to definicja kolumny jest używana do określania oszacowania w miarę realizacji planu wykonania. Tak więc, podczas gdy deklarowanie varchara (1000) do przechowywania wartości 10 znaków zużyje tylko 12 znaków miejsca na dysku, szacunki planu wykonania będą znacznie mniej wydajne i negatywnie wypaczą wyniki, zarówno pod względem ilości pamięci, aby udzielić operacji, jak i czy operacja może być wykonana wyłącznie w pamięci, czy też będzie wymagała miejsca na dysku tempdb. Możesz ustawić kolumnę varchar (1000), ale silnik nie wie, że wszystkie przechowywane wartości są naprawdę mniejsze niż varchar (10),

— Jim
źródło

0

Sprawdzanie długości pola to coś, co dostajesz „za darmo”, co oznacza, że nie musisz używać CHECKograniczenia, aby to samo robić. I nie chcesz przewymiarowanych wartości danych, gdy na przykład musisz przesłać swoje dane do innej bazy danych, która ograniczyła ten sam element danych do 35 znaków zgodnie ze standardowym adresem międzynarodowym.

— oneedaywhen
źródło