Абстрактные ссылки между сущностями

Question

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

В проекте есть требование контролировать доступ к различным объектам (логически: бизнес-объекты; физически: строки базы данных) различными людьми. Например, мы могли бы хотеть создать правила как:

• Пользователь Алиса является участником компании Z
• Пользователь Боб - менеджер группы Y, в которой есть пользователи Чарли, Дейв и Ева.
• Пользователь Франк может вводить данные для [критического бизнес-объекта] X, а также [критических бизнес-объектов] в [группе критических бизнес-объектов] U.
• Пользователь George не является членом Компании T, но может просматривать отчеты для Компании T.

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

В «традиционном» дизайне данных у нас могут быть такие сущности / таблицы:

• Пользователь
• Компания
• Ссылка пользователя / компании
• UserGroup
• Перекрестная ссылка на пользователя / группу пользователей
• CBO («Критический бизнес-объект»)
• Пользователь / CBO Cross-Reference
• CBOGroup
• Ссылка пользователя / CBOGroup
• Ссылка CBO / CBOGroup
• ReportAccess, который является перекрестной ссылкой между Пользователем и Компанией специально для доступа к отчетам

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

В предлагаемой системе все основные объекты (Пользователь, Компания, CBO) ссылаются на значение в новой таблице, которая называется Entity. (В коде мы, вероятно, сделаем все эти подклассы сущностей суперкласса сущностей). Тогда есть две дополнительные таблицы, которые ссылаются на сущность * Группа, которая также является сущностью "подкласс". * EntityRelation, который представляет собой отношение между двумя объектами любого типа (включая группу). Возможно, в этом поле также будет какое-то поле «Тип отношения», чтобы объяснить / квалифицировать отношение.

Эта система, по крайней мере на первый взгляд, выглядит так, как будто бы она соответствовала многим нашим требованиям. Мы могли бы представить новые сущности в будущем, но нам никогда не понадобилось бы создавать дополнительные таблицы для обработки группировки и отношений между этими сущностями, потому что Group и EntityRelation уже могут это обрабатывать.

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

У кого-нибудь есть опыт работы с подобной системой?

Answer 1

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

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

Например, вы уже знаете, что это может вызвать замешательство у пользователей и дизайнеров отчетов. Еще одним недостатком является то, что столбец «тип отношения» содержит только значащие строки для сущностей, участвующих в отношениях. Например. имеет смысл сказать Bob IsMemberOf UserGroup4, но что это значит, если CBO CanViewReportsOf Bob? Также, как вы предотвращаете взаимоисключающие условия, такие как Bob IsMemberOf Company1 и Bob IsMemberOf Company2?

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

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

Вы также определяете иерархические права доступа, например, если Bob CanViewReportsOf Company1, то сможет ли он просматривать отчеты какой-либо группы пользователей или CBO, являющейся членом этой компании? Или вам нужно ввести отдельную строку для отчетов каждой сущности, которые может прочитать Боб? Это проблемы политики, которые будут существовать независимо от того, какой дизайн вы используете.

---

Чтобы ответить на ваши комментарии:

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

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

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

Answer 2

У меня странный опыт с этим; что следующим образом:

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

Когда дело касается дизайна пользовательского интерфейса, клиент или пользователь настаивает на том, что реальное использование намного проще и будет удовлетворено этими двумя простыми экранами (пользователь / клиент рисует их на доска для вас, как вы слушаете).

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

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

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

Answer 3

На предыдущей работе мы пошли по тому же пути и в итоге эффективно реализовали разрешения типа активного каталога для объектов данных.

Каждая таблица, для которой требуются разрешения, будет иметь внешний ключ к таблице SecurityObject. Строки в таблицах UserPermission и GroupPermission указывают тип разрешений, которые были у разных пользователей для этой строки SecurityObject. Данные в таблице SecurityObject были иерархическими - каждая строка по умолчанию наследовала разрешения от своего родителя, если она была.

Соответствующие классы объектов данных реализовали общий интерфейс, чтобы API безопасности мог работать с любыми «защищаемыми» данными, не зная точно, что это было.

Компоненты пользовательского интерфейса для управления правами доступа группы и пользователя предоставили общий интерфейс для управления разрешениями объекта.

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

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

Это привело к довольно интенсивному кешированию данных с собственным набором проблем, если ваши приложения распределены по нескольким машинам.

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

Если бы я делал это снова, я бы обязательно использовал хранимые процедуры для проверки и управления объектами безопасности и разрешениями - настаивание на использовании объектов ORM, скорее всего, сделало мою работу намного сложнее:]

Answer 4

Ваше предложение Entity / Relation настолько мета, что оно будет достаточно гибким, чтобы справиться со всеми сумасшедшими перестановками - черт возьми, вы на расстоянии одного шага от одной таблицы с одним столбцом, который содержит путь к классу, который реализует это логика, если бы это было сделано - но, как вы заметили, непосредственное управление им привело бы к сумасшедшему замешательству. Чтобы скрыть всю абстракцию, вам нужно поместить на нее симпатичную обертку из уровня бизнес-объектов (re: одиночное наследование таблиц?). Но прежде чем пройти через все эти неприятности, ознакомьтесь с другими уже установленными системами. Большую часть времени я проваливаюсь в эту кроличью нору, и в итоге получаю разрешения файловой системы Unix , что неудивительно, что выдержало испытание временем.