SQL Server równoważny typowi danych wyliczenia MySQL?

139

Czy SQL Server 2008 ma typ danych, taki jak MySQL enum?

— Patrick
źródło

166

Tak nie jest. Istnieje niejasny odpowiednik:

mycol VARCHAR(10) NOT NULL CHECK (mycol IN('Useful', 'Useless', 'Unknown'))

— chaos
źródło

15

Dlaczego nie użyć tabeli, która definiuje prawidłowe wartości, a zamiast tego użyć ograniczenia klucza obcego?

— Elaskanator

1

@Elaskanator Powiedziałbym, że to najdokładniej odpowiada bezpośredniemu OP, podczas gdy najlepszym rozwiązaniem jest prawdopodobnie użycie zewnętrznego stołu FK +.

— userfuser

1

Dziękuję @Elaskanator za przypomnienie mi oczywistego ... znormalizuj dane i wyliczenie przestanie istnieć.

— Andrew

@Elaskanator Często wartości wyliczenia są definiowane najpierw w kodzie aplikacji (np. C # enum), podczas gdy gdyby używały odwołania FK do tabeli, wówczas te rzekomo statyczne wpisy wyliczenia mogą być modyfikowane w czasie wykonywania, co byłoby niepożądane (a SQL Server nie obsługuje koncepcji niezmienne tabele), wreszcie, jeśli masz wiele wyliczeń z tylko kilkoma wartościami, w końcu dodasz wiele tabel do bazy danych. Nie wspominając o dodatkowych odczytach IO ze względu na sprawdzanie ograniczeń FK podczas wstawiania / usuwania danych, podczas gdy a CHECK CONSTRAINTjest znacznie szybszy i nie powoduje spamowania obiektów bazy danych.

— Dai

1

Zgadzam się z @dai. Kiedyś używałem tablic kodu, ale postrzegam je jako przesadę. Podoba mi się funkcjonalność CHECK i varchar. Pozwala na użycie statycznego wyliczenia w języku C # bez wielu wymyślnych obejść. Pod względem wydajności sqlserver doskonale radzi sobie z indeksowaniem ciągów znaków prawie tak samo dobrze jak ints lub smallint. Wzrost wydajności jest minimalny w porównaniu z dodatkową złożonością kodowania. Czas to pieniądz.

— James O'Brien

90

Najlepszym rozwiązaniem, jakie znalazłem w tym przypadku, jest utworzenie tabeli przeglądowej z możliwymi wartościami jako kluczem podstawowym i utworzenie klucza obcego do tabeli przeglądowej.

— user1431422
źródło

14

Lepsze rozwiązanie z punktu widzenia łatwości konserwacji niż pokazane powyżej ograniczenie sprawdzające.

— HLGEM

22

To lepsze rozwiązanie niż Enums - także w MySQL.

— ypercubeᵀᴹ

3

@ypercube Dlaczego jest lepszy również dla MySQL?

— BenR

5

@BenRecord Istnieje kilka problemów z wyliczeniami MySQL: 8 powodów, dla których typ danych ENUM w MySQL jest zły . Nie zgadzam się w 100%, że są złe, ale podczas ich używania należy zachować szczególną ostrożność.

— ypercubeᵀᴹ

2

@BenR również, jeśli dobrze pamiętam, w trybie nieścisłym z MySQL, nieprawidłowe wyliczenie można wstawić jako NULL. Niezależnie od warunków, poprzedni zespół miał problemy z wyliczeniem MySQL, które nie zostało wstawione i nie kończyło się niepowodzeniem, gdy wartość nie została określona na liście wartości. Ograniczenie klucza obcego w tabeli przeglądowej spowodowałoby błąd. Zgadzam się, że tablica przeglądowa jest lepsza dla MySQL.

— Jim Schubert

5

Tabele wyszukiwania IMHO to droga do zrobienia, z referencyjną integralnością. Ale tylko jeśli unikniesz „złych magicznych liczb”, postępując zgodnie z przykładem takim jak ten: Generowanie wyliczenia z tabeli wyszukiwania bazy danych przy użyciu T4

Baw się dobrze!

— Jony Adamit
źródło

3

CREATE FUNCTION ActionState_Preassigned()
RETURNS tinyint
AS
BEGIN
    RETURN 0
END

GO

CREATE FUNCTION ActionState_Unassigned()
RETURNS tinyint
AS
BEGIN
    RETURN 1
END

-- etc...

Tam, gdzie liczy się wydajność, nadal używaj twardych wartości.

— Dimitrios Staikos
źródło

1

Znalazłem to interesujące podejście, gdy chciałem zaimplementować wyliczenia w SQL Server.

Podejście wymienione poniżej w linku jest dość przekonujące, biorąc pod uwagę, że wszystkie potrzeby wyliczeń bazy danych mogą być zaspokojone przy użyciu 2 tabel centralnych.

http://blog.sqlauthority.com/2010/03/22/sql-server-enumerations-in-relational-database-best-practice/

— user_v
źródło

8

Jest to odmiana anty-wzorca znanego jako „jedna prawdziwa (przeglądowa) tabela”. Właściwym podejściem jest utworzenie oddzielnej tabeli dla każdego typu wyliczenia i użycie kluczy obcych (jeśli w ogóle potrzebujesz wyszukiwania, co może nie mieć miejsca w przypadku „czystych” wyliczeń).

— Branko Dimitrijevic

2

Komentarze na połączonej stronie stanowią dobrą kopię zapasową do korzystania z indywidualnych tabel dla każdego „wyliczenia”, zamiast tego, co określa ta odpowiedź

— skia.heliou

5

To dość zabawne, jak większość ludzi słusznie wzbraniałaby się przed takim projektem, ale autor nazywa swój artykuł „Najlepszą praktyką”.

— underscore_d