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

П>А аргументировать?

Ну когда аргументов нет — и минус кажется аргументом.

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

П>Ну когда аргументов нет — и минус кажется аргументом.

Просто не на всех они действуют.
Ну или не все их понимают

Softwarer wrote:

> C>Мы так делали,
> Хм. Из разового эксперимента может следовать возможность проблем, но
> не может — невозможность
> Все же вопрос, что именно делали. Я как-то приспосабливал программу
> Perl+MySQL, чтобы она запустилась на Oracle — на простенькую вещь из
> нескольких тысяч строк и нескольких таблиц ушел почти день.

В MySQL нет view'шек, триггеров, хранимых процедур — поэтому надо
править только запросы. В силу их примитивности это тоже обычно несложно.

> C> из проблем вспоминается только то, что в MySQL был слегка другой
> синтаксис для bulk insert.
> Хм. Признаться, не знал о наличии в Oracle специального синтаксиса для
> bulk insert, доступного не из хранимого кода.

Ну так и сделали, собственно говоря. Просто в MySQL можно в обычном
INSERT это делать.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

F> 5. Но если рассматривать сектор Embedded, то MSDE не является таким... OraExpress пожалуй тоже.

О! Это ты очень даже прав!.. Свежеустановленный OraExpress — это 1, 1 гига места на диске! И это экспресс?! А уж какой embedded — закачаешься просто!.. Куда там какому-то Firebird до такого embedded мегаэкспресс...

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

>> Хм. Признаться, не знал о наличии в Oracle специального синтаксиса для
>> bulk insert, доступного не из хранимого кода.

C>Ну так и сделали, собственно говоря. Просто в MySQL можно в обычном
C>INSERT это делать.

Что "это"? Я всю жизнь считал, что синтаксис insert и bulk insert в Oracle никак не отличается, если не считать дополнительно введенного в PL/SQL оператора forall. Можете показать, что вы писали на MySQL и на Oracle (по несколько строк, просто чтобы понять)?

Softwarer wrote:

> C>Ну так и сделали, собственно говоря. Просто в MySQL можно в обычном
> C>INSERT это делать.
> Что "это"? Я всю жизнь считал, что синтаксис insert и bulk insert в
> Oracle никак не отличается, если не считать дополнительно введенного в
> PL/SQL оператора forall. Можете показать, что вы писали на MySQL и на
> Oracle (по несколько строк, просто чтобы понять)?

Было что-то типа "INSERT INTO table1 VALUES (12,231,45), (243,435,123),
...." в Оракле оно так не заработало. Еще были маленькие проблемы с
разными именами типов, но больше ничего не вспомню такого фатального.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Было что-то типа "INSERT INTO table1 VALUES (12,231,45), (243,435,123),

За такое оракловские админы склонны отрывать разработчикам руки, если дотянутся Да, такое не заработает; можно сделать похожее через

insert into table1
select 12, 231, 45 from dual
union all select 243, 435, 123 from dual

Но вообще говоря, правильный bulk insert таки делается через

insert into table1 values (:a, :b, :c)

Например, из оракловой документации (пример на Pro*C)

int   emp_number[50]; 
float salary[50]; 
/* populate the host arrays */ 
EXEC SQL UPDATE emp SET sal = :salary 
    WHERE EMPNO = :emp_number;

C> но больше ничего не вспомню такого фатального.

Фатального нет, но чем сложнее проект — тем сложнее переносить.

Softwarer wrote:

> C>Было что-то типа "INSERT INTO table1 VALUES (12,231,45), (243,435,123),
> За такое оракловские админы склонны отрывать разработчикам руки, если
> дотянутся

Почему, кстати? Вроде бы ничего особого — для bulk'ов вполне сойдет.

> C> но больше ничего не вспомню такого фатального.
> Фатального нет, но чем сложнее проект — тем сложнее переносить.

Но это не причина сразу его делать на Оракуле.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

>> За такое оракловские админы склонны отрывать разработчикам руки, Почему, кстати? Вроде бы ничего особого — для bulk'ов вполне сойдет.

Потому что неиспользование bind variables в данном случае приводит к совершенно напрасным тратам процессора и памяти.

>> Фатального нет, но чем сложнее проект — тем сложнее переносить.
C>Но это не причина сразу его делать на Оракуле.

Смотря по ситуации

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

>> C> но больше ничего не вспомню такого фатального.
>> Фатального нет, но чем сложнее проект — тем сложнее переносить.

C>Но это не причина сразу его делать на Оракуле.

Совершенно справедливо: каждому серверу — собственная ниша, где именно он и нужен будет. Честно — ну не понимаю я людей, которые стараются воткнуть везде и непременно Оракла только потому, что это круто. А в чем тут крутость? Для огромного множества задач вполне сойдет и MS SQL, если не Firebird. Хотя, если оправдывать установку Оракла кривостью своих рук и неумением переписать код так, чтоб он работал, а не глючил, тогда конечно... Но, может быть, тогда нужно будет просто выгнать разработчика?

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

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

>>> C> но больше ничего не вспомню такого фатального.
>>> Фатального нет, но чем сложнее проект — тем сложнее переносить.

C>>Но это не причина сразу его делать на Оракуле.

H_I>Совершенно справедливо: каждому серверу — собственная ниша, где именно он и нужен будет. Честно — ну не понимаю я людей, которые стараются
воткнуть везде и непременно Оракла только потому, что это круто. А в чем тут крутость?

Не потому что круто, а потому что в будущем проблем не вызывает.

Для огромного множества задач вполне сойдет и MS SQL,

я бы понял если бы сказали "вполне сойдет и My SQL", а так получается что MS жалкая пародия на базу гыгы

если не Firebird. Хотя, если оправдывать установку Оракла кривостью своих рук и неумением переписать код так, чтоб он работал, а не глючил, тогда конечно... Но, может быть, тогда нужно будет просто выгнать разработчика?

Все СУБД разные. часто вижу топики, был Access хотим MS, был ХХ хотим YY потому что XX уже не справляется. Так вот зачем заранее себе яму копать? Я использую две базы MySQL и oracle. Какой мне резон разбираться еще с десятком заведомо менее "фичастых" СУБД, а потом сидеть и думать, блин, а вот в оракле я бы так написал и красота, а тут сиди и велосипед изобретай. Если я точно знаю кто ничего такого никогда не понадобится , (для веба обычно) ставлю mysql и вперед, хватает по самые помидоры. В итоге никогда не имел геммороя с переписывание приложений под другую субд, из-за того что ранее выбранная стухла.

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

M>я бы понял если бы сказали "вполне сойдет и My SQL", а так получается что MS жалкая пародия на базу гыгы
Да в общем-то что-то типа того. MS плохо держит нагрузку. Хотя, это возможно от кривости проектирования БД. Но БД не моя, и менять что-то внутри нее я не имею права. И получается, что при числе коннектов всего лишь 100-110 — тормоза. Не сильные, но неприятные. Аналогичные запросы на Oracle при том же числе коннектов выполняются в 3-4 раза быстрее. И это без специальной оптимизации. Да и функционал MS SQL все же бедноват.

Но я не про то. Я про то, что каждому серверу — свой круг выполняемых задач. Лично я тоже выбираю Oracle. Не по причине крутости, а по причине простоты реализации многих модулей. Я как-то привык, что есть пакеты. И я не ковыряюсь в тысячах ХП в поисках нужной. Процедуры/функции объединены в пакеты, пакеты объединены в бизнесы — и всех забот.

З.Ы. Предлагаю прекратить бесплодный спор. Выбор СУБД — это исключительно личное дело.

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

H_I>Но я не про то. Я про то, что каждому серверу — свой круг выполняемых задач. Лично я тоже выбираю Oracle. Не по причине крутости, а по причине простоты реализации многих модулей. Я как-то привык, что есть пакеты. И я не ковыряюсь в тысячах ХП в поисках нужной. Процедуры/функции объединены в пакеты, пакеты объединены в бизнесы — и всех забот.

H_I>З.Ы. Предлагаю прекратить бесплодный спор. Выбор СУБД — это исключительно личное дело.

Так об этом я и не спорил. Мне просто было интересно почему некоторые начинают думать так "я вот раьнше делала на Оракле (читай любой мощной СУБД-МСУБД ), а теперь мне задачку надо простеньку сделать, зачем мне МСУБД, когда можно взять мСУБД (мини), а потом обрести гемморой при расширении и наступить на грабли при изучении новой системы.

Только и всего.

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

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

C>>При этом embedded FireBird помещается в 2Мб. Сколько у нас Оракл минимум
C>>займет?

C>>Вообще, FB — это не самая фичастая база (никто и не спорит).


OLE>Блин, ну сколько можно. Человеку СУБД нужна для биллинга. Фаребирд не для этого.

А я таки согласен, что Firebird плохо подходит для биллинга. Если не ошибаюсь, задачи биллинга подразумевают массированные вставки данных. На таких задачах классические версионники, к числу которых относится Firebird, — не самый лучший выбор. Это связано с тем, каким образом данная СУБД хранит версии записей и делает операцию commit.
При частых операциях insert/update мусор в Interbase/Firebird накапливается быстрыми темпами, производительность довольно быстро падает. Если постановка задачи подразумевать какую-то фиксированную скорость в TPC, то в случае Firebird можно крепко огрестись. С PostgreSQL, кстати, похожая ситуация.

Цитата из Дмитрия Кузьменко, известнейшего авторитета по Interbase/Firebird:

Накопление мусора, конечно, влияет на производительность. Влияние может быть либо сильным либо слабым, все зависит как от количества накопленного мусора, так и от действий приложений. Известны редкие случаи, когда приложения удерживают активными очень много транзакций и производят очень много обновлений, и из-за накапливания мусора сервер начинает работать настолько медленно, что приходится его рестартовать (см. статью). Причем, замедление происходит как от чтения большого количества версий записей, так и от попыток их собрать как мусор. Больше всего влияет на скорость сборки мусора наличие неуникальных индексов — но эта проблема решена в InterBase 7.1 и Firebird 2.0.

http://www.ibase.ru/devinfo/garbage.htm

Вообще, благодаря Кузьменко, об архитектуре Interbase очень многое известно. Очень рекомендую данный ресурс:

http://www.ibase.ru/develop.htm

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

S>При частых операциях insert/update мусор в Interbase/Firebird накапливается быстрыми темпами, производительность довольно быстро падает.

Боюсь, я не авторитет по IB, поэтому прошу пояснить: с какой стати при insert накапливается мусор?

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

А>Здравствуйте, Softwarer, Вы писали:
А>просто нет многого привычного "хорошего".

А>- Можно 1 маленький пример: это можно и легко на Oracle и нельзя
А>(или с большими трудностями) на FireBird

Из остро необходимого для бизнес-задач — standby-сервер.

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

S>Боюсь, я не авторитет по IB, поэтому прошу пояснить: с какой стати при insert накапливается мусор?

Боюсь, что при INSERT — никак он не накапливается. Но подмечено, что массированная вставка большого количества данных в коротких транзакциях сильно тормозит. Выход — делать длинную транзакцию на большое количество инсертов. Однако, до коммита эти данные будут не видны (ну, если исключить "грязное чтение"). К тому же, если на таблице много индексов, то перестройка их тоже займет немало времени. ИМХО.

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

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

S>>При частых операциях insert/update мусор в Interbase/Firebird накапливается быстрыми темпами, производительность довольно быстро падает.

S>Боюсь, я не авторитет по IB, поэтому прошу пояснить: с какой стати при insert накапливается мусор?

Ха, вы поймали меня =) Действительно, мусор накапливается при update. При insert на массивных вставках в Interbase бывает другая проблема. Описана здесь: http://www.ibase.ru/devinfo/oitoat.htm

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

H_I>Боюсь, что при INSERT — никак он не накапливается. Но подмечено, что массированная вставка большого количества данных в коротких транзакциях сильно тормозит. Выход — делать длинную транзакцию на большое количество инсертов. Однако, до коммита эти данные будут не видны (ну, если исключить "грязное чтение"). К тому же, если на таблице много индексов, то перестройка их тоже займет немало времени. ИМХО.

Это уже никак не зависит от "классического версионника" и прочих подобных факторов. Это уже объективная задача, трудная в любой архитектуре. По крайней мере до 10gR2 "массированная вставка большого количества данных в коротких транзакциях" и ораклу будет ой как не по душе. В 10gR2 вроде бы сделали BATCH COMMIT, что может быть поможет в таких случаях (личных впечатлений пока нет).

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

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

H_I>>Боюсь, что при INSERT — никак он не накапливается.

S>Это уже никак не зависит от "классического версионника" и прочих подобных факторов.

Подчеркиваю, в оригинальном письме было "insert/update" написано. Что подразумевает не только массированную вставку, но и массированные изменения. И не надо переводить тему на более удобное для вас поле боя.