Ile pól ma "za dużo" w tabeli?

Question

Mam współpracownika, który planuje bazę danych dla nowej aplikacji, która będzie miała kilka tabel z ponad 30 polami. Czy to jest przesadne? Może po prostu nie jestem wystarczająco przedsiębiorczy, żeby to zrozumieć.

Edycja: Ponadto, wiele pól to rzeczy typu opcji (jak na formularzu żądania, czy chcesz, aby twój widget był żółty lub zielony, ma pole dla "koloru" z wyliczeniem) . Jest całkiem prawdopodobne, że zostaną one dodane lub usunięte w miarę upływu czasu. Tak naprawdę nie robiłem projektowania baz danych i starałem się trzymać z dala od tego, więc może jestem całkowicie głupi, ale na pewno jest lepszy sposób na zrobienie tego?

Answer 1

nie ma arbitralnego limitu; wystarczy, aby zadanie to dobra zasada

jeśli masz lepszy wygląd db sugerują go

jeśli chcesz bardziej szczegółowe informacje zwrotne, pisać schematu

Answer 2

oczywiście standardową odpowiedź to jest to zależy od. Stół z wieloma polami może w niektórych sytuacjach mieć całkiem sensowny sens.

Pomyśl o danych, które będziesz tam przechowywać. Czy jest prawdopodobne, że wiele z tych pól będzie NULL? Jakie jest prawdopodobieństwo, że te pola się zmienią (np. Więcej zostanie dodanych)?

Jeśli do niektórych obiektów odnoszą się tylko niektóre pola, być może warto pomyśleć o umieszczeniu tych pól w innej tabeli. Alternatywnie, przechowuj tylko podstawowe, wspólne pola w jednej tabeli i dodatkowe informacje w innej tabeli, jeden wiersz na pole. Jak I suggested dla a different question (which might be helpful to you):

 
refs (id, title, refType) 
-- title of the reference, and what type of reference it is 

fieldDef (id, fieldName, refType, dataType) 
-- name of the field, which reference types it applies to, and 
-- what type of data is stored in these fields (ISDN number, date, etc) 

fields (refId, fieldId, value) 
-- where you actually add data to the references. 

Należy pamiętać, że był to downvoted, i prawdopodobnie z tego powodu. Jest to opcja, niekoniecznie najlepsza opcja, ale nadal jest to metoda możliwa do zastosowania. Jednak najwyżej oceniona odpowiedź w pytaniu, które tam podłączyłem, może być najlepszym rozwiązaniem.

---

Edit: skoro mówisz, że będzie ona trzyma rzeczy jak ustawień użytkownika (np: kolor widget), bym faktycznie polecam metodę opisaną powyżej (z trzech tabel). Możliwe, że większość ludzi domyślnie opuści rzeczy, więc będziesz mieć cały stos niepotrzebnych informacji. Proszę przeczytać moją odpowiedź w drugim pytaniu, ponieważ inni czytelnicy zwrócili uwagę na niedociągnięcia tej metody.

Answer 3

Liczba pól zwykle nie stanowi problemu, ale chcesz się upewnić, że twoja baza danych jest poprawnie sformalizowana. Third normal form to dobry początek.

Answer 4

Jeśli musisz zapytać: "Czy w tym stole jest zbyt wiele pól?" Wtedy prawdopodobnie są.

Answer 5

Znakiem ostrzegawczym jest dokładnie to, co powiedziałeś. Ma pola, które teoretycznie powinny zostać podzielone na inną tabelę. Kolejną nagrodą jest obecność wielu pól opcjonalnych.

Powiedziałbym, że kurs projektowania baz danych ma na celu DB "Expert". A proponuję, żebyś to odświeżył ... może tylko pomóc ci rozwinąć się w swojej karierze :)

Answer 6

Tabele baz danych mogą legalnie zawierać 30 lub więcej pól. To, na co musisz zwrócić uwagę, to normalizacja danych i czy ta normalizacja ma sens.Zwykle zmieni się to również w przyszłości. Ale chcesz spróbować to zminimalizować.

Na przykład, jeśli masz tabelę zawierającą adresy, to czy w tej tabeli znajdują się pola miasta, stanu i kodu pocztowego? Lub, czy uwzględniasz tylko jedno pole, które "wskazuje" rekord w osobnej tabeli dla tych wartości? Oddzielna tabela zawierałaby unikalne kombinacje miast, stanów i kodów pocztowych. Efektem podziału danych na dwie tabele jest zmniejszenie ilości przechowywanych danych (najprawdopodobniej, ale nie bezwzględnie), ale nieco zwiększona złożoność podczas uruchamiania zapytań względem bazy danych. Teraz musisz zająć się 2 tabelami zamiast tylko jedną. Ale z drugiej strony jest znacznie czystszy i znacznie mniejszy (prawdopodobnie).

Prawdziwa odpowiedź brzmi, że w danych okolicznościach można pozostawić dane z miasta-stanu zip w tabeli adresowej. Lub, możesz chcieć "znormalizować" to. Oba są w porządku.

Znajdź dobrego administratora bazy danych i zatrudnij go na krótki okres, aby przejrzeć plan, jeśli jest on w budżecie. To się opłaca w dłuższej perspektywie.

Answer 7

Trzydzieści pól to nie jest zbyt wiele - wystarczy, że upewnisz się, że twoje dane są odpowiednio znormalizowane (dla których jest wiele przewodników w Internecie).

Na podstawie Twojej edycji, w której określisz, że wiele kolumn będzie polami opcji typu, które mogą być dodawane lub usuwane w miarę upływu czasu, proponuję następujące rozwiązanie.

BaseTable: 
    Id 
    NonOptionFields 
OptionTable: 
    Id 
    OptionName 
    OptionValue 

Następnie możesz powiązać wszystkie swoje opcje z rekordem bazy. Oznacza to, że nie będziesz musiał dodawać i usuwać kolumn do tabel przez cały czas znormalizowany sposób, aby osiągnąć to, co chcesz.

Answer 8

Najbardziej oczywistym znakiem tabeli wymaga normalizacji, że widziałem pola kończące się liczbami całkowitymi: CouponCode1, CouponCode2, CouponCode3 .. masz rację. Będą jednak wyjątki od reguły, jak zawsze.

Answer 9

przypomnienie normalizacji-by-default Partyzantka za:

1. Stół powinien mieć klucz podstawowy i co najwyżej jeszcze jedną kolumnę.
2. Łamanie reguły nr 1 tylko tak często, jak jest to wymagane.

Answer 10

Nie ma ograniczeń co do liczby pól w teorii bazy danych. Tabela może być ograniczona do klucza podstawowego (nawet jeśli ten klucz główny składa się z 2 pól), co oznacza, że ​​Apocalisp's answer nie jest bardzo jasne. W przeciwnym przypadku tabela może być utworzona z tysięcy pól, pod warunkiem, że są przestrzegane normal form rules.

Gdy grupy pól są oczywiście niedostatecznie wykorzystywane w tabeli, można sprytnie podzielić tę grupę pól na inną tabelę z relacją 0-1 między tabelą główną a tabelą "podrzędną".

Ze względów bezpieczeństwa był on często proponowany (dawno temu: myślę, że to była moja pierwsza książka z relacyjnymi bazami danych, opublikowana po raz pierwszy w 197 r.?), Aby podzielić poufne informacje w innej tabeli z tym samym 0-1 relacja między głównym i podrzędnym. Następnie można było łatwo ograniczyć dostęp użytkownika do tabeli "podrzędnej". Taką konfigurację można teraz łatwo zarządzać widokami.

Answer 11

Termin "zbyt wiele" jest względny ... Nie należy dzielić tabeli tylko w celu zmniejszenia liczby pól, szczególnie jeśli w każdym zapytaniu będziesz musiał do nich dołączyć razem, ponieważ są to w zasadzie relacje jeden-do-jednego. Jeśli pola można podzielić na osobny obiekt logiczny, miałoby to sens.Na przykład zamiast zapisywania pól adresowych w tabeli klienta można je przenieść do osobnej tabeli adresów. To jest prosty przykład, ale ilustruje mój punkt widzenia.

Answer 12

OLTP

Z mojego doświadczenie w projektowaniu baz danych, istnieje bardzo niewiele stoły w znormalizowanej bazy danych OLTP, które zawierają szalenie dużą liczbę kolumn.

IMO 30 kolumn jest za dużo.

Dla mnie nie więcej niż 10% moich tabel OLTP ma dużą liczbę (> 10) kolumn.

OLAP

Teraz, jeśli masz zamiar zrobić przestrzennej struktury/Raportowanie, niektórzy ludzie mogą rozważyć tabeli 30 kolumna być wąskie.