Здравствуйте, sharpcoder, Вы писали:

S>Мы давно сделали для списков генерацию DataView в MS SQL. Т.е. с ними можно работать через SQL и со скоростью SQL Server'а (выбор из 10 млн. элементов за 0.1 сек, например).

S>Тормозят не списки, а стандартные представления. Зачем их использовать если данных много? У наших списках лежит до 500 тыс. записей в одной папке, и это открывается быстрее чем за 0,5 сек.

S>Без проблем. Обращаясь к DataView можно писать любыз запросы на SQL Reporting Services, на SAP BI и даже на Cognos'е.

S>Все тривиально. Есть простые инструменты типа Nnintex. Есть доступ к спискам через веб-службы и возможность юзать бизтоки и т.п.

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

S>??? Ldap провайдер есть, SQL бери-нехочу, HTML — и так все на нем.
S>В общем самый главный поддерживаемый стандарт это C#!

HL>>Короче, почти все компании, которые думают что СП — это бизнес-платформа, рано или поздно уходят с неё на что-нить кастомное или на что-нить более приличное.
S>Замечено обратное. У нас есть проекты где клиенты выбрасывают в помойку почти все, что было до этого (один клиент выкинул 13 систем стоимостью 100 млн.р.) и все это делают на шарике.

Я вот только не понял все утверждения до этого утверждали о том,что платформа под Sharepoint — это всё, что угодно:
— SSRS,
— .NET (ASP.NET, ADO.NET, C#.NET и пр.)
— SQL
— HTML
— LDAP
кроме чего-то из (стандартного) функционала Sharepoint,
а потом "замечено обратное"?!

Правильно ли я понял умозаключения, что платформа разработки решений на/под Sharepoint — это (совсем и) не (стандатный, и не функционал) Sharepoint?
Я, наверное, повторяюсь с этим вопросом

Здравствуйте, sharpcoder, Вы писали:

S>нам тут ребята из ООО ХХХ сделали портал и автоматизировали пару процессов, все убого и хреново, сделайте что нибудь чтобы мы были счастливы". Мы начинаем смотреть что им сделали и начинают волосы на затылке шевелиться. Большая часть решений так спроектирована, что вообще не может работать с нормальным количеством данных. Иногда такой ацкий замес из стандартного функционала, что даже не понятно как это работает, и как клиент осуществлял приемку работ.

Т.е.?
Правильно ли я понял, что:
— пользуясь Ыharepoint, нужно уметь избегать его и обходиться без его функционала?
— Sharepoint — это не платформа, а коробочный продукт?
— Sharepoint который не стоит применять не по назначению?

Соответственно, вопросы:
— какие из функциональности Sharepoint отсутствуют в других продуктах и довольно сложно было бы воспроизвести с "нуля"
(т.е., используя платвормы .NET и BI MS SQL Server)?
— какими доводами Вы представите клиенту необходимость использования именно Sharepoint,
а не чего-то другого?
— в каких случаях не имеет смысла применения Sharepoint
(Например, если в компании — гетерогенная среда — одни работают Windows, Unix (Linux), etc. — есть там место для Sharepoint?
Такие среды я наблюдал даже в очень маленьких компаниях, до 10 работников, — часть пользователей и серверов (обших сервисов) на Windows, часть — на Linux)
— какие сценарии существующих бизнес-процессов лучше всего (идеально) подходят для применения Sharepoint

Здравствуйте, Она На Нас Ий, Вы писали:

ОНН>Здравствуйте, sharpcoder, Вы писали:

S>>нам тут ребята из ООО ХХХ сделали портал и автоматизировали пару процессов, все убого и хреново, сделайте что нибудь чтобы мы были счастливы". Мы начинаем смотреть что им сделали и начинают волосы на затылке шевелиться. Большая часть решений так спроектирована, что вообще не может работать с нормальным количеством данных. Иногда такой ацкий замес из стандартного функционала, что даже не понятно как это работает, и как клиент осуществлял приемку работ.

ОНН>Т.е.?
ОНН>Правильно ли я понял, что:
ОНН>- пользуясь Ыharepoint, нужно уметь избегать его и обходиться без его функционала?

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

ОНН>- Sharepoint — это не платформа, а коробочный продукт?

Именно платформа. Которая сама по себе почти никакие задачи не решает.

ОНН>- Sharepoint который не стоит применять не по назначению?

Именно по назначению. Просто когда доходит до кастомизации, нужно ее уметь делать так, чтобы она работала хорошо.

ОНН>Соответственно, вопросы:
ОНН>- какие из функциональности Sharepoint отсутствуют в других продуктах и довольно сложно было бы воспроизвести с "нуля"
ОНН>(т.е., используя платвормы .NET и BI MS SQL Server)?

Можете относиться к шарику просто как к application-серверу. Посмотрите на конкурентов (SAP Portal, IBM Websphere, Oracle AS Portal) — там вообще нет своего функционала, кроме того, что они могут хостить портлеты (+ есть несколько портлетов для своих продуктов).

ОНН>- какими доводами Вы представите клиенту необходимость использования именно Sharepoint, а не чего-то другого?

Этим занимается Microsoft.

ОНН>- в каких случаях не имеет смысла применения Sharepoint

Не знаю. По мне — Sharepoint хорош для любых ситуаций.

ОНН>(Например, если в компании — гетерогенная среда — одни работают Windows, Unix (Linux), etc. — есть там место для Sharepoint?

Есть. Но с ограниченным функционалом.

ОНН>Такие среды я наблюдал даже в очень маленьких компаниях, до 10 работников, — часть пользователей и серверов (обших сервисов) на Windows, часть — на Linux)

Маленькие компании не пример для подражания.

ОНН>- какие сценарии существующих бизнес-процессов лучше всего (идеально) подходят для применения Sharepoint

Это тема отдельного разговора.

Здравствуйте, Романов Михаил, Вы писали:


РМ>Но, как я уже сказал, в целом вы правы, попытка внедрения ЭДО — это попытка найти "серебряную пулю". Люди надеются что магическим образом разгребут неразбериху царящую с документами у них.

Классика жанра: результатом автоматизации бардака всегда становится автоматизированный бардак.