none
Когда имеeт смысл создавать свою структуру полей в базе, а не использовать стандартные списки RRS feed

  • Вопрос

  • Планируется создание нескольких разделов со статьями на Портале Sharepoint 2013, основные поля:

    -Тема.

    -Дата

    -Текст статьи,

    -ФОТО (рисунок)

    И еще поля для каждого раздела свои будут добавляться, например, для раздела «Реклама» – поля «Проект» и «Группа». Разделов будет около 10, потом будут добавляться. На статьи будет использоваться функционал разграничения прав пользователей (кто-то может вносить, кто-то только смотреть), стандартный функционал комментариев.

    В каждом разделе статей максимум до 500 штук в год.

    Будет создаваться свой красивый дизайн для каждого раздела – что бы выглядели как на порталах в Интернет .

    Вопросы: Что лучше использовать:

    1.Стандартные настраиваемые списки куда просто добавлять новые поля.

    2.Создавать структуру полей непосредственно в СУБД, и получается создавать свои формы для отображения и редактирования.

    3. Вопрос встал в связи с дальнейшей эксплуатацией – скорость работы и использованием своего уникального дизайна и поддержкой решения.

    Программисты (новенькие, только изучают Sharepoint) хотят создавать поля для списков непосредственно в базе SQL.

    4. Я вижу, что такой подход сильно усложнит дальнейшую поддержку т.к. практически получается отдельное решение. По скорости работы, когда у нас в каждом списке будет в год до 500 записей – можно и стандартными настраиваемыми списками обойтись.

    5. Подскажите когда имеeт смысл создавать свою структуру полей в базе а не использовать стандартные списки? Я вижу что это только если очень много записей (Сколько ?), или это просто сложные формы элементов ?

    13 апреля 2017 г. 9:28

Ответы

  • Добрый день

    я бы при Вашем объеме элементов не использовал таблицы и поля SQL, проще использовать стандартный функционал SharePoint.

    Дело в том, что SharePOint предоставляет функционал, а при использовании SQL Вашим специалистам нужно будет разрабатывать свою модель предоставления прав, версионности (если требуется) и т.д.

    на мой взгляд имеет смысл переходить на SQL если количество элементов исчисляется десятками тысяч в месяц.

    но тут еще стоит учитывать много факторов:

    1. вашу IT инфраструктуру

    2. железо

    3. количество пользователей которые будут читать контент 


    мой блог не много о SharePoint

    13 апреля 2017 г. 9:43
    Модератор

Все ответы

  • Добрый день

    я бы при Вашем объеме элементов не использовал таблицы и поля SQL, проще использовать стандартный функционал SharePoint.

    Дело в том, что SharePOint предоставляет функционал, а при использовании SQL Вашим специалистам нужно будет разрабатывать свою модель предоставления прав, версионности (если требуется) и т.д.

    на мой взгляд имеет смысл переходить на SQL если количество элементов исчисляется десятками тысяч в месяц.

    но тут еще стоит учитывать много факторов:

    1. вашу IT инфраструктуру

    2. железо

    3. количество пользователей которые будут читать контент 


    мой блог не много о SharePoint

    13 апреля 2017 г. 9:43
    Модератор
  • >но тут еще стоит учитывать много факторов:

    >1. вашу IT инфраструктуру

    >2. железо

    >3. количество пользователей которые будут читать контент 

    Инфтраструктура - все на MS серверах (виртульных) домен AD, все ПО miсrosof используется, железо какое надо выделят для увеличения мощности это не проблема...

    Количество пользователей читающих будет не большое - несколько десятков в день на статью. Всего будет не более 800 пользователей вообще. 


    13 апреля 2017 г. 9:54
  • я бы даже не парился и не изобретал велосипед.

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


    мой блог не много о SharePoint

    13 апреля 2017 г. 10:45
    Модератор