Как настроить специфичные для организации элементы данных об общих элементах?

Question

Первое сообщение, пожалуйста, будьте добры.

ПРИМЕЧАНИЕ. Я просмотрел запись № 20856 (как реализовать тегирование), но чувствую, что это не так, потому что метод тегов, который я рассматриваю, зависит от конкретной организации в моем приложении. Я надеюсь, что кто-то может подтвердить направление, в котором я иду, или указать другие варианты.

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

Обычно две (или более) организации хотят использовать портал для проверки состояния запасов (например) виджета A на складе в Лос-Анджелесе. Эта часть в порядке. Однако различные организации также отслеживают уникальную информацию о виджете А. Например, организация 1 хочет отслеживать цвет, объем и основного поставщика для каждого элемента. Орг 2 хочет отслеживать цвет, тип запаса, инвентарный цикл, код покупателя для каждого товара. Я хочу избежать ситуации, когда мне нужно загрузить таблицу со всеми этими возможными полями, а затем выяснить, какие организации используют какие поля.

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

Таблица: OrgTagCategory
Поля: OrgId, TagCategoryId, CategoryTitle

Таблица: OrgTag
Поля: OrgId, TagCategoryId, TagId, TagTitle

Таблица: OrgItemTag
Поля: OrgId, ItemId, TagId

Тогда, когда пользователь войдет в основную панель мониторинга, сетка будет включать в себя соответствующие поля элементов в виде столбцов в сетке. Таким образом, из вышеприведенного примера Org 1 будет видеть Item #, Description (будет показано для всех), цвет, объем и основного поставщика. Будет отображаться Org 2 № изделия, описание, цвет, тип запаса, инвентарный цикл, код покупателя.

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

Answer 1

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

- Организация и человек являются типами пользователей . В таблице User есть столбцы, общие для всех пользователей , а в таблицах Organization и Person есть столбцы, специфичные для каждой из них.
- Склад предмет (класс виджетов) можно найти на нескольких сайтах (склады); сайт хранит множество предметов .
- Один элемент принадлежит одному пользователю ; пользователь может владеть многими элементами .
- Измерения и признак являются типами наблюдений. Измерение - это числовое наблюдение, как высота. Черта - это описательное наблюдение, похожее на цвет.
- наблюдение имеет определенный тип (рост, вес, цвет), может быть много наблюдений одного и того же типа .
- Один элемент (класс виджетов) может иметь множество наблюдений , наблюдение относится только к одному элементу .
- A пользователь может предпочитает отображать множество наблюдений ; наблюдение может быть предпочтительным (для отображения) многими пользователями .



UPDATE
Мы могли бы упростить подписку пользователя на детали товара (наблюдения), пометив тип наблюдения , например, рост, вес, ширина будут помечены: все, размеры, физические. Некоторыми другими тегами могут быть: accounting_interest, tracking_specific и т. Д. Затем пользователь будет подписываться только на теги. Теги (могут) формировать иерархию с ALL наверху.

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



ОБНОВЛЕНИЕ 2
Теперь мы можем разобраться, кто есть кто, а кому что принадлежит. В этой модификации пользователь (теперь человек) может работать в нескольких организациях (имеющих несколько рабочих мест или контрактов с частичной занятостью). предмет принадлежит организации сейчас. Зарегистрированный пользователь может видеть все элементы из всех организаций, в которых он работает.

Answer 2

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

Вот как бы я это сделал:

• Таблица: OrgTag

  Поля: OrgId, TagId

• Таблица: тег

  Поля: TagId, TagTitle

• Таблица: ItemTag

  Поля: ItemId, TagId

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

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

Answer 3

Моим первым быстрым объяснением этого было бы то, что - если это просто ограничивается «показом» определенных полей отдельным Оргам на панели инструментов, то лучше справиться с этим на стороне приложения. Если есть какое-либо другое использование тегов, то уточните.

Вот простой подход - Вы можете сохранить поле [OrgDashboardFields] в основной таблице Org или в таблице OrgItem. Это будет список полей, разделенных запятыми (','), которые будут отображаться на панели инструментов. Во время выполнения извлеките поле [OrgDashboardFields] и проанализируйте разделенный запятыми список в приложении и заставьте сетку панели мониторинга вести себя соответствующим образом.

Или, если есть структура динамического запроса, то на основе поля [OrgDashboardFields] вы можете создать динамический SQL-запрос и получить желаемый результат, который является чисто специфическим для Org.