Chcę przechowywać płeć użytkownika w bazie danych przy jak najmniejszych kosztach (rozmiar / wydajność).
Jak dotąd przychodzą na myśl 3 scenariusze
- Int - wyrównane z wyliczeniem w kodzie (1 = mężczyzna, 2 = kobieta, 3 = ...)
- char (1) - Przechowuj m , f lub inny pojedynczy identyfikator znaku
- Bit (boolean) - czy istnieje odpowiednia nazwa pola dla tej opcji?
Powodem, o który pytam, jest ta odpowiedź, która wspomina, że znaki są mniejsze niż wartości logiczne .
Należy wyjaśnić, że używam MS SQL 2008, który robi w rzeczywistości mają bitowego typu danych.
sql
database-design
Marko
źródło
źródło
Odpowiedzi:
Nazwałbym kolumnę „płcią”.
Data Type Bytes Taken Number/Range of Values ------------------------------------------------ TinyINT 1 255 (zero to 255) INT 4 - 2,147,483,648 to 2,147,483,647 BIT 1 (2 if 9+ columns) 2 (0 and 1) CHAR(1) 1 26 if case insensitive, 52 otherwise
BIT typ danych można wykluczyć, ponieważ obsługuje tylko dwie płcie, które możliwe jest niewystarczająca. Podczas gdy INT obsługuje więcej niż dwie opcje, zajmuje 4 bajty - wydajność będzie lepsza przy mniejszym / węższym typie danych.
CHAR(1)
ma przewagę nad TinyINT - oba zajmują tę samą liczbę bajtów, ale CHAR zapewnia węższą liczbę wartości. UżycieCHAR(1)
spowodowałoby użycie naturalnych kluczy "m", "f" itp., Zamiast użycia danych numerycznych, które są określane jako klucze zastępcze / sztuczne.CHAR(1)
jest również obsługiwany w każdej bazie danych, jeśli zajdzie potrzeba przeniesienia.Wniosek
Użyłbym opcji 2: CHAR (1).
Uzupełnienie
Indeks w kolumnie płci prawdopodobnie nie pomógłby, ponieważ w indeksie w kolumnie o niskiej liczności nie ma wartości. Oznacza to, że nie ma wystarczającej różnorodności wartości, aby indeks mógł podać jakąkolwiek wartość.
źródło
Istnieje już norma ISO w tym zakresie; nie musisz wymyślać własnego schematu:
http://en.wikipedia.org/wiki/ISO_5218
Zgodnie ze standardem kolumna powinna nosić nazwę „Płeć”, a „najbliższy” typ danych to tinyint z ograniczeniem CHECK lub odpowiednio z tabelą przeglądową.
źródło
W medycynie wyróżnia się cztery płci: męską, żeńską, nieokreśloną i nieznaną. Możesz nie potrzebować wszystkich czterech, ale z pewnością potrzebujesz 1, 2 i 4. Nie jest właściwe posiadanie wartości domyślnej dla tego typu danych. Jeszcze mniej traktować go jako wartość logiczną ze stanami „jest” i „nie jest”.
źródło
TinyInt
wybrałbym wyrównanie z wyliczeniem (jak sugeruje Hugo) i wybrałbym co najmniej 1, 2 i 3 (inne).Not Known
, 1 =Male
, 2 =Female
, 9 =Not Specified
, które odzwierciedlają wartości ISO 5218 . Uwaga: istnieją dwa rodzaje : płeć w momencie rejestracji (zwykle krótko po urodzeniu) i aktualna.Int
(LubTinyInt
) dostosowane doEnum
pola byłaby moja metodologia.Po pierwsze, jeśli masz jedno
bit
pole w bazie danych, wiersz nadal będzie używał pełnego bajtu, więc jeśli chodzi o oszczędność miejsca, opłaca się tylko wtedy, gdy masz wielebit
pól.Po drugie, łańcuchy / znaki mają "magiczną wartość", niezależnie od tego, jak oczywiste mogą się wydawać w czasie projektowania. Nie wspominając już o tym, że pozwala ludziom przechowywać dowolną wartość, której niekoniecznie odwzorowaliby na coś oczywistego.
Po trzecie, wartość liczbowa jest znacznie łatwiejsza (i lepsza praktyka), aby utworzyć tabelę przeglądową, aby wymusić integralność referencyjną i może korelować 1 do 1 z wyliczeniem, więc istnieje parzystość w przechowywaniu wartości w pamięci w w aplikacji lub w bazie danych.
źródło
Używam znaków „f”, „m” i „u”, ponieważ przypuszczam płeć na podstawie imienia, głosu i rozmowy, a czasami nie znam płci. Ostateczna decyzja jest ich zdaniem.
To naprawdę zależy od tego, jak dobrze znasz osobę i od tego, czy twoje kryteria to forma fizyczna czy tożsamość osobista. Psycholog może potrzebować dodatkowych opcji - skrzyżowanie z kobietą, skrzyżowanie z mężczyzną, trans z kobietą, trans z mężczyzną, hermafrodyta i niezdecydowani. Mając 9 opcji, które nie są jasno zdefiniowane przez jeden znak, mogę skorzystać z rady Hugo dotyczącej małej liczby całkowitej.
źródło
Opcja 3 jest najlepszym rozwiązaniem, ale nie wszystkie silniki DB mają typ „bitowy”. Jeśli nie masz trochę, najlepszym rozwiązaniem będzie TinyINT.
źródło
CREATE TABLE Admission ( Rno INT PRIMARY KEY AUTO_INCREMENT, Name VARCHAR(25) NOT NULL, Gender ENUM('M','F'), Boolean_Valu boolean, Dob Date, Fees numeric(7,2) NOT NULL ); insert into Admission (Name,Gender,Boolean_Valu,Dob,Fees)values('Raj','M',true,'1990-07-12',50000); insert into Admission (Name,Gender,Boolean_Valu,Dob,Fees)values('Rani','F',false,'1994-05-10',15000); select * from admission;
wprowadź opis linku tutaj
źródło
Wybrałbym opcję 3, ale wiele kolumn bitowych NON NULLABLE zamiast jednej. IsMale (1 = Tak / 0 = Nie) IsFemale (1 = Tak / 0 = Nie)
jeśli wymagane: IsUnknownGender (1 = Tak / 0 = Nie) i tak dalej ...
Ułatwia to czytanie definicji, łatwą rozszerzalność, łatwą programowalność, brak możliwości użycia wartości spoza domeny i brak wymogu stosowania drugiej tabeli przeglądowej + ograniczeń FK lub CHECK w celu zablokowania wartości.
EDYCJA: Korekta, potrzebujesz co najmniej jednego ograniczenia, aby upewnić się, że ustawione flagi są prawidłowe.
źródło