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

Question 1

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

Question 2

Tak nie jest. Istnieje niejasny odpowiednik:

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

Question 3

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.

Question 4

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!

Question 5

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.

Question 6

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/

Answer 1

139

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

sql sql-server tsql sql-server-2008 types Patrick
źródło

Answer 2

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

Answer 3

15

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

Elaskanator

Answer 4

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

Answer 5

1

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

Andrew

Answer 6

@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

Answer 7

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

Answer 8

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

Answer 9

14

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

HLGEM

Answer 10

22

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

ypercubeᵀᴹ

Answer 11

3

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

BenR

Answer 12

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ᵀᴹ

Answer 13

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

Answer 14

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!

Answer 15

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.

Answer 16

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

Answer 17

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

Answer 18

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

Answer 19

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

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

Odpowiedzi: