2016-04-25 4 views
-1

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

В настоящее время мы используем WorkEffortParty объекта для хранения всех сторон, связанные с проектом, а затем PartyContactMech объекта для хранения адреса электронной почты. Здесь нам нужно каждый раз перебирать WorkEffortParty и PartyContactMech, чтобы получить весь адрес электронной почты, на который мы должны отправлять электронные письма для изменения билетов каждый раз.

Чтобы избежать этих итераций, мы теперь подумываем о предоставлении функции добавления разделенных запятыми адресов электронной почты на уровне проекта. Администратор проекта может добавлять адреса электронной почты связанных сторон или адрес списка рассылки, на которые ему нужно отправить уведомление по электронной почте для изменения билета.

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

ответ

0

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

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

Если вам нужно выйти за рамки этого, самый простой подход с помощью Moqui - использовать DataDocument и DataFeed для отправки обновлений «на лету» в ElasticSearch, а затем использовать его для ваших запросов и фильтрации большого объема (с произвольно сложной фильтрацией и т. Д. требования).

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

+0

Благодарим Вас за полезное руководство. Мы используем ** WorkEffortContactMech ** для решения этой задачи. Я попробую объяснить требование снова здесь. У нас есть требование, в котором нам нужно сообщать любые изменения в билете в приложение для управления проектами для предполагаемого набора пользователей, и мы хотели избежать итераций через сущность для получения адресов электронной почты предполагаемых сторон. Поэтому мы подумали о сохранении всех адресов электронной почты пользователей (разделенных запятыми) на уровне проекта, так что нет необходимости в каких-либо итерациях для получения адресов. Мы не были уверены, какое поле в модели данных мы должны использовать. – Pritam

Смежные вопросы