SharePoint: я должен использовать списки или базу данных?

Question

Я нахожусь в процессе разработки пользовательского приложения SharePoint. В предыдущем проекте все данные хранились в списках SharePoint, и я сейчас так пытаюсь. Но я дошел до того, что модель данных растет, и я чувствую необходимость ее нормализовать и разделить один логический объект на несколько физических списков. Мне интересно, стоит ли мне переключаться со списков SP на классическую базу данных. С одной стороны, я доволен формами «Новый элемент», «Редактировать элемент», «Все элементы» SharePoint; с другой стороны, я беспокоюсь о том, что производительность может снизиться, если мне придется запрашивать объединенные данные (если они остаются в SPList s).
Если у вас есть понимание или опыт с этой проблемой, пожалуйста, поделитесь. Спасибо.

Answer 1

Это зависит от ваших требований, но из моего опыта здесь приведены случаи, когда вы должны использовать базу данных вместо списков:

1) Когда у вас есть отношение многие ко многим в вашей модели базы данных

2) Если у вас есть два или более объекта, связанных друг с другом (например, Клиент> Счет-фактура> Продукт счета-фактуры).

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

3) Если вы планируете иметь какие-либо пользовательские отчеты или графики, вы должны придерживаться своей собственной базы данных.

Когда вы используете объекты базы данных, лучшим подходом является разработка ваших собственных веб-частей, поскольку BDC дорог и в большинстве случаев очень ограничен. Вы также можете проверить сторонние веб-части (например, Bamboo Web Parts)

---

Вот причины использования списков SharePoint поверх базы данных:

• Права доступа
• Простота использования для конечного пользователя
• Редактировать в таблице данных / Excel / Access
• * 1023 рабочих процессов *
• Поиск

Answer 2

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

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

Конечно, если вы активируете кэширование, данные, запрашиваемые из базы данных, будут кэшироваться на уровне вывода страницы.

Answer 3

Я бы не стал слишком беспокоиться о переходе в пользовательскую базу данных для данных.

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

Если у вас есть доступный BDC, это будет путь, в противном случае пользовательский.

Таким образом, в конечном итоге это компромисс между простотой интеграции с sharepoint и наличием доступных форм ввода данных по сравнению с кодированием всех этих элементов, но с полным контролем целостности данных.

Answer 4

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