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

pkarklingoldenfoods...чисто логически понятно...

Рука так и тянется за тапком...

Да почему же за тапком..

Если одна компания занимается только одним направлением (вкладывает деньги от проданных лицензий) и другая компания имеет много направлений и СУБД не есть приоритетное (деньги распределяются на разные направления). Если одна компания занимается СУБД около 30 лет, а другая только 20. Если уровень стоимости компаний примерно одинаков, какая из них итого больше вложит денег в развитие СУБД. Какая из них больше потратить человеко-часов на труд программистов, архитекторов и т.д. Таким образом логично предположить (здравый смысл), что первая компания будет новатором, а вторая будет использовать технологии первой и пытаться применить их на своей совсем иной архитектуре.

Любая временная таблица сиквела оказывается в базе темпдб, то есть на жестком диске. Любой курсор оракла будет сидеть в ОЗУ. Скорость чтения из одной области ОЗУ в другую область ОЗУ всяко выше через скорость чтения из темпдб (жесткого диска) в первую область ОЗУ, и потом из этой области в другую область ОЗУ.
Далее работа с транзакциями у серверов иная, может ли сиквел обеспечить неблокирующее "чистое" чтение из таблицы в 500 млн строк, с интенсивностью наполнения скажем 200 строк в секунду.
Чтобы чисто прочитать сиквел должен заблокировать всю таблицу уровнем изоляции рид коммиттед, пищущие ребята отдохнут некоторое время, чтобы не испортить своими транзакциями общую картину.

Dimitry Sibiryakovandsmвот аналог в MS SQL Server 2008:

Это [название таблицы] включает в себя inserted и deleted? Напоминаю, речь шла именно о
том как связать эти две таблицы в отсутствии стабильного первичного ключа.


Никак не связать без дополнительно столбца, которые будет по сути вторым первичным ключом

BestZvitgoldenfoods чисто логически понятно что две компании с приблизительно одинаковой капитализацией вкладывают деньги в разные направления и что оракл более совершенен. .
А основания для этого "чисто логически понятно" есть ?
Или, как обычно, "просто понятно" ?

Оракл всегда является новатором и задает тон новых приблуд в мире СУБД.

andsmgoldenfoodsЛюбая временная таблица сиквела оказывается в базе темпдб, то есть на жестком диске.

Это не так
goldenfoods Любой курсор оракла будет сидеть в ОЗУ.

Уверен что это тоже не так.
goldenfoods Скорость чтения из одной области ОЗУ в другую область ОЗУ всяко выше через скорость чтения из темпдб (жесткого диска) в первую область ОЗУ, и потом из этой области в другую область ОЗУ.

скорость чтения из ОЗУ конечно быстрее чем с жесткого диска. Про tempdb смотри выше.
goldenfoodsДалее работа с транзакциями у серверов иная, может ли сиквел обеспечить неблокирующее "чистое" чтение из таблицы в 500 млн строк, с интенсивностью наполнения скажем 200 строк в секунду.

Да, сможет. Но не на любом железе - как и Оракл.
goldenfoodsЧтобы чисто прочитать сиквел должен заблокировать всю таблицу уровнем изоляции рид
Это не так
goldenfoodsпищущие ребята отдохнут некоторое время, чтобы не испортить своими транзакциями общую картину.
Это не так.

Общее заключение - отсутствие знаний по MS SQL Server, и похоже со знаниями по Оракл тоже не все хорошо.
То есть темпдб имеет свой кэш, как и любая другая база? Тогда зачем в принципе ее было создавать происходило бы все в кэше.
Почему это уверен насчет Оракла. У Оракла есть специальная область ОЗУ для каждой сессии, и она выделяется при инициализации подключения. Конечно при большом объеме курсора вероятно нужно создавать какую-то область на диске, но зачем делать такие огромные курсоры, всегда можно ограничить количество строк каким-то здравым смыслом.
Как это сделает сиквел насчет 500 млн строк, он что создаст версию "на начало чтения"? То есть перестанет быть блокировочником. Железо тут совсем ни при чем, мы говорим в принципе о возможности, пускай это будет строится 3 дня. Но через 3 дня мы получим данные в оракле, те которые были на на начало чтения.
А как физически сиквел в режим блокирования может отличать строки, которые были добавлены после начала чтения (модификации), разве что по временной метке?

pkarklingoldenfoods,

авторДалее работа с транзакциями у серверов иная, может ли сиквел обеспечить неблокирующее "чистое" чтение из таблицы в 500 млн строк, с интенсивностью наполнения скажем 200 строк в секунду.
Чтобы чисто прочитать сиквел должен заблокировать всю таблицу уровнем изоляции рид коммиттед, пищущие ребята отдохнут некоторое время, чтобы не испортить своими транзакциями общую картину.

У Вас сведения об MS SQL на уровне 10ти летней давности.

То есть в 2005-2008 сиквеле майкрософт пошел по пути версионнирования, то есть по пути пионера в этой области. Или я в корне не прав? Таким образом остается один путь, "где-то по временной метке хранить строку на момент чтения", это "где-то" и есть вероятно какая-нибудь область на жестком диске", с дублирующим кэшом, например темпдб. Хотя наверное я ошибаюсь.

pkarklin,
Как часто сиквел сбрасывает блоки из буфера темпдб на диск? Тоже по общему алгоритму "вытеснения" редко используемых блоков?