none
Сравнение быстродействия SQL tables/Sharepoint lists RRS feed

  • Вопрос

  • Очень часто приходиться сталкиваться с желанием людей хранить данные не в списках sharepoint, а в базе данных MS SQL. Основеной аргумент этого подхода - быстродействие.

    Вполне очевидно, что грамотное хранение данных в БД и прямая работа с БД будет работать быстрее, чем работа со списками Sharepoint.

    Но насколько быстрее? Если это 10-20 процентов разницы, то это несущественно, и наличие подтверждения этой цифре является очень веским аргументом в пользу списков. А если 200-300%, то сами понимаете...

     

    В связи с этим вопрос - существует ли подобное сравнение быстродействия между хранением данных в БД или в списках Sharepoint?

    Прошу предоставить ссылки на это(желательно на сайте microsoft).


    Ivan Gorbadey. Sharepoint 2010 MCPD & MCITP.
    29 июля 2011 г. 13:43

Ответы

Все ответы

  • Думаю это зависит от данных которые собираетесь считывать.

     

    Тут ещё появится вопрос трудоёмкости решения считывающего данные из таблицы.

    Если использовать BCS - то списки SharePoint будут быстрее, если делать самим, то придётся реализовывать свой интерфейс.

    29 июля 2011 г. 13:50
  • Ок, с BCS более менее понятно.

     

    А как обстоят дела с прямой работой с БД(не BCS)? Речь о хранении в основном настраиваемых списков, а не документов.

    И без превышения рекомендуемых лимитов 2000 элементов на контейнер и т.п.

     

    Вопрос трудозатрат и возможностей out-of-the-box освещен довольно неплохо в инете, и я видел статьи на эту тему.

    Но трудозатраты не всегда являются решающим фактором при выборе способа хранения данных.

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


    Ivan Gorbadey. Sharepoint 2010 MCPD & MCITP.


    29 июля 2011 г. 13:56
  • Ок, с BCS более менее понятно.

     

    А как обстоят дела с прямой работой с БД(не BCS)? Речь о хранении в основном настраиваемых списков, а не документов.

    И без превышения рекомендуемых лимитов 2000 элементов на контейнер и т.п.

     

    Вопрос трудозатрат и возможностей out-of-the-box освещен довольно неплохо в инете, и я видел статьи на эту тему.

    Но трудозатраты не всегда являются решающим фактором при выборе способа хранения данных.

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


    Ivan Gorbadey. Sharepoint 2010 MCPD & MCITP.



    А с чего Вы взяли, что напрямую будет быстрее работать, чем с помощью SharePoint?

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

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

    Вот Вам ссылки:

    http://blogs.msdn.com/b/markarend/archive/2008/01/25/sharepoint-lists-as-datatables.aspx

    http://blog.solanite.com/keith/Lists/Posts/Post.aspx?ID=15

    http://sharepoint.microsoft.com/Blogs/GetThePoint/Lists/Posts/Post.aspx?ID=162


    Sergey A Belskiy - Microsoft® Most Valuable Professional Sharepoint Server, MCP, MCTS, MCPD || My blog || My Twitter || My Facebook || My Video
    30 июля 2011 г. 19:12
    Модератор
  • Сергей, добрый день.

    А с чего Вы взяли, что напрямую будет быстрее работать, чем с помощью SharePoint?

    К частью, мне нет необходимости логически обосновывать этот тезис, поскольку об этом написано в MSDN.

    В этой статье написано: In general, reading and writing to a custom database provides an overall performance advantage. Although SharePoint has made significant strides in its performance, there is still a certain amount of overhead involved in processing lists.

     

    За ссылки большое спасибо, количественные показатели быстродействия списков тоже могут выступать аргументом в пользу выбора списков Sharepoint.

    Однако в них также не содержится того самого числа, чему же в наиболее общих ситуациях равняется этот самый "certain amount of overhead involved in processing lists".


    Ivan Gorbadey. Sharepoint 2010 MCPD & MCITP.
    30 июля 2011 г. 22:07
  • Спасибо Иван за ссылку. Но всё же. Здесь множество факторов, которыми можно руководиться, чтобы выбрать правильный вариант решения. Если Вы архитектор, Вы должны много чего проанализировать. Вот статья - http://geekswithblogs.net/tmurphy/archive/2011/06/15/sharepoint-lists-vs.-database-tables.aspx

     

    А вот более расширенная таблица, на которую Вы давали ссылку - http://tihomirignatov.blogspot.com/2009/09/sharepoint-lists-vs-database-tables.html

    И вот ещё статья - SharePoint is not database - http://chriswoodill.blogspot.com/2009/05/sharepoint-is-not-database.html

     

    Так вот, если у Вас стоит задача создать простенькую таблицу, если она будет использовать только Sharepoint приложение, если не будет глубоких связей, если бла бла бла, можно много говорить, тогда лучше для производительности SharePoint.

     


    Sergey A Belskiy - Microsoft® Most Valuable Professional Sharepoint Server, MCP, MCTS, MCPD || My blog || My Twitter || My Facebook || My Video
    • Предложено в качестве ответа Alexey Entin 1 августа 2011 г. 8:21
    • Помечено в качестве ответа Ivan Gorbadei 1 августа 2011 г. 8:34
    31 июля 2011 г. 5:12
    Модератор