Где-то на заре 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Речь скорее о том, что версионник гораздо терпимее к промахам разработчиков ...
Это кто ж такую чушь сказал тебе?
Если разработчик дурак, то какую СУБД ему ни дай - он с ентой самой СУБД под мышкой устроит пляски по граблям.

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

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

vadiminfoavduТут важна не скорость, а стабильность работы, т.е. отсутствие зависаний и входов-выходов. В данном случае существенно лучше - настолько, насколько версионник лучше блокировочника.

Все же в плане блокировки пишущим пишущего Оракл блокировочник, и зависания таки встречаются на практике. То парни коммит на апдэйт забыли поставить, то индекс на внешнии ключи установить. Во втором случае, к примеру, некоторые операции блокируют изменение структуры таблы. Эти же операции при наличии индекса ничке не блокируют. Ну по крайней мере на 9 с таким сталкивался. Конечно, у Оракла моно быстро найти и исправить.
Кроме того, к зависанию могут приводить и клиентские проги.
Т.е. сказать, что Оракл совсем свободет от этого нельзя: не часто но бывает.

В нашей теперешней системе на Oracle года 4 все было Ок, потом после смены очередной версии
стало вдруг зависать на блокировках записей. Все мозги свернул вместе с разработчиками - ничего найти не можем. Ситуацию долго держать нельзя - система производственная, поэтому и поймать не удается. Единственно написал запрос, который ловит главного виновника - он выходит или нажимает commit и все Ок. Вот это уже конкретно - кривые руки разработчиков.

Dimitry Sibiryakov
avdu
стало вдруг зависать на блокировках записей. Все мозги свернул вместе с разработчиками -
ничего найти не можем.

А какого-нибудь параметра сессии или транзакции чтобы оно не ожидало освобождения чужого
лока, а сразу вываливалось с ошибкой у Оракула нет? Ну или хотя бы по таймауту...


Есть, только для deadlock. А это обычная штатная блокировка строки ...

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

Вот это куда серьезнее..
SQL 6.5 - 2000 вполне нормальные СУБд для своего времени..
Конечно если написали на теме Акссес и прилинковали таблички, то и оракл бы уронили...
Вопрос не в субд, а в способе применения..
По ходу провалился разработчик - проектировщик..
Причем серьезно..
400 пользователей.. это не торговая тема.. где накладные по 100 - 2000 строк.
Тут куда все легче..

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

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

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

3. надо ставить на 1 и тогда любую субд можно по Ваше описание подвести.

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

Вот это куда серьезнее..
SQL 6.5 - 2000 вполне нормальные СУБд для своего времени..
Конечно если написали на теме Акссес и прилинковали таблички, то и оракл бы уронили...
Вопрос не в субд, а в способе применения..
По ходу провалился разработчик - проектировщик..
Причем серьезно..
400 пользователей.. это не торговая тема.. где накладные по 100 - 2000 строк.
Тут куда все легче..

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

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

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

3. надо ставить на 1 и тогда любую субд можно по Ваше описание подвести.

Нет, не согласен. Для такой задачи (автоматизация налоговой) 2000 и тем более 6.5,
с которой все начиналось - СУБД откровенно слабые. Недаром ни одной серьезной банковской
системы, для крупных банков, особенно для работы с розницей, вы не найдете на MSSQL, даже
на 2005/2008. На Oracle - сколько угодно. Чтобы не спорить, назовите крупные банковские системы
на MSSQL.

andy stavdu...
На Oracle - сколько угодно. Чтобы не спорить, назовите крупные банковские системы
на MSSQL.
Извините за нескромный вопрос, но неужели Вас на www.google.com забанили ?
Изучаем

А я имел ввиду АБС российской разработки. Итак ...

andy stavdu...
На Oracle - сколько угодно. Чтобы не спорить, назовите крупные банковские системы
на MSSQL.
Извините за нескромный вопрос, но неужели Вас на www.google.com забанили ?
Изучаем

К тому же, помещать рекламу от Microsoft - моветон ...

andy stavdu[quot andy st]К тому же, помещать рекламу от Microsoft - моветон ...
зато открыто рекламировать Oracle - рулез форева? :)

Может мне попросить у Oracle денег за рекламу ?

А чего я буду изучать ссылки с сайта Microsoft. И хорошо, если бы там были указаны причины
перехода ?

andy stavduandy stavdu...
На Oracle - сколько угодно. Чтобы не спорить, назовите крупные банковские системы
на MSSQL.
Извините за нескромный вопрос, но неужели Вас на www.google.com забанили ?
Изучаем

А я имел ввиду АБС российской разработки. Итак ...
Типа руки российских разработчиков банковского софта лучше заточнены под оракул, чем сиквелсервер?


Мозги ...

Volochkovaavdu
Нет, не согласен. Для такой задачи (автоматизация налоговой) 2000 и тем более 6.5,
с которой все начиналось - СУБД откровенно слабые. Недаром ни одной серьезной банковской
системы, для крупных банков, особенно для работы с розницей, вы не найдете на MSSQL, даже
на 2005/2008. На Oracle - сколько угодно. Чтобы не спорить, назовите крупные банковские системы
на MSSQL.

А Вас никто в чужую веру обращать не собирается.
В мире происходят вещи вне зависимости, верите Вы в них или нет..
Банки до недавнего, а то и по сей день сидят на самописках C# + MSSQL
А есть система RS Balance - Знаете такую? Вообще под новелом крутится на btrieve..
И работает как надо.
Если Вы не пробовали устриц, не факт что оно не полезно, а испортить продукт дело не хитрое..
А так же есть тела, которые свято верят что Filemaker круче гор и оврагов :)
А сбер вообще на каких дос окошках работает
Ношу надо брать по себе, чтобы не падать при ходьбе..
По чесноку был переход с MS SQL 7 на 8 оракл.. фигня получилась...
Оракл, в данном случае, плохая субд? Это по Вашей логике.

Система RS-Bank, а не RS-Balance. Знаю, сам на ней работал в банке, именно на btrieve. А Сбер, как Вы, мадам, изволили выразится, по крайней мере нашего ФО, уже давно перешел с RS-Bank на ЦФТ, именно на Oracle, поскольку ЦФТ не на Oracle нет. Еще в 2004 году. А веру я менять не собираюсь, поскольку от рождения православный, им и помру. Впрочем, с женщинами спорить себе дороже.

MazoHistКогда-то я варился в этой кастрюле...
1. TCO. Сколько стоит купить ораклу на все ИФНС РФ? а настроить? а админить? и где в каком-нибудь Усть-Перепендюйске найти народ на это дело? А зарплаты у айтишников в ФНС чуть больше чем у уборщицы (не шучу). Да он свалит сразу.
2. Лоббирование M$. Сколько разговоров было про альтернативные системы? Нет. Никаких альтернатив, M$ only. Главное хранилище в те времена M$ не тянуло - поэтому там Oracle. на HPшном железе и HP-UX.

1. С тех пор многое изменилось. Теперь в налоговой, кроме зарплаты, платят еще и премию, которая бывает с зарплату размером. Судя по количеству машин на приколе у конторы, никто уходить не собирается. Сейчас увольнение из налоговой именно IT - явление редкое.
2. Речь идет о крупных нагруженных системах, а не о неких ООО, тут и MS SQL нужно настраивать и
админить, а вот это уже дело будет посложнее, чем Oracle, да и стоящей литературы поменее. К тому же налоговая давно имеет каналы связи, по которым все админится удаленно. Достаточно иметь 2-х достойных IT шников на регион.
3. МВД, ФМС, таможня, юстиция, Росреестр (права и кадастр), МЧС (!) - Oracle, и только налоговая на MS. Где тут лоббирование ?

iv_an_ruavduХороший пример неудачного выбора СУБД и неудачной реализации проекта. И неудачного выбора разработчика. Из дальнейшего описания вырисовывается некрупная "бюрократическая" системка без каких-либо нетривиальных кусков, которую можно слабать на любой "толстой" СУБД, равно как и на многих поделках попроще. 400 немудрячих пользователей и налоговая ерунда масштаба города --- при современном-то оборудовании не вопрос совершенно, были бы квалифицированные разработчики.

Налоговая системка, сама по себе вещь нетривиальная, как и наша налоговая система.

VolochkovaavduMazoHistКогда-то я варился в этой кастрюле...
1. TCO. Сколько стоит купить ораклу на все ИФНС РФ? а настроить? а админить? и где в каком-нибудь Усть-Перепендюйске найти народ на это дело? А зарплаты у айтишников в ФНС чуть больше чем у уборщицы (не шучу). Да он свалит сразу.
2. Лоббирование M$. Сколько разговоров было про альтернативные системы? Нет. Никаких альтернатив, M$ only. Главное хранилище в те времена M$ не тянуло - поэтому там Oracle. на HPшном железе и HP-UX.

1. С тех пор многое изменилось. Теперь в налоговой, кроме зарплаты, платят еще и премию, которая бывает с зарплату размером. Судя по количеству машин на приколе у конторы, никто уходить не собирается. Сейчас увольнение из налоговой именно IT - явление редкое.
2. Речь идет о крупных нагруженных системах, а не о неких ООО, тут и MS SQL нужно настраивать и
админить, а вот это уже дело будет посложнее, чем Oracle, да и стоящей литературы поменее. К тому же налоговая давно имеет каналы связи, по которым все админится удаленно. Достаточно иметь 2-х достойных IT шников на регион.
3. МВД, ФМС, таможня, юстиция, Росреестр (права и кадастр), МЧС (!) - Oracle, и только налоговая на MS. Где тут лоббирование ?

А пожары тушат так до революции.

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

VolochkovaavduVolochkovaavduMazoHistКогда-то я варился в этой кастрюле...
1. TCO. Сколько стоит купить ораклу на все ИФНС РФ? а настроить? а админить? и где в каком-нибудь Усть-Перепендюйске найти народ на это дело? А зарплаты у айтишников в ФНС чуть больше чем у уборщицы (не шучу). Да он свалит сразу.
2. Лоббирование M$. Сколько разговоров было про альтернативные системы? Нет. Никаких альтернатив, M$ only. Главное хранилище в те времена M$ не тянуло - поэтому там Oracle. на HPшном железе и HP-UX.

1. С тех пор многое изменилось. Теперь в налоговой, кроме зарплаты, платят еще и премию, которая бывает с зарплату размером. Судя по количеству машин на приколе у конторы, никто уходить не собирается. Сейчас увольнение из налоговой именно IT - явление редкое.
2. Речь идет о крупных нагруженных системах, а не о неких ООО, тут и MS SQL нужно настраивать и
админить, а вот это уже дело будет посложнее, чем Oracle, да и стоящей литературы поменее. К тому же налоговая давно имеет каналы связи, по которым все админится удаленно. Достаточно иметь 2-х достойных IT шников на регион.
3. МВД, ФМС, таможня, юстиция, Росреестр (права и кадастр), МЧС (!) - Oracle, и только налоговая на MS. Где тут лоббирование ?

А пожары тушат так до революции.

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

Зато патриции нынче с Ораклом

Есть такая поговорка - неладно скроен, но крепко сшит. Это про MS SQL. А про Oracle - и скроен ладно и сшит крепко. В последних своих комментариях на asktom.oracle.com гуру и вице-президент Oracle Том Кайт признал, что в настоящее время у Oracle 1 серьезный конкурент - MSSQL.

DorsajС системой в сабже был знаком лично в 2005 - 2007 гг. и админил и писал, многое там не нравилось но(!) не сточки зрения СУБД, а с точки зрения реализации. Написана она топорно и доставали бесконечные попытки заткнуть мелкие дырки драными тряпками

Мораль всего выше сказанного

Выбор СУБД он критичен, но с помощью любой из них можно добится хороших результатов если иметь руки идущие от головы

Ну так я это и говорил в предыдущих постах. Но если руки кривые и СУБД не очень - получается
Система ЭОД. В принципе выбор MS SQL 6.5 изначально - это те же самые руки, но идущие от жопы.

iscrafmavduandy stavdu...
На Oracle - сколько угодно. Чтобы не спорить, назовите крупные банковские системы
на MSSQL.
Извините за нескромный вопрос, но неужели Вас на www.google.com забанили ?
Изучаем

А я имел ввиду АБС российской разработки. Итак ...
неуклюжая попытка съехать.

Не впечатляет ...