Где-то на заре 1997 года в недрах налоговой службы зародился проект единой системы автоматизации, который позже получил название Система ЭОД. В 2000 году я имел "счастье" лицезреть сей продукт в неком городе на Волге. С какого-то перепугу для реализации проекта выбрали MS SQL 6.5, хотя в то время уже был Oracle 8. Это оказалось фатальным для системы. Внедрение этого продукта стало одной из причин моего покидания сего ведомства. Масштабное внедрение началось в 2001-2002 годах, уже на MSSQL2000. С тех пор и поныне, при посещении своей бывшей работы, я постоянно натыкаюсь на зависание системы. Было поменено несколько серверов, каждый раз покупался все более мощный, сейчас стоит самый мощный из того, что можно найти на Win. В течение времени, пока находишься там, постоянно раздаются возгласы - система зависла, выйдите все и т.п. С интересом ждал момента перевода ее на MSSQL2005/2008, не знаю перевели или нет, но проблема зависаний осталась.
Хороший пример неудачного выбора СУБД и неудачной реализации проекта. И неудачного выбора разработчика.

Причин неудачи я вижу три

1. Неудачный выбор СУБД (MSSQL тогда - блокировочник)
2. Неудачная структура данных, изначально написанная под блокировочник
3. Неудачный разработчик, что, впрочем, породило и пп.1 и 2.

p.s. Одновременно работающих пользователей > 400

Нет, я не хочу сказать, что если бы ВСЕ и ВСе писали на Oracle, то все бы идеально работало.
Прросто я хочу сказать, что если бы конкретная Система ЭОД была написана на Oracle, при сохранении 2 остальных пунктов, ситуация была бы существенно лучше.

Тут важна не скорость, а стабильность работы, т.е. отсутствие зависаний и входов-выходов. В данном случае существенно лучше - настолько, насколько версионник лучше блокировочника.
То, что система работает так долго - не показатель, а, в общем, наплевательское отношение
заказчиков к своим пользователям. Где нибудь на западе проект давно бы признали не успешным и переделали. У нас и государство не успешное - никто же его не переделывает.Цепочки разработчиков не было, есть один - некий ФГУП в системе налоговой службы. Хотя, в общем, насчет студентов верно.

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

P.S. Меня из службы не выпирали, действительно, сам ушел, на Oracle. О чем не жалею.

iscrafm ... Явно есть пробелы в проектировании. При помощи другой субд можно только скрыть их.

Вот об этом речь и шла, о чем тут спорить ?

iscrafmсмысл темы в итоге?

Смысл был такой - что думают об этом сами, кто сейчас систему эксплуатируют? Если
он и этот сайт посещают.

[quot iscrafm ...акцент сделан на том, что замена СУБД решит все проблемы, а это немного не о том.[/quot]
Речь скорее о том, что версионник гораздо терпимее к промахам разработчиков ...

ЛПavduРечь скорее о том, что версионник гораздо терпимее к промахам разработчиков ...
Это кто ж такую чушь сказал тебе?
Если разработчик дурак, то какую СУБД ему ни дай - он с ентой самой СУБД под мышкой устроит пляски по граблям.

И ежели вдруг разработчик-дурак-плясун-по-граблям перешёл с СУБД А на СУБД В, то в лагере А только вздох облегчения :)

А вот это верно ...