Я новичок в разработке sharepoint, надеюсь, мой вопрос имеет смысл,
с использованием sharepoint 2010, структура приложения, над которым я работаю, выглядит следующим образом:
- root семейства сайтов
- некоторые списки и типы контента, которые являются общими для всех сайтов ниже.
- сайт для работы с проектами x-типа
- сайт для работы с y-типомпроекты
- сайт для выполнения других вещей, не связанных напрямую с проектами, но может быть косвенным
если бы я разрабатывал приложение для традиционной базы данных, я бысущность BaseProject, и она будет различать подпроекты по полю projectType или даже будет иметь дочерние объекты, которые связаны 1-1 (вид наследования) с сущностью baseProject, если проблемы нормализации меня беспокоят.
окружающие предлагают иметь отдельные списки для проектов x, y, которые имеют разные рабочие процессы, шаблоны документов, разных пользователей и т. Д., И изолировать содержимое разных сайтов, сводить данные в отчетах, даже не задумываясь оПодобные наследованию отношения между сущностями, но это означает, что отношения от общих сущностей должны быть сделаны отдельно для различных списков проектов.и многие списки поиска будут повторяться вокруг разных списков объектов проекта.поэтому расширение модели данных будет затруднено в будущем.а для отчетов, которые интересуются всей областью применения, потребуется объединить списки, разбросанные по сайтам.
если я спроектирую списки так, чтобы они позже были более расширяемыми
только один список baseProject в корневом сайте со столбцом projectType: мне пришлось бы фильтровать все списки, содержащиебольше, чем мне нужно на конкретном сайте
один список baseProject на корневом сайте и подсписки для других типов проектов на под-сайтах: мне нужно синхронизировать данные между базовым спискоми подсписки.чтобы все элементы проекта были в списке baseProject.
вопрос в том, каковы наилучшие практики для создания списков sharepoint для моделирования наследования между сущностями?
в отношении ..