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

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

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

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

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


file text database acl
person gargantuan    schedule 10.02.2009    source источник

Ответы (6)


arrow_upward
3
arrow_downward

Учитывая вариант, я бы сохранил ACL в базе данных:

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

Я надеюсь, что это помогает.

person Handerson    schedule 10.02.2009

arrow_upward
0
arrow_downward

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

person Joe    schedule 10.02.2009

arrow_upward
0
arrow_downward

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

person Toon Krijthe    schedule 10.02.2009

arrow_upward
0
arrow_downward

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

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

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

person Community    schedule 10.02.2009

arrow_upward
0
arrow_downward

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

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

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

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

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

person Rad    schedule 10.02.2009
comment
Вложенные деревья обычно являются лучшей моделью для хранения иерархических данных, чем списки смежности. Это может представлять интерес: dev.mysql.com/tech-resources/ статьи/hierarchical-data.html - person ; 10.02.2009

arrow_upward
0
arrow_downward

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

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

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

person David Easley    schedule 14.02.2009