Jeśli użytkownik może mieć wiele ról, prawdopodobnie lepiej mieć user_role
tabela przechowująca te informacje. Jest znormalizowany i będzie znacznie łatwiejszy do wyszukania.
Stół taki jak:
user_id | role
--------+-----------------
1 | Admin
2 | User
2 | Admin
3 | User
3 | Author
Umożliwi wysyłanie zapytań dla wszystkich użytkowników z określoną rolą, na przykład SELECT user_id, user.name FROM user_role JOIN user WHERE role='Admin'
zamiast używać parsowania ciągów w celu uzyskania szczegółów z kolumny.
Będzie to między innymi szybsze, ponieważ można prawidłowo indeksować kolumny i zajmie niewiele więcej miejsca niż jakiekolwiek rozwiązanie, które umieszcza wiele wartości w jednej kolumnie - co jest przeciwieństwem tego, do czego są zaprojektowane relacyjne bazy danych.
Powodem, dla którego nie powinno to być przechowywane, jest to, że jest nieefektywny, ponieważ DCoder stwierdza w komentarzu do ta odpowiedź . Aby sprawdzić, czy użytkownik ma rolę, każdy wiersz tabeli użytkownika będzie musiał zostać przeskanowany, a następnie kolumna „role” będzie musiała zostać przeskanowana przy użyciu dopasowania ciągów — niezależnie od tego, jak ta akcja zostanie ujawniona, RMDBS będzie musiał wykonaj operacje na ciągach, aby przeanalizować zawartość. Są to bardzo kosztowne operacje i wcale nie dobry projekt bazy danych.
Jeśli potrzebujesz aby mieć jedną kolumnę, zdecydowanie sugerowałbym, że nie masz już problemu technicznego, ale problem zarządzania ludźmi . Dodawanie dodatkowych tabel do istniejącej bazy danych, która jest w trakcie opracowywania, nie powinno być trudne. Jeśli nie jest to coś, do czego jesteś upoważniony, wyjaśnij, dlaczego dodatkowy stół jest potrzebny właściwej osobie — ponieważ mung wiele wartości w jednej kolumnie jest złe, złe pomysł .