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

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

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

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

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

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

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

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

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

Затем, когда пользователь вошел в основную панель управления, сетка будет включать соответствующие поля элементов в виде столбцов в сетке. Итак, из приведенного выше примера организация 1 увидит номер позиции, описание (будет отображаться для всех), цвет, объем и основного поставщика. Для организации 2 будет показан номер позиции, описание, цвет, тип запаса, цикл инвентаризации, код покупателя.

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


database tags tagging
person Community    schedule 11.11.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

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

  • Таблица: OrgTag

    Поля: OrgId, TagId

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

    Поля: TagId, TagTitle

  • Таблица: ItemTag

    Поля: ItemId, TagId

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

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

person Bill Karwin    schedule 11.11.2009
comment
Хотя этот дизайн немного сложнее, чем я ожидал, я хотел бы принять и его из-за ценных ссылок на детали схемы наблюдения, которые интересно изучать. спасибо Дамир. - person ; 13.11.2009

arrow_upward
1
arrow_downward

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

person Damir Sudarevic    schedule 11.11.2009
comment
На основе вашего описания я набросал упрощенную модель и объединил ее с моделью наблюдения < / а>. Это должно позволить вам отслеживать различные свойства элементов и пользовательские настройки для их просмотра. Разумеется, таблица _1_ может увеличиваться в размерах, но данные все равно нужно где-то хранить, и вы можете получить их с помощью sql, что упрощает бизнес-уровень.

- Организация и человек - это типы пользователей. В _2_ таблице есть столбцы, общие для всех пользователей, а в таблицах _3_ и _4_ есть столбцы, специфичные для каждого из них.
- Штатный товар (класс виджета) можно найти на нескольких сайтах (складах); сайт хранит множество товаров.
- Один элемент принадлежит одному пользователю; пользователь может владеть множеством элементов.
- Измерение и характеристика - это типы наблюдений. Измерение - это числовое наблюдение, например высота. Черта - это описательное наблюдение, например цвет.
- наблюдение относится к определенному типу (рост, вес, цвет), может быть много наблюдений одного и того же < сильный> тип.
- Один элемент (класс виджета) может иметь несколько наблюдений, наблюдение относится к одному элементу. Только.
- пользователь может предпочесть отображение множества наблюдений; наблюдение может быть предпочтительным (для отображения) многими пользователями.

orgspecific_model_01

ОБНОВЛЕНИЕ
Мы могли бы упростить подписку пользователя на сведения об элементе (наблюдения), отметив тип наблюдения, например рост, вес, ширина будет иметь теги: все, размеры, физический. Вот некоторые другие теги: account_interest, tracking_specific и т. Д. Тогда пользователь будет подписываться только на теги. Теги (могут) образовывать иерархию со ВСЕМИ наверху.

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

orgspecific_model_01A

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

orgspecific_model_01B - person ; 13.11.2009

arrow_upward
0
arrow_downward

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

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

Спасибо за указание на избыточность, Билл. Красивое чистое решение.

person Hemant Tank    schedule 11.11.2009