Файл против базы данных

Question

Я собираюсь реализовать Список контроля доступа для каждого отдельного пользователя, чтобы они могли назначать доступ к своим собственным ресурсам, чтобы они могли скрывать вещи, например, от своих матерей, но показывать друзьям.

Теперь хранение ACL в базе данных может показаться довольно безумным, если каждый пользователь также является группой, которая может иметь много подгрупп. Так что я думаю о хранении ACL в текстовом файле.

Хорошая идея? Плохая идея?

РЕДАКТИРОВАТЬ: я должен отметить, я говорю об отдельном текстовом файле для каждого пользователя. Я думаю о создании класса ACL, который я мог бы сериализовать и записать в текстовый файл. Я опасаюсь, что хранение ACL в базе данных приведет к созданию безумно огромных таблиц соединений и значительно увеличит нагрузку на сервер базы данных.

Answer 1

При наличии опции я буду хранить ACL в базе данных:

• Язык для доступа и запроса данных проще и стандартнее (SQL)
• БД предоставит вам транзакции, индексы для быстрого запроса, ограничения целостности и безопасность.
• В зависимости от того, как вы храните данные в локальном файле, вам может понадобиться переместить файлы данных вместе с вашим приложением. Пример: перемещение приложения с сервера1 на сервер2.
• Для данных, которые являются неизменными (или изменяются не часто), следует использовать некоторую форму кэша. Таким образом, независимо от того, используете ли вы File или DB, вы должны кэшировать некоторые из этих данных в течение некоторого периода времени.
• Я почти уверен, что вы можете найти хорошие шаблоны схем ACL для реляционной базы данных, которые вы можете использовать в качестве ссылки, например, здесь: http://edhs1.gsfc.nasa.gov/waisdata/v2r20/ps/cd31110001.ps

Надеюсь, это поможет.

Answer 2

Я боюсь, что хранение ACL в база данных создаст безумно огромный присоединиться к столам и поставить значительный нагрузка на сервер базы данных.

С одним текстовым файлом на пользователя и вашими группами / подгруппами, предположительно в некоторых других файлах, вам придется создавать свои собственные объединения, не так ли?

Проблема / требование, которое вы описали, как раз то, для чего хорош SQL. SQL - подходящий инструмент для работы, без вопросов.

Answer 3

Параллельность вас укусит. Как и сложность и снижение производительности, как файл становится больше. Как и повышенный риск повреждения чего-либо во время записи файла, например, сбой питания при сбоях системы.

База данных обычно защищает вас от этих проблем и позволяет сосредоточиться на логике

Вы можете реализовать иерархическое хранение в базе данных, используя самостоятельные объединения, например,

ItemID    Data   ParentID
--------------------------

Где ParentID - указатель на ItemID другой строки

Answer 4

XML идеально подходит для иерархических данных. Можно работать с иерархическими данными в базе данных, хотя это объясняет, насколько красиво (концепции применимы не только к MySQL):

http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/

Лично я не буду хранить такие данные в текстовом файле. Манипуляция становится намного сложнее.

Answer 5

Защищен ли ваш текстовый файл от одновременного доступа? В противном случае база данных будет лучшей идеей.

Answer 6

Я не уверен, как легче хранить его в текстовом файле. Отношения данных одинаковы. Конечно, SQL не всегда дружелюбные иерархические данные, но и не текстовый файл.