Czy tabela z jedną kolumną jest dobrym projektem? [Zamknięte]

Czy można mieć tabelę z tylko jedną kolumną? Wiem, że nie jest to technicznie nielegalne, ale czy jest to uważane za kiepski projekt?

EDYTOWAĆ:

Oto kilka przykładów:

• Masz tabelę z 50 prawidłowymi kodami stanów USA, ale nie musisz przechowywać pełnych nazw stanów.
• Czarna lista e-maili.

Ktoś wspomniał o dodaniu pola kluczowego. Tak jak ja to widzę, ta pojedyncza kolumna BYŁAby kluczem podstawowym.

Tak, z pewnością dobrym projektem jest zaprojektowanie stołu w taki sposób, aby był jak najbardziej wydajny. „Zły projekt RDBMS” zwykle koncentruje się na nieefektywności.

Jednak odkryłem, że większość przypadków projektowania z jedną kolumną może skorzystać na dodatkowej kolumnie. Na przykład kody stanów mogą zazwyczaj zawierać nazwę pełnego stanu zapisaną w drugiej kolumnie. Albo czarna lista może mieć przypisane notatki. Ale jeśli twój projekt naprawdę nie potrzebuje tych informacji, to idealnie jest mieć pojedynczą kolumnę.

W kategoriach relational algebratego byłaby to relacja jednoargumentowa, oznaczająca „ ta rzecz istnieje ”

Tak, dobrze jest mieć tabelę definiującą taką relację: na przykład w celu zdefiniowania domeny.

Wartości takiej tabeli powinny oczywiście być naturalnymi kluczami głównymi.

prime numbersNajpierw przychodzi mi do głowy tabela przeglądowa .

Używałem ich w przeszłości. Jeden z moich klientów chciał automatycznie blokować każdego, kto próbował się zarejestrować za pomocą numeru telefonu z tej dużej listy, którą miał, więc była to tylko jedna duża czarna lista.

Jeśli istnieje taka potrzeba, to nie widzę problemu. Może z jakiegoś powodu chcesz po prostu wyświetlić listę możliwości i chcesz mieć możliwość jej dynamicznej zmiany, ale nie musisz łączyć jej z inną tabelą.

Jeden przypadek, który czasami znajdowałem, jest taki:

Tabela country_id , zawiera tylko jedną kolumnę z numerycznym identyfikatorem dla każdego kraju.

Tabela opis_krajów zawiera kolumnę z identyfikatorem kraju, kolumnę z identyfikatorem języka i kolumnę z zlokalizowaną nazwą kraju.

Tabela company_factories , zawiera informacje o każdej fabryce firmy, w tym o kraju, w którym się znajduje.

Aby więc zachować spójność danych i dane niezależne od języka w tabelach, baza danych używa tego schematu z tabelami z tylko jedną kolumną, aby umożliwić klucze obce bez zależności językowych.

W tym przypadku myślę, że istnienie tabel z jedną kolumną jest uzasadnione.

Opracował w odpowiedzi na komentarz: Quassnoi

_{(źródło: ggpht.com )}

W tym schemacie mogę zdefiniować klucz obcy w tabeli company_factories, która nie wymaga umieszczania kolumny Language w tabeli, ale jeśli nie mam tabeli country_id to muszę dołączyć kolumnę Language do tabeli, aby zdefiniować klucz obcy .

W rzadkich przypadkach tabela jednokolumnowa ma sens. Zrobiłem jedną bazę danych, w której lista prawidłowych kodów języków była tabelą jednokolumnową używaną jako klucz obcy. Nie było sensu mieć innego klucza, ponieważ sam kod był kluczem. I nie było ustalonego opisu, ponieważ opisy kodu języka różniłyby się w zależności od języka w niektórych kontekstach.

Ogólnie rzecz biorąc, każdy przypadek, w którym potrzebujesz autorytatywnej listy wartości, które nie mają żadnych dodatkowych atrybutów, jest dobrym kandydatem do tabeli jednokolumnowej.

Cały czas korzystam z tabel jednokolumnowych - oczywiście w zależności od tego, czy projekt aplikacji korzysta już z bazy danych. Kiedy już wytrzymałem projekt związany z ustanowieniem połączenia z bazą danych, umieściłem wszystkie zmienne dane w tabelach, jeśli to możliwe.

Przychodzą mi do głowy dwa zastosowania jednokolumnowych tabel OTMH:

1) Pozycja danych istnieje. Często używany na listach rozwijanych. Używane również do prostych testów legitymacji.

Na przykład. dwuliterowe skróty stanów USA; Kody pocztowe, do których wysyłamy; słowa legalne w Scrabble; itp.

2) Rzadki atrybut binarny, tj. W dużej tabeli atrybut binarny, który będzie prawdziwy tylko dla kilku rekordów. Zamiast dodawać nową kolumnę logiczną, mógłbym utworzyć osobną tabelę zawierającą klucze rekordów, dla których atrybut jest prawdziwy.

Na przykład. pracownicy cierpiący na śmiertelną chorobę; banki z 360-dniowym rokiem (większość używa 365); itp.

-Glin.

Nie ma problemu, o ile zawiera unikalne wartości.

Zwykle widziałem to w tabelach typów wyszukiwania, takich jak tabela stanów, którą opisałeś. Jeśli jednak to zrobisz, ustaw kolumnę jako klucz podstawowy, aby wymusić unikalność. Jeśli nie możesz ustawić tej wartości jako unikalnej, nie powinieneś używać jednej kolumny.

Ogólnie powiedziałbym, że tak. Nie wiem, dlaczego potrzebujesz tylko jednej kolumny. Jest kilka wyjątków od tego, które jak widziałem skutecznie stosowane. To zależy od tego, co próbujesz osiągnąć.

Nie są one dobrym projektem, jeśli myślisz o schemacie bazy danych, ale tak naprawdę powinny być używane tylko jako tabele narzędzi.

W przeszłości widziałem skutecznie używane tabele liczbowe .

Celem bazy danych jest powiązanie ze sobą informacji. Jak możesz to zrobić, gdy nie ma danych, do których można by się odnieść?

Może to jest jakaś tabela kompilacji (np. Imię + Nazwisko + Data urodzenia), chociaż nadal nie jestem pewien, dlaczego chcesz to zrobić.

EDYCJA: Widziałem użycie tego rodzaju tabeli do jakiejś prostej listy. Czy do tego go używasz?

Tak, o ile pole jest kluczem podstawowym, tak jak powiedziałeś. Powodem jest to, że jeśli wstawisz zduplikowane dane, te wiersze będą tylko do odczytu. Jeśli spróbujesz usunąć jeden z powielonych wierszy. nie zadziała, ponieważ serwer nie będzie wiedział, który wiersz usunąć.

Jedynym przykładem użycia, jaki mogę sobie wyobrazić, jest tablica słów, być może dla gry słownej. Uzyskujesz dostęp do tabeli tylko po to, aby sprawdzić, czy ciąg jest słowem: wybierz słowo ze słów, w których słowo =?. Ale istnieją znacznie lepsze struktury danych do przechowywania listy słów niż relacyjna baza danych.

W przeciwnym razie dane w bazie danych są zwykle umieszczane w bazie danych, aby wykorzystać zależności między różnymi atrybutami danych. Jeśli Twoje dane nie mają atrybutów wykraczających poza ich wartość, w jaki sposób rozwinie się ta relacja?

Tak więc, chociaż nie jest to nielegalne, generalnie prawdopodobnie nie powinieneś mieć tabeli z tylko jedną kolumną.

Wszystkie moje tabele mają co najmniej cztery pola techniczne, seryjny klucz podstawowy, znaczniki czasu utworzenia i modyfikacji oraz wartości logiczne do miękkiego usuwania. Na dowolnej czarnej liście będziesz również chciał wiedzieć, kto dodał wpis. Więc dla mnie odpowiedź brzmi nie, tabela z tylko jedną kolumną nie miałaby sensu, z wyjątkiem tworzenia prototypów.

Tak, to jest w porządku. ale pole identyfikacyjne nie może tego zranić, prawda?