pkarklinТак что, хоть вперед\хоть взад. ;) Причем давно.
A filtered index is an optimized nonclustered index, especially suited to cover queries that select from a well-defined subset of data. It uses a filter predicate to index a portion of rows in the table . Замечание по индексам снимается. Правда, DB2 сама по статистике выбирает, какой именно индекс использовать, ну да это мелочи. Тут догнали :)

pkarklinFavn2. row-level security - кажется, в SS до сих пор ее нет.
По крайней мере, я в MSDN так и не нашел - попадаются только внешние костыли на SP-UDF.
На декларативном уровне нет. Расценивать это http://technet.microsoft.com/ru-ru/library/cc966395(en-us).aspx костылями я бы не стал.То есть все-таки нет. По ссылке, если правильно навскидку понял, описана эмуляция этого механизма тригерами-вьюхами, что реализуемо в любой СУБД и имеет кучу недостатков. Это не функционал самой СУБД, а именно внешние "костыли". Кстати, введя в поиске MSDN "row level security", я даже этой доки не нашел - только ответы в конфах MS :)

AAron1. как я понимаю, индекс один, но может сканироваться в разных направлениях? такого нет.
2. row-level security - честно, не в курсе.
3. насчет реорганизации - есть команды dbcc, они позволяют дефрагментировать индекс/таблицу.1. pkarklin говорит, что есть - верю.
2. Выяснили, что нет.
3. Угу, посмотрел, моск кипит возмущенно:
" Инструкция DBCC CLEANTABLE выполняется за одну или несколько транзакций. Если не указан размер пакета, команда обрабатывает всю таблицу за одну транзакцию, при этом на время обработки производится ее монопольная блокировка.
Инструкция DBCC CLEANTABLE не должна выполняться как задача регламентного обслуживания. Вместо этого используйте инструкцию DBCC CLEANTABLE после выполнения значительных изменений над столбцами переменной длины в таблице или индексированном представлении, если необходимо незамедлительно освободить неиспользуемое пространство. Кроме того, можно выполнить перестроение индексов таблицы или представления, однако это более ресурсоемкая операция."
То есть не только оффлайн, но и не "задача регламентного обслуживания", хотя и почему-то дешевле по ресурсам, чем index reorg
С другой стороны, DBCC для индексов не рекомендуют - устарел, рекомендуют ALTER INDEX REORGANIZE . А там - online reorg и для кластерных индексов в том числе.
Люди добрые, объясните, в чем сакральный смысл online перестройки кластеризующего индекса, если кластеризуемая таблица не перестраивается?! Про таблицы там - ни слова.

AAron1. странно требовать от MS драйвера AIX или z/OS. кстати, в Feature Pack есть драйвера для рнр и жавы.
2. можно создавать CLR-типы данных, но в TSQL объектности действительно нет. Можно создавать CLR-функции/процедуры, используя там ООП. поля clr-типов можно индексировать стандартными механизмами. насчет video/audio - честно, не представляю, как можно на языке SQL работать с такими данными, а главное - зачем.1. Почему? Или у клиента с MacOS, например, работать с SS желания не возникнет по определению? А app-сервер на AIX тоже не должен иметь возможность работать с SS? В смысле, по политическим соображениям? :)
На драйверы посмотрел, хуже, чем могло бы быть, но есть.
Java: "The Microsoft SQL Server JDBC Driver version 2.0 can connect to SQL Server 2008 but does not fully support the new data types or other features that are new in SQL Server 2008". И SQLJ нет. Но спасибо, что хоть нативный - кажется, это единственный кусочек SS, который работает по *nix'ами, слава JVM :)
PHP - жесть : Supported Operating Systems: Windows в разных вариантах. Вы знаете хоть кого-нибудь, юзающего PHP из-под Windows? К тому же " Server Driver for PHP relies on the Microsoft SQL Server 2005 ODBC Driver to handle the low-level communication with SQL Server.", то есть он - просто ODBC-прокси.

2. Еще раз - дело не в самой объектности, а в возможности описание собственных индексов по нестандартным данным, и их использования в запросах и оптимизатором. Ну, антропометрия какая-нибудь, например. Да что угодно - API добавления индексов в DB2 открыт. А функции/процедуры CLR - и в DB2 можно, но они от любых других не отличаются.
Про video/audio - раз Оракл с IBM используют, наверно не просто так. Затем же, зачем полнотекст - централизованное хранилище всего с поиском по подобию, например.

AAron3. пакаджей в SS нет, насколько я понимаю, частично описанные здесь возможности решаются через LINQ. могу ошбаться.
4. динамические запросы - по всей видимости мы понимаем разные вещи под динамическими запросами. в моей картине мера динамический запрос "select * from " + @tbl не оптимизируется заранее никак.
5. вообще, при выполнении SP она целиком компилируется (либо план уже берется из кеша). не уверен насчет двух движков
6. SS не столько суров, он позволяет использовать хинты, но в документации написано - на свой страх и риск. кстати, ораклисты приводят большое количество хинтов как плюс
7. SS2000-2008 позволяют писать на С++ процедуры. насчет контекста - не в курсе. ни разу не использовал. предпочитаю использовать SQL.
8. насчет самого важного отличия - есть плюсы и минусы. а сервер СУБД как правило не мигируют с одной ОС на другую по несколько раз в месяц. на моей памяти, ни один оракловый проект не переносился Win <--> Linux <--> *nix. как правило, для серьезных проектов сервер планируют от железа и до СУБД.3. Совсем не похож:
- одна из задач static SQL - ускорять выполнение запроса, убирая лишние этапы выполнения, а у доп. прослойки LINQ - совсем наоборот :)
- как я понимаю, LINQ формирует запрос на клиенте, являясь частью .Net framework, тем самым опасность SQL injection сохраняется
- у пакаджей есть еще одно важное свойство - они позволяют отслеживать привязку программ и SP к структуре БД. Например, удаление поля может сделать использующие его SP (или программы со static SQL) невалидными сразу, а не потом по воплям от несчастных юзеров :)
- сама идея отказаться от декларативного SQL, т.е. лучшего, что есть в РСУБД, в пользу объектной навигации - мягко говоря, сомнительна.
4. В терминах DB2 статический запрос - запрос в коде программы, сформулированный до ее компиляции спец. прекомпилером. Динамический - любой, текст которого формируется в переменных-строках. И переведен в статический он может быть потом, админом, по факту частого выполнения и/или долгой оптимизации. Этот факт админу подскажут :)
5. Насчет контекстов - вопрос не праздный. T-SQL фактически не различает процедурную и декларативную части, чем провоцирует писать процедуры вместо сложных запросов. И неплохо бы знать, чем, кроме плохой оптимизации, приходится за это платить.
6. Ну, ораклисты - дело особое А вот изменить хинты в уже работающем приложении, если они внутри запросов, уже невозможно, подход DB2 гибче (хотя м.б. сложнее). Впрочем, подсказывать оптимизатору DB2 приходится крайне редко.
7. Согласен, фича редкая, я и сам не пользуюсь. Привел для порядку :)
8. Если проект под заказ - да, редко. Если на продажу - сколько угодно. Более того, со связкой DB2-J2EE (или Oracle-J2EE) можно спокойно перемещаться с Win на Unix сервера по мере роста проекта, масштабируясь почти неограниченно.

pkarklinВы будете смеятся, но оптимизатор MS SQL точно так же выбирает индекс на основе статистики. Более того, SS строит недостающую статистику сам по полям, не входящим в индекс, но используемых в предикатах.Написал некорректно - какой индекс, конечно, а какой тип индексации для данного индекса, т.е. строить обычный или filtered в терминах SS.
pkarklinЭээ... кластерный индекс - это и есть сама таблицы. Поэтому его реорганизация - есть реорганизация самой таблицы.Все понял, путаница в терминологии Если бы вот тут явно про таблицы и написали, все было бы понятно. А то получается, что есть table reorg со сжатием, кот. только offline, и есть другой - для кластеризации по индексу, но online. Путаница.

AAronраз уж я достаточно подробно ответил - расчитываю все же получить комментарии к моим вопросам по документу и озвучить версии DB2, которые сравниваем - продукт, версию, редакцию. а то сравнение аморфное.Озвучиваю.
1. Online table (не индекс) reorg и multi-dimensional clustering - входят в Enterprise.
2. Row-level security и audio/video - доп. фичи к Enterprise.
Все остальное - core-level, применимо ко всем без исключения редакциям. Все описанное, кроме полного XQuery, было еще в версии 8.2, естественно и в 9.5 есть.

Кстати, принципиальный вопрос по SS:

Поддерживается ли связь SP с используемыми в ней таблицами? Что будет с SP, если дропнули таблицу, к кот. она обращалась? Что накроется - понятно, но при дропании или при выполнении?

pkarklinEmbedded SQL for C существует в SS с незапямятных времен. ;) И прекомпайлер, есть, который:
. ..The access plan consists of a separate stored procedure for each static SQL statement in each compiled program module .Да уж, действительно - с незапамятных времен. Жесть
pkarklinНо это такие древности.По поводу древностей - посмотрите современный стандарт по Java и как динамично там развивается SQLJ. Отсутствие у MS похожего механизма - не повод считать его не нужным. На самом деле, это как раз возможность писать запросы на C++/Java/... в стиле процедур на T-SQL.
Или Вы думаете, что запихивать SQL в строку и потом вызвать функции любого CLI удобнее, чем просто написать строчку
#sql select MyField into :MyVar ... ;
pkarklinНа современном этапе механизмов доступа к данным, код SQL, зашитый жестко приложение, выполняют на сервере с помощью sp_exeutesql, расширенной хп, которая:
Using sp_executesql can help reduce this overhead and still let SQL Server reuse execution plans. sp_executesql can be used instead of stored procedures when executing a Transact-SQL statement several times, when the only variation is in the parameter values supplied to the Transact-SQL statement. Because the Transact-SQL statements themselves remain constant and only the parameter values change, the SQL Server query optimizer is likely to reuse the execution plan it generates for the first execution. Вы считаете вызов некой SP с текстом запроса "современном этапом механизмов доступа к данным"?
К тому же, это закрывает только маленький кусочек описанных выше возможностей package, и то план создается при 1-м выполнении. В DB2 для pakage можно настраивать кучу параметров, в т.ч. создание плана при rebind package (т.е. когда скажут), при 1-м вызове, или генерячить динамически, как для обычного SQL.
Кстати, чтобы перевести динамический запрос на этот механизм - придется переписывать код, а не тыркнуть несколько раз мышой в админке, как в DB2.

pkarklinОтвечу ссылкой, где я объяснял поведение SS в таком случае...Мерси, молдца SS! :)
Получается, что статическое связывание кода с запросом - это правильная, современная фича в случае T-SQL и жуткий древний отстой для остальных ЯП?

ApexЧто за наезд в сторону?:) Все там можно поменять, если знать как и где :Р"Ша, уже никто никуда не идет!" (c) Я всего лишь про старый спор с ораклоидами о хинтах 8)

Stas TristanВопрос - а зачем писать процедуры на Си или Джаве - это же отстой по сравнению с СиШарпом, благо процедуры на них поддерживаются в обоих сабжах.
ИМХО!Действительно, вы уж сначала портируйте CLR подо все, что движется, да со всем окружением, чтобы с J2EE сравнить было не стыдно.
А потом, в этом утопичном будущем, можно будет объяснять, что именно отстой и почему, как по Java, так и по C++. Не в пользу шарпа, конечно. И не в этой конфе :)