Причина, по которой вы организовываете данные таким образом, связана с шаблоном доступа (как вы используете данные). Краткий ответ - если вы получите доступ к своим данным только одним способом, структура будет быстрее. Насколько быстрее? Для приведенных примеров это будет тривиально, возможно, несколько миллисекунд сохранятся в базе данных. Если бы вы перешли к структуре 2 и все еще имели менее 10000 строк, разница в производительности, как правило, тоже была бы незначительной.
Разница в производительности стала бы более существенной, если бы структура 1 имела, скажем, 100 000 строк, а структура 2 требовала, например, 1 000 000 строк для хранения тех же данных. Затем, в зависимости от сложности вашего запроса и количества возвращаемых строк, вы, вероятно, заметите разницу во времени выполнения запроса в сотни миллисекунд с точностью до секунды.
Давайте посмотрим, почему, возьмем следующий запрос:
SELECT permission
FROM perm
WHERE role = 1
Преимущества конструкции 1:
Возвращается одна строка для каждой роли, хранящаяся в одном месте на диске. Время поиска диска сокращено.
Недостатки конструкции 1:
Что если мы хотим найти все роли, которые имеют права на редактирование? Это немного сложно, нам (или базе данных) нужно обрабатывать записи - что сильно загружает процессор. Так что это серьезный недостаток, но ... Если мы никогда не получим доступ к данным таким образом, или мы получим к нему доступ очень редко, и готовы согласиться с затратами, тогда это не имеет значения.
Преимущества конструкции 2:
Поскольку данные нормализованы, легко найти все разрешения, которые принадлежат роли, или все роли, у которых есть разрешение. Это гораздо более гибкая структура.
Недостатки конструкции 2:
Учитывая вторую структуру, записи, составляющие разрешения для каждой роли, потенциально хранятся в разных местах на диске. Это означает, что для очень больших таблиц производительность будет хуже, чем у структуры 1.
Вывод:
Структура 1, вероятно, была выбрана для обеспечения (очень незначительной) лучшей производительности с учетом того, как используются данные. Это немного сложнее (отсюда и вопрос о том, почему было принято это дизайнерское решение). Drupal 7, вероятно, пошел со структурой 2, потому что это проще, а разница производительности незначительна в общем случае.