Здравствуйте, Vasiliy_Krasnokutsky

Мне, например, очень нравится такое преемущество Oracle, как select for update.
И, по моему, в SQL сервере такого нет.
Хотя, я был бы признателен, если мне кто-то скажет, как это проще всего сделать в MS SQL

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

А>да я не особо и радуюсь, за это мне не платят
Такое ощущение, что все-таки платят..

А>я в который раз хочу намекнуть, что преимущество в скорости — маркетинговая лажа, ни чем не потвержденная,
Это не маркетинговая лажа, а объективная реальность. Подтвержденная и практикой и теорией.

А> даже накрученые тесты (совершенно сиснтетические),
Когда лет пять-шесть назад Оракл там более менее уверенно лидировал тесты были не синтетическими, а самыми настоящими... клева..

А>речь о сиквере ?
Нет, об Оракле.

А>про оракл знаю, даже знаю что за ресурсы будут расходоватся — блокировки, ну так если нада их можно на всю базу понатыкать, места на диске от этого меньше не станет. Если требует бизнес правило, то транзакция будет такой длины какой нужно (C) Tom Kyte. Еще роллбэк сегменты сожрут диск, ну и что ?
Вот сейчас ты открытым текстом рассказал, что даже про Оракл ничего не знаешь.
Фиг с ним, что тебе про MS "рабинович по телефону насвистел", еще можно было бы о чем-то поговорить, но ты даже про Оракл информацию берешь из тех же маркетинговых статей... Так какой смысл тебе чего-то объяснять? Если у меня возникнет желание индукцию с дедукцией через редукцию скрещивать, я к первоисточникам пойду, а здесь — увольте.

А>нет ... не работают, разве что грязное чтение применив ...
Я уже устал десять раз объяснять, интересно — пользуйся поиском.

А>P.S. так я не понял модель — единственое преимущество ?
Нет.

А> и можно все таки узнать где и как енто преимущество проявляется ?
В любом, более менее грамотно написанном приложении.

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

S>Здравствуйте, Vasiliy_Krasnokutsky

S>Мне, например, очень нравится такое преемущество Oracle, как select for update.
S>И, по моему, в SQL сервере такого нет.
S>Хотя, я был бы признателен, если мне кто-то скажет, как это проще всего сделать в MS SQL

select * from [table] with(updlock)

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

S>Мне, например, очень нравится такое преемущество Oracle, как select for update.

Это не преимущество — это заплатка..
В некоторых случаях, когда необходимо, чтобы читающие запросы все-таки блокировали пишущие, и применяется for update.

S>И, по моему, в SQL сервере такого нет.
Есть...
with (holdlock), with (updlock) или with(xlock) в зависимости от необходимой строгости блокировки и уровня изоляции.

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

M>В некоторых случаях, когда необходимо, чтобы читающие запросы все-таки блокировали пишущие, и применяется for update.
Да, я это прекрастно понимаю, и знаю, что пишушие запросы должны блокировать читающие только в редких случаях.

M>Это не маркетинговая лажа, а объективная реальность. Подтвержденная и практикой и теорией.
чьей практикой млин ? практика САМЫХ уважаемых организаций tpc.org sap.com грит совсем о другом, или речь о практики Васья Пупкин ?

А>>про оракл знаю, даже знаю что за ресурсы будут расходоватся — блокировки, ну так если нада их можно на всю базу понатыкать, места на диске от этого меньше не станет. Если требует бизнес правило, то транзакция будет такой длины какой нужно (C) Tom Kyte. Еще роллбэк сегменты сожрут диск, ну и что ?
M>Вот сейчас ты открытым текстом рассказал, что даже про Оракл ничего не знаешь.
M>Фиг с ним, что тебе про MS "рабинович по телефону насвистел", еще можно было бы о чем-то поговорить, но ты даже про Оракл информацию берешь из тех же маркетинговых статей... Так какой смысл тебе чего-то объяснять? Если у меня возникнет желание индукцию с дедукцией через редукцию скрещивать, я к первоисточникам пойду, а здесь — увольте.

ОК, давай я еще раз носом тыкну ! давай так — я заявлю что я получу тормоза если в оракле буду в место одной дилинной транзакции использовать много. ну давай табличка на 10 млн, а нужно проапдейтить 1 млн.
жду просто ответа "нет" и в ответ просто процетирую кусок Tom Kyte

Gt_

Здравствуйте, Vasiliy_Krasnokutsky, Вы писали:
V_K>прошу прощения если вопрос не по адресу, но меня интересует сравнительный анализ разработки под Oracle с разработкой под MSSql.
V_K>Если можно сравнение средств разработки, достоинства и недостатки той или иной базы данных.

IMHO.
Сравнение этих двух БД бесполезно, так как это обсуждение может затянуться на очень большое время, и все равно ни чего, кроме оскорблений и ругательств не даст.
Все останутся при своем мнении.
По моему скромному мнению, из этих двух БД, Вам, надо выбирать ту, с которой именно Вам будет проще разобраться, т.е. по какой БД у Вас больше информации, больше книжек, больше знакомых, знающих эту БД и могущих быстро помочь в случае какого-нибудь небольшого затруднения.
Сравнение производительности работы Oracle и MS SQL Server, для Вас вообще не должно играть ни какой роли. Разницу в производительности в своих приложениях, я уверен, Вы не заметите.

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

А>чьей практикой млин ? практика САМЫХ уважаемых организаций tpc.org sap.com грит совсем о другом, или речь о практики Васья Пупкин ?
Во первых ты определись, tpc самая уважаемая организация или все-таки синтетические тесты?
Во вторых подтверждается именно практикой tpc и sap, не говоря уже о практике всех васей пупкиных, которым пришлось писать более-менее серьезное приложение и под версионник, и под блокировочник.
В третьих, сравнивая модели на sap ссылаться несколько не корректно, так как там реализован свой собственный менеджер транзакций.

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

А>давай так — я заявлю что я получу тормоза если в оракле буду в место одной дилинной транзакции использовать много. ну давай табличка на 10 млн, а нужно проапдейтить 1 млн.
Слов нет..
Давай ты лучше сначала с терминологией определишься?
Вот этот вот твой пример не есть "длинная транзакция". То есть ты опять споришь, но не понимаешь о чем речь идет — это нормально?
К слову твой любимый Том Кайт, в данной ситуации, рекомендует принудительно блокировать всю таблицу, потому как иначе Ораклу тяжко придется.

А>жду просто ответа "нет" и в ответ просто процетирую кусок Tom Kyte
Ранее за тобой ни одной, цитаты к месту не наблюдалось. Такое впечатление, что ты выдергиваешь куски из документации, где встречаются знакомые слова и не обращаешь внимания на контекст.
Так что будь внимательнее, когда цитировать соберешься.

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

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

А>>Сравнивать Oracle и MSSQL — это то же, что сравнивать Мерседес и Жигули. Оба в принципе могут ездить, только на Мерсе удобнее и быстрее.
M>Если уж проводить подобную анологию, тогда это сравнение между Land Cruiser (Oracle) и 325 бэхой... полноприводной (MSSQL).
M>И там и там можно ездить с комфортом, по бездорожью на ждипе сподручнее, но ездть почему-то больше приходится по трассе.

По специально для нее (325-ой) построенной — идеально ровной, без ям и кочек, грязи и трамвайных путей. Это я о машине, а не об MSSQL.
IMHO, все же лучше сравнение между Mercedes и BMW — т.е. вопрос религии. Правда, Mercedes то по комплектации явно побогаче будет,хотя и подороже.

А>>Возможности и скорость в Oracle гораздо больше.
M>Пффф... [-]
M>По возможностям именно RDBMS они абсолютно одинаковы.
M>В скорости, для очень широкого класса задачь MSSQL банально быстрее, так что вот так вот откровенно уж не правду говорить не надо.
Не, ну здесь надо говорить — IMHO.

А>>Кроме того Oracle — кросплатформенный.
M>Ну вот это да, это есть.

А>>Всех плюсов не перечтешь, пока не поработаешь сам с Ораклом лет несколько.
M>И столько же глюков, недоработок и косяков соберешь.
Недоработки есть, а вот глюков и косяков — опять нужно говорить — IMHO.

А>>Но будем откровенны — в MS SQL есть один плюс — он дешевле Оракла, по-моему, раза в два.
M>И этот плюс далеко не единственный. MSSQL продуманнее, лаконичнее и проще, как следствее более предсказуемый и надежный.
Опять похоже на божественный голос — типа я всегда прав.

M>Вообще сравнивать DB в отрыве от задачи — мягко говоря не корректно, можно наплести все что угодно, и попробуй докажи, что я не прав.
M>О каком-либо тотальном превосходстве какой-нибудь СУБД из тройки лидеров, для более менее широкого класса задач, на данный момент говорить не приходится, по возможностям и производительности они примерно одинаковы, дальше все зависит от специфики и радиуса кривизны рук разработчика.
M>Если стоит проблема выбора, то тадо брать ту СУБД, которую лучше знают те, кому придется с ней работать, все остальное — разговоры в пользу бедных.
Браво.

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

M>>В скорости, для очень широкого класса задачь MSSQL банально быстрее, так что вот так вот откровенно уж не правду говорить не надо.
A>Не, ну здесь надо говорить — IMHO.
Не, это не IMHO, это так и есть..

M>>И столько же глюков, недоработок и косяков соберешь.
A>Недоработки есть, а вот глюков и косяков — опять нужно говорить — IMHO.
Неа, как раз именно глюков и косяков. Можно спорить по поводу недоработок (что для одного недоработки, то чля другого вполне естественно), но глюки и косяки — факт вполне объективный.

M>>И этот плюс далеко не единственный. MSSQL продуманнее, лаконичнее и проще, как следствее более предсказуемый и надежный.
A>Опять похоже на божественный голос — типа я всегда прав.
Не, вот это как раз IMHO.

M>Во вторых подтверждается именно практикой tpc и sap, не говоря уже о практике всех васей пупкиных, которым пришлось писать более-менее серьезное приложение и под версионник, и под блокировочник.
опыт васи, с кривыми ручками меня как-то мало интересует
а вот опыт tpc.org и sap говорит о том, что оракловая модель быстрее, имеет преимущества версионности.


А>>ОК, давай я еще раз носом тыкну !
M>Носом будешь тыкать где-нибудь в другом месте, а здесь держи себя пожалуйста в руках, иначе за тебя это сделают другие..

цитата:
У многих разработчиков выроботолись плохие привычки в отношении транзакций.
[skip]
Это объясняется тем, что в упомянутых СУБД (MSSQL, INFORMIX) блокировки — ценный ресурс, а сеансы, читающие данные, блокируют сеансы изменяющие данные. Пытаясь повысить параллелизм, создатели этих СУБД заставляют разработчиков делать транзакции как можно короче (иногда в ущерб целостности данных).
[skip]
Столкнувшись с задачей изменения большого кол-ва строк программисты обычно пытаются изобрести процедурный способ сделать это в цикле — так, чтоб можно было фиксировать изменения группы строк определенного размера. Я слышал 2 обоснования подобного решения:
— быстрее и эфективнее фиксировать изменения часто с помощью множества небольших транзакций
— недостаточно места в сегментах отката

create table t as select * from all_objects ;
set timing on
update t set object_name=lower(object_name);

00:00:01.12

begin
for x in (select rowid rid, object_name, rownum r from t)
loop
update t set object_name=lower(x.object_name) ;
if (mod(x.r,100)=0) then
commit;
end if;
end loop;
commit;
end;

00:00:05.99

на этом простом примере показано, что частое фиксирование изменений в цикле в 5 раз медленее.
[skip]


Теперь давайте вернемся ко второй причине, связанной с экономичным использованием разработчиком "ограниченого ресурса" (сегмента отката). Это проблема конфигурирования — необходимо предусмотреть достаточно места в сегментах отката для поддержки транзакций требуемого размера. Фиксация в цикле — мало того, что обычно медленнее, это одна из наиболее частых причин возникновения ORA-01555 snapshot too old.
[skip]
в модели многовариантного доступа oracle данные в сегментах отката используются для востановления блоков в том виде, который они имели в начале выполнения оператора или транзакции (в зависимости от уровня изолированности). Если необходимые данные отмены не доступны, выдается сообщение об ошибке ORA-01555 snapshot too old и запрос не выполняется. Так что если вы изменяете считываемую вами таблицу (как в представленом выше анонимном блоке ) то генерируете данные отмены, необходимые для выполнения запроса для согласованного представления изменяемых данных. Если изменения фиксируются, системе разрешается повторно использовать только что занятое место в сегменте отката. Используя его, она стирает данные отката, которые в дальнейшем могут понадобится для выполнения запроса т.е. у вас возникает большая проблема, Оператор SELECT не выполнится и изменения остановятся на пол пути. В результате получится частично завершенная транзакция, и никакого приемлевого способа выполнить ее повторно, как правило, не существует.
[skip]
Подведу итоги: нельзя "съэкономить" место в сегментах отката, фиксируя изменения чаше, — эта информация необходима.

(C) Tom Kyte

Gt_

П>По моему скромному мнению, из этих двух БД, Вам, надо выбирать ту, с которой именно Вам будет проще разобраться, т.е. по какой БД у Вас больше информации, больше книжек, больше знакомых, знающих эту БД и могущих быстро помочь в случае какого-нибудь небольшого затруднения.
П>Сравнение производительности работы Oracle и MS SQL Server, для Вас вообще не должно играть ни какой роли. Разницу в производительности в своих приложениях, я уверен, Вы не заметите.

Не согласен, очень часто из-за разницы идеологий — вылезает разница в производительности.
Например наблюдал проблему — было приложение разработаное не безизвестным васей пупкиным, решили часть базы выложить в веб (статистику), но проблема была в том что приложение блокировало записи (причем целыми страницами) пока висело окно редактирования. статистику в вебе можно было тогда показать только через грязное чтение ... что не приемлимо.

Gt_

Подводя итог, можно сказать:

Да здравствует MySQL — самый продуманный, лаконичный, простой и, как следствие, более предсказуемый и надежный сервер баз данных. Притом в скорости он для очень широкого класса задач (известных узкому кругу лиц) банально быстрее (теоретически).

Спасибо за внимание.

Модератору.
Пока не поздно, может тему лучше в holy wars. А то щас праздники кончатся, и начнется. Пока все к этому идет.

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

А>а вот опыт tpc.org и sap говорит о том, что оракловая модель быстрее, имеет преимущества версионности.
Да флаг тебе в руки, особенно учитывая, что опыт tpc и sap говорит как раз обратное.

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

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

А>Не согласен, очень часто из-за разницы идеологий — вылезает разница в производительности.
Ну откровенную-то чушь пороть не надо....

А> статистику в вебе можно было тогда показать только через грязное чтение ... что не приемлимо.
Это не разница в идеологии а просто кривые руки, что вообщем-то должно быть вполне очевидно.

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

A>Пока не поздно, может тему лучше в holy wars. А то щас праздники кончатся, и начнется. Пока все к этому идет.
Я не посту, как только, так сразу...

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

A>Да здравствует MySQL — самый продуманный, лаконичный, простой и, как следствие, более предсказуемый и надежный сервер баз данных. Притом в скорости он для очень широкого класса задач (известных узкому кругу лиц) банально быстрее (теоретически).
Ну передергивать-то не надо..

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

M>Ну хоть одну цитату к месту из тебя выжать можно?
Объясняю почему не к месту была предыдущая цитата:
Во првых, непонятно к чему было приведено упоминание про MSSQL и Informix, они чудно справятся с данной задачей и без выполненя ее в цикле, а одним оператором. Благо с блокировками они справляются гораздо лучше чем Оракл, а сегмента отката там нет по определению.
Во вторых, там не сказано сколько запросов одновременно с выполнением update'а пытались изменить нужные записи. Чем больше таких запросов, тем медленнее будет в оракле выполняться изменение одним оператором и быстрее изменения в цикле, и еще не известно что в конечном итоге окажется выгоднее. Особенно учитывая каким образом Оракл мудрит с RW транзакциями при RC, а при snapshot'е все еще грустнее — там версионник сливает по определению.
И в третьих, эта цитата не имеет никакого отношения к "длинным транзакциям", о коих ты сам речь и завел.

Так что это лишь описание принципов работы с Ораклом, да и то, в определенных условиях. К чему это?

Что ты пытаешься доказать?

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

M>Ну передергивать-то не надо..
И я о том же.