Потому что это нарушает 3-ю нормальную форму. Вы хотите разделить все свои объекты как разные объекты, что означает, что вам нужна отдельная таблица, а также таблица отношений.

Нарушение данных

Если вы храните все это в одной таблице, вы размещаете слишком много нерелевантной информации о пользователе в пользовательской таблице. В таблице пользователя должны быть поля, относящиеся только к этому пользователю, такие как его имя, учетная запись пользователя и т. д. Но в этом случае вы решили добавить некоторую информацию о роли. Это не имеет смысла, поскольку вы добавляете атрибуты, которые не обязательно имеют какое-либо отношение к пользователю.

В результате вы начинаете добавлять поля, которые не относятся к пользователю, и в итоге получаете массу несвязанной информации. Решение этой проблемы состоит в том, чтобы иметь таблицу пользователей, например:

User table
UserID
User
...

Role table
RoleID
Role
....

User Role Table (the relationship)
UserRoles
UserID
RoleID
...

Обновление/вставка данных

Следующая проблема, с которой вам придется столкнуться, если вы храните информацию о ролях внутри пользовательской таблицы, — это как выполнять допустимые обновления и вставки. Это все усложняет. Когда вы редактируете запись, вы должны убедиться, что редактируете правильное значение из CSV.

Поиск подходящей роли

Здесь кроется самая сложная проблема, как найти роль, данную пользователю. Вы можете придумать эту замечательную технику синтаксического анализа на C# или SQL Server, она отлично работает... но становится ужасно медленной и трудной для чтения. Вы начинаете иметь дело с SubString(), Left(), Right(), Len() и целым рядом других функций только для того, чтобы проанализировать роль пользователя.

Решение

Вы можете подумать, что свести все это в одну таблицу сейчас проще. Вероятно, это займет намного меньше времени. Но вы должны разрабатывать приложения с расчетом на будущее. Пользовательский интерфейс будет намного проще, если вы будете следовать правилам 3nf и создадите красивую реляционную структуру. Мало того, что экраны администрирования пользовательского интерфейса будут выглядеть красиво, но получение роли для определенного идентификатора пользователя будет настолько тривиальным, в отличие от синтаксического анализа или поиска...

Я не думаю, что это отличный план. Предположим, вы вручную обновляете чьи-то роли и немного неправильно набираете имя роли? Если бы у вас была отдельная таблица, ограничение базы данных предупредило бы вас. Предположим, вы решили изменить название роли? Если бы у вас была отдельная таблица, вам нужно было бы изменить ее только в одном месте.

Нормализация базы данных выполняется по уважительным причинам; это не просто придирки. Вы не будете повторять ключевой код в своей кодовой базе более чем в одном месте; денормализация базы данных является эквивалентом.

EDITED TO ADD: Вы указываете, что приложение в конечном итоге будет принимать решения на основе значений, возвращаемых базой данных; например предоставление определенных опций, если у пользователя есть роль «Администратор». Это правда, и это еще одно отдельное место, где непротиворечивость, например, имен ролей может быть нарушена. Я не думаю, что денормализация базы данных делает это менее вероятным.

Один из хороших подходов, помогающих в этом (и хороший способ реализации авторизации в целом), состоит в том, чтобы иметь единое место в коде, где роль преобразуется в определенные общие возможности (например, администраторы могут читать и записывать все объекты, гости могут читать определенные объекты). и ничего не может написать и т.д.). Затем во многих местах, где вам нужно установить доступ, вы проверяете способность, а не роль.

То есть в представлении, если вы решаете, показывать ли кнопку «редактировать» в описании элемента, вы не проверяете, выполнив if role=='ADMIN' or role=='EDITOR', вы проверяете, выполнив if user.can_edit(item). Где-то еще вы установили, что администраторы и редакторы имеют возможность редактировать элементы. См., например, подход, который использует система авторизации Rails CanCan.

Используя этот подход, есть только одно место, где вы ссылаетесь на имена ролей (например, в CanCan у вас есть класс под названием «способности», который определяет все правила того, кто что может делать, исходя из их ролей). укажите, какие способности есть у пользователя, чтобы определить, что он может делать или видеть.

1. Вам нужна дополнительная логика для анализа вашего CSV на стороне кода.
2. Большинство ORM не поддерживает CSV.
3. Если у вас длинное имя роли (например, UserWhoHaveAccessToXObjButNotYObjAndAtTheSameTimeCanDoZ), то вы теряете место, повторяя его для всех пользователей.

Кроме того, ваше первое предположение справедливо не для всех ситуаций. Что, если МОЕЙ базе данных нужно знать о ролях?

Это зависит от того, хотите ли вы, чтобы система управления базами данных управляла данными, или вы хотите, чтобы приложение управляло данными. В большинстве случаев СУБД работает лучше, потому что для этого она и создана.

Ты сказал

Так почему бы просто не определить роли в приложении и только в приложении?

Вы можете сделать это надежно, только если честно скажете: «Я на 100% уверен, что каждый программист и каждый администратор базы данных вручную сохранит целостность данных, независимо от того, какое приложение прикасается к этой базе данных, независимо от того, на каком языке оно запрограммировано, независимо от того, насколько опытен или неопытен программист, и неважно, насколько сложной становится база данных, с этого момента и до конца ее жизни».

Если вы дойдете до того момента в своей карьере, когда будете управлять проектом по программированию, часть вашей работы будет заключаться в том, чтобы возложить обязанности по программированию на людей, которые лучше всего подходят для их выполнения. На архитектурном уровне кто-то также возлагает программные обязанности, такие как целостность данных, на модуль или подсистему, которые лучше всего подходят для их выполнения. Целостность данных может быть гарантирована только путем возложения этой ответственности на СУБД. Назначение его любой другой части системы, будь то код или человек, — это просто выражение надежды, а надежда плохо масштабируется.