zawyżanie wielkości pola w projekcie bazy danych

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.

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.

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.

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),

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.