Ile kolumn jest za dużo dla tabeli programu SQL Server 2005?

Question

Mam żądanie, aby tabela dynamiczna miała 1000 kolumn (losowo wybranych przez moich użytkowników końcowych). Wydaje mi się to złym pomysłem. Jest to konfigurowalny stół, więc będzie miał mieszankę kolumn varchar(200) i float (najlepiej pasuje do aplikacji podwójnego typu C++). Ta baza danych jest głównie indeksem dla starszej aplikacji i służy jako repozytorium raportowania. To nie jest system rekordów. Aplikacja zawiera tysiące punktów danych, z których bardzo niewiele można znormalizować.

Jakieś pomysły dotyczące implikacji związanych z wydajnością? Lub idealny rozmiar stołu, aby podzielić to również?

Ponieważ nie wiem, jakie pola z wartości 20 tysięcy wyborów, które użytkownicy końcowi wybierze do normalizacji tabel, nie są możliwe. Mogę oddzielić te dane od kilku tabel, które będę musiał dynamicznie zarządzać (pola mogą być dodawane lub opuszczane) Wiersze są następnie usuwane, a system rekordów jest ponownie analizowany w celu wypełnienia tabeli.) Moją preferencją jest odsunięcie i znormalizuj wszystkie 20 tys. bitów danych. Ale nie widzę, żeby to się stało.

Answer 1

To pachnie złym wzorem dla mnie.

warte rozważenia:

Czy większość z tych kolumn będzie zawierać wartości NULL?

Czy wiele osób będzie nazywać się Property001, Property002, Property003 itd ...?

Jeśli tak, zalecam ponowną analizę normalizacji danych.

Answer 2

Co do zasady: im szersza tabela, tym niższa wydajność. Wiele cienkich stolików jest lepszym rozwiązaniem niż jeden gruby bałagan ze stołu.

Jeśli Twój stół jest tak szeroki, prawie na pewno jest to kwestia projektowa. Nie ma prawdziwych reguł dotyczących tego, ilu jest lepsze, nigdy nie spotkałem się z tabelami zawierającymi więcej niż 20 kolumn w świecie rzeczywistym. Tylko grupuj według relacji. W końcu to RDBMS.

Answer 3

Wydaje się strasznie dużo. Najpierw upewnię się, że dane są znormalizowane. To może być częścią twojego problemu. Jaki rodzaj celu będą służyć te dane? Czy to dotyczy raportów? Czy dane się zmienią?

Wydawałoby się, że stół, który jest szeroki, byłby koszmarnym osiągnięciem i konserwacją.

Answer 4

To za dużo. Każda szerokość jest większa niż 50 kolumn, a przy problemach występują problemy z wydajnością, obsługą kodu i rozwiązywaniem problemów.

Answer 5

z dokumentacją SQL2005:

SQL Server 2005 może mieć maksymalnie dwa miliardy tabel każdej bazy danych i 1024 kolumn na stole. (...) Maksymalna liczba bajtów na wiersz to 8,060. To ograniczenie jest luźniejsze w przypadku tabel z kolumnami varchar, nvarchar, varbinary lub sql_variant, które powodują, że całkowita zdefiniowana szerokość tablicy przekroczy 8 060 bajtów. Długości każdej z tych kolumn muszą nadal mieścić się w granicach 8 000 bajtów, ale ich łączna szerokość może przekraczać limit o wartości 8,060 bajtów w tabeli.

jaka jest funkcjonalność tych kolumn? dlaczego nie lepiej podzielić je na tabelę główną, właściwości (tabele wyszukiwania) i wartości?

Answer 6

Serwer MS SQL Server ma limit 1024 kolumn na tabelę, więc będziesz działać na granicy tego. Korzystając z kolumn varchar (200), można przekroczyć limit 8 bajtów na wiersz, ponieważ SQL będzie przechowywać 8k na stronie danych, a następnie przepełni dane poza stronę.

SQL 2008 dodał rzadkie kolumny dla scenariuszy takich jak ta - w których byłaby duża liczba kolumn z wartościami pustymi.

Korzystanie Rzadkie kolumny http://msdn.microsoft.com/en-us/library/cc280604.aspx

Answer 7

Będzie to miało ogromne problemy z wydajnością i danymi. Prawdopodobnie wymaga znormalizowania.

Podczas gdy serwer SQl pozwoli Ci utworzyć tabelę, która ma więcej niż 8060 bajtów w wierszu, NIE pozwoli ci przechowywać więcej danych niż w niej. Mogłeś niespodziewanie skrócić dane (a co gorsza, dopiero po kilku miesiącach może to nastąpić, a czas naprawy tego monstrum jest zarówno naglący, jak i wyjątkowo trudny).

Zapytanie o to również będzie prawdziwym problemem. Skąd wiesz, która z 1000 kolumn będzie szukała danych? Czy każde zapytanie powinno wymagać wszystkich 1000 kolumn w klauzuli where?

A pomysł, że byłoby to możliwe do dostosowania przez użytkownika, jest naprawdę przerażający. Dlaczego użytkownik musiałby mieć 1000 pól do spersonalizowania? Większość aplikacji, które widziałem, które dają użytkownikowi szansę na dostosowanie niektórych pól, wyznacza mały limit (zwykle mniej niż 10). Jeśli jest tak dużo, że trzeba je dostosować, to aplikacja nie wykonała dobrej pracy przy definiowaniu, czego faktycznie potrzebuje klient.

Czasami jako programista musisz wstać i powiedzieć "nie", to zły pomysł. To jeden z tych czasów.

Co do tego, co zamiast tego zrobić (poza normalizacją), myślę, że potrzebowalibyśmy więcej informacji, aby wskazać wam właściwy kierunek.

I BTW, zmiennoprzecinkowy jest niedokładnym typem danych i nie powinien być używany w polach, w których przeprowadzane są obliczenia, chyba że lubisz nieprawidłowe wyniki.

Answer 8

Ilekroć czujesz potrzebę, aby zapytać, jakie ograniczenia ma system, masz problem z projektowaniem.

Jeśli pytasz "Ile postaci mogę zmieścić w varcharze?" wtedy nie powinieneś w ogóle używać varcharów.

Jeśli poważnie chcesz wiedzieć, czy 1000 kolumn jest w porządku, to rozpaczliwie potrzebujesz reorganizacji danych. (normalizacja)

Answer 9

Czy myślisz o wyświetleniu ostatecznej tabeli (1000 kolumn) w wyniku zapytania tabeli krzyżowej? Twoja oryginalna tabela miałaby wtedy tylko kilka kolumn, ale wiele tysięcy rekordów.

Czy możesz wyjaśnić swój problem? Myślę, że nikt tak naprawdę nie rozumie, dlaczego potrzebujesz tych 1000 kolumn!

Answer 10

Muszę się z tym wszystkim nie zgodzić ... Wiem, że to brzmi szalenie, ale używanie tabel z setkami kolumn to najlepsza rzecz, jaką kiedykolwiek zrobiłem.

Tak wiele kolumn często ma wartości puste; Tak, mogę normalizować go do kilku tabel i transponować; Tak to jest nieefektywne

Jednak jest niezwykle szybkie i łatwe do analizowania danych kolumn w niekończących się różnych sposobów

Marnotrawstwo i nieeleganckie - nigdy nie budować niczego jako przydatne!