Я занимаюсь разработкой пользовательского приложения SharePoint. В предыдущем проекте все данные были сохранены в списках SharePoint и так, как я пытался сейчас. Но я добираюсь до такой степени, что модель данных растет, и я чувствую необходимость ее нормализации и разделяю один логический объект на несколько физических списков. Мне интересно, следует ли мне переключаться с списков SP на классическую базу данных. С одной стороны, я доволен формами "Новый элемент", "Редактировать элемент", "Все элементы" SharePoint; с другой стороны, я опасаюсь, что производительность пострадает, когда мне придется запросить объединенные данные (если он остается в SPList s).
Если у вас есть понимание или опыт с этой проблемой, пожалуйста, поделитесь. Спасибо.
SharePoint: следует ли использовать списки или базу данных?
Ответ 1
Это зависит от ваших требований, но из моего опыта здесь приведены случаи, когда вы должны использовать базу данных вместо списков:
1) Когда у вас есть отношение "многие ко многим" в вашей модели базы данных
2) Когда у вас есть два или более объекта, связанные друг с другом (например, Клиент > Счет-фактурa > Продукт-фактура).
SharePoint велик, но в описанных выше сценариях возникают проблемы с ограничениями пользовательского интерфейса SharePoint.
3) Если вы планируете иметь какие-либо пользовательские отчеты или диаграммы, вы должны придерживаться своей собственной базы данных.
Когда вы используете сущности базы данных, лучший подход заключается в разработке собственных веб-частей, поскольку BDC является дорогостоящим и очень ограниченным для большинства случаев. Вы также можете проверить сторонние веб-части (например, веб-части Bamboo).
Ниже приведены причины использования списков SharePoint по базе данных:
- Права доступа
- Простота использования для конечного пользователя
- Изменить в таблице данных /Excel/Access
- Workflows
- Поиск
Ответ 2
Если у вас есть сложные запросы, я предлагаю вам поместить их в отдельную базу данных. Списки хороши, когда модель данных не растет так часто.
Расширение количества полей внутри столбцов списка включает в себя обновление ContentTypes напрямую с помощью STSADM, который вам придется кодировать. Однако запрос данных непосредственно из базы данных (с некоторым кешем, конечно) приведет к более быстрой разработке без необходимости обновления всех ContentTypes, связанных с каждым списком, связанным с ним.
Конечно, если вы активируете кеширование, данные, запрошенные из базы данных, будут кэшироваться на уровне вывода страницы.
Ответ 3
В дополнение к Максиму ответьте, я бы также посоветовал вам принять во внимание. Поиск OTB действительно хорош, если эти данные будут чем-то, что вам нужно будет копать.
Ответ 4
Я бы не стал слишком беспокоиться о том, чтобы перейти к пользовательской базе данных.
Это означает, что есть дополнительная работа, чтобы скинуть его с помощью настраиваемых элементов управления и ввести эти элементы управления на страницу макета и/или пользовательские веб-страницы, которые списки делают для вас.
Если у вас есть доступный BDC, это будет путь, в противном случае пользовательский.
Таким образом, в конечном итоге это компромисс между легкостью интеграции с sharepoint и наличием доступных форм ввода данных и кодированием всех этих элементов, но с полным контролем целостности данных.