Dimitry SibiryakovМногие со мной не согласятся

Безусловно!!!

Dimitry Sibiryakovно я бы не рекомендовал его для новичков

А я бы вот как раз наоборот рекомендовал бы!

Dimitry SibiryakovСлишком уж он вычурный

Толковый словарь русского языка УшаковаВычурный: Замысловатый, излишне затейливый, искусственно осложненный

Можно раскрыть хотя бы один из синонимов???

Dimitry Sibiryakovпосле него изучение других серверов даётся с трудом

Так может проблема не в нем, а в "других серверах"?

Dimitry SibiryakovДа и "нестабильность" API (они быстро из recommended становится
deprecated) тоже настораживает.

Можно уточнить временные рамки "быстро" в Вашей трактовке? Замечу, что Deprecated никоим образом <> Discontinued! Например, приложения, использующие DB-Library (вспомните сколько ей лет) прекрасно работаю с 2005. Про ODBC вообще промолчу.

Dimitry SibiryakovУгу, именно таков он и есть. Я бы только добавил "не соответствующий
общепринятым канонам (то бишь ANSI стандарту)".

Хоть бы капельку аргументации. Ну, или, хотя бы, IMHO. Особенно на счет совместимости с ANSI и в сравнении с другими СУБД. :)

Dimitry Sibiryakov"Прекрасно работают" значит поддерживают все фичи/типы данных, включая
новые?

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

Dimitry SibiryakovКстати, что нынче является "наиболее прямым" (т.е. быстродействующим и
"нативным") методом доступа? Универсальные прослойки типа ODBC такими не
являются по определению.

OLE DB которая напрямую работает с TDS протоколом. Ну, да, конечно, голимый API на С++ - это небыстродействующий метод доступа. :)

Dimitry SibiryakovПоскольку сам я с ним не сталкивался (пока),

Это пять!!! Зато какие безапеляционые суждения о вычернутости, "нестабильности" API и совместимости с ANSI.

Dimitry Sibiryakovсуждение вынесено из вопросов несчастных, которые пытаются перейти с MS SQL на, например, Firebird. Каждый второй пытается задействовать временные таблицы там,
где достаточно простых запросов, что уже выглядит подозрительно.

Безусловно, но только под подозрение должна подпадать, в первую очередь, квалификация этих "несчастых", а не сервер, с которого они переходят.

Dimitry SibiryakovНу и перлы типа SELECT INTO вместо стандартного INSERT SELECT...

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

Dimitry SibiryakovТо, что я пока не трогал его грязными лапами, ещё не значит, что я не
открывал BOL и соседний форум

Здорово! Жду аргументацию Ваших, пока безапелляционных, заявлений по результатам прочтения BOL и соседнего форума. Ссылки приветствуются. Особенно на посты "несчастных", чей моцх был выеден MS SQL и они решили перейти на Firebird.

2 Dimitry Sibiryakov

Посмотрел:

1. hvlad так же, как Вы не понимает разницы между SELECT ... INTO и INSERT ... SELECT. То, что это является расширением стандарта SQL не делает MS SQL (так же как и Oracle, имеющий аналогичное расширение) несовместимым с ANSI, а предоставляет больше возможностей. Вопрос про временную таблицу - это из моей любимой поговорки: "Задавайте вопрос по самой задаче, а не по выбранному Вами способу ее решения". Это даже вынесено в Рекомендации по оформлению сообщений на bid=1.

2. Вообще не понял к чему Вы привели этот линк. Select из хп сделать нельзя (без танцов с бубнами) ни в MS SQL, ни в Oracle, но что там, что там хп может возвращать курсор. В MS SQL, как и в Firebird хп м.б. "селективной", т.е. выдавать результат SELECTом находящимся в ней. В чем здесь вычурность или не соответствие стандарту?

3. Жесть! Вместо того, чтобы честно признаться что Firebird не поддерживает предложение FROM в инструкции UPDATE Вы скатились в философские заключения на тему проектирования бд. В каком плане в инструкции UPDATE, без учета расширений, MS SQL не соответствует стандарту?

1 = 4.

И так, что же показали Ваши ссылки:

1. Подтверждения вычурности я в них не нашел, ибо все приведенные Вами "подтверждения" на поверку оказались "слабыми сторонами" реализации диалекта SQL в Firebird, по сравнения с расширениями (обращаю внимание, это именно расширения и стандартный синтаксис поддерживается) в T-SQL
2. Ни один из приведенных примеров не показал, что MS SQL не соответствует стандарту ANSI и в какой его части.
3. Кмк, вопросы задавались слабоквалифицированными специалистами.
4. Вы пытаетесь выдать за вычурность и не соответсnвие MS SQL стандартном Ваше незнание как базового синтаксиса T-SQL, так и его расширений.

Dimitry SibiryakovНоограничение в один триггер на таблицу убивает мои перспективы по
портированию. Или это ограничение тоже следствие моего недопонимания?

А Вы говорили, что лазили в BOL. ;)

BOL->Maximum Capacity Specifications:
...
Triggers per table(3) - Limited by number of objects in a database
...

(3) Database objects include objects such as tables, views, stored procedures, user-defined functions, triggers, rules, defaults, and constraints. The sum of the number of all objects in a database cannot exceed 2 147 483 647 .

Dimitry SibiryakovBOL. Действительно, к седьмой версии они таки этому научились...

Даже в далеком 1996 году версия 6.5 позволяла создавать три триггера - по одному на INSERT\UPDATE\DELETE. С 7ой версии и это ограничение было снято:

http://www.microsoft.com/technet/prodtechnol/sql/70/proddocs/intro/part3/75515c14.mspx?mfr=true

ЗЫ. Может не стоит, все-таки, в таком тоне - "научились". Давайте не будем сравнивать то, что было более 10ти лет назад (у MS SQL), и то, чего не существовало тогда вообще (FireBird).

Dimitry SibiryakovНе сущестовало у Firebird - было у Interbase.

И причем тут Interbase?! Где эта СУБД среди рекомендованных Вами:

Dimitry SibiryakovНачни с чего-нибудь бесплатного: Firebird, PostrgreSQL, Oracle XE.

И где она сейчас вообще?

авторРаз уж сравнивать историю, давай расширим временной интервал хотя бы до 20 лет. В каком году MS купила заготовку для своего сервера?

1. Я предлагаю как раз не "сравнивать историю", ибо это бессмыслено в контексте сабжа.
2. Выпуск SQL Server 4.21 - 1993 год.

Dimitry Sibiryakov
Всё там же - у CodeGear. Не так давно они выпустили Interbase 2007.

А в моём списке она отсутствует по причине того, что отнюдь небесплатна.
Хотя, конечно, есть версия для разработчиков, но...

Под "где она сейчас вообще" я имел ввиду ее распространенность, а не владельца, и Вы это прекрасно понимаете, учитывая Ваше "но...".

hvladНе нужно мне отвечать, умоляю.

Нет, уж, позвольте, уважаемый...

hvladВ приведенной ссылке я сказал, что SELECT ... INTO <table> FROM <select_expr> есть не стандартная конструкция. Не больше и не меньше.

Т.е. Вы таки понимаете, что из себя представляет эта нестандартная конструкция и в каких ситуациях ее применение оправдано? Чем плохо то, что кроме стандарта, есть еще "не стандарт"?

hvladТо, что её поддерживает Оракл, не добавляет ему плюсов. Вы ещё начните внешние джойны в стиле *=, += относить к сильным сторонам тех серверов, где они есть.

Кмк, любая дополнительная функциональность, наряду с поддержкой стандарта, добавляет плюсов любой СУБД. Не так ли?!

hvladНасчёт "предоставляет больше возможностей" - именно это не даёт людям переходить между серверами. Стандарт однако.

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

hvladЕсли язык позволяет сделать одно и тоже действие разными способами (я не говорю о принципиально разных способах), то он, увы, далёк от совершенства.

Это абстрактное заключение, или высказанное в контексте SELECT ... INTO ... vs INSERT ... SELECT ...? Если последнее, то, SELECT ... INTO ... - это всего-лишь "синтаксический сахар" (правда не только), к которым и относятся большинство расширений, заменяющие, как в данном случие несколько отдельных инструкций одной. Чуть ниже Вы упомяните MERGE. Ничего, что она появилась в стандарте не так давно, и раньше для реализации того, что делает одна инструкция приходилось писать несколько?

Так что же тогда является мерилом "совершенства"?

hvladВ непродуманных расширениях. UPDATE FROM позволяет писать неоднозначные операторы. В отличие от стандартного MERGE. Который есть в FB.

Господь с Вами! В чем, на Ваш взгляд, может быть допущена неоднозначность при использовании UPDATE ... FROM ...? И чем MERGE однозначнее в контексте "чистого" UPDATE?

hvladНикогда не любил беседовать с фанатиками...

Простите, но я всегда становлюсь "фанатиком", когда в качестве аргументации против "чего то" приводят домыслы и догадки, а не знания.

hvladЕсли сильно хочется - побрызгайте слюной вместе с ё, оно это любит

Будьте спокойней, пожалуйста.

2 Yo.!

Речь идет о реализации инструкции SELECT .. INTO ... в T-SQL, которая на основании метаданных выборки создает таблицу и заносит туда данные. В Orfcle - это CREATE TABLE ... AS SELECT ...

2 Yo.!

Все началось с того, что аргументом не соответствия MS SQL стандарту, были приведены линки, где те, кто поюзал некоторое время MS SQL, хотел применить SELECT ... INTO .... в Firebird. Но его там не оказалось. Oracle с его аналогичным по функционалу (вот это надо было явно упомянуть) синтаксическим сахаром упомянул я, пытаясь понять, как из наличия озвученного сахара вытекает несоответствие стандарту.

hvladСначала обложим человека, даже не участвующего в этом флейме, а потом "уважать" начинаем ? Это называется - лицемерие

Гм... Для Вас, если человек чего-то может не знать, одназначно заносит его в рязряд не уважаемых? Для меня это не так!

Откроем Ожигова: ЛИЦЕМЕРИЕ ср. Поведение, прикрывающее неискренность, злонамеренность притворным чистосердечием, добродетелью.

Вам обяснить, откуда я сделал вывод о Вашем "непонимании" инструкции SELECT .. INTO ... в ее реализации в MS SQL? Имеено из-вашего "не больше, не меньше" в топике, где вопрашающий явно описал что ему надо (создать таблицу и заполнить ее данными), а Вы предложили ему только INSERT ... SELECT..., не упомянув о CREATE TABLE.

hvladЯ - понимаю. Оно может быть оправдано (с натяжкой), только если нет стандартного эквивалента.

Вот и здорово. Значит мои предположения в Вашем "непонимании" оказались необоснованными.

hvladЯ, кстати, не выступал за отмену этого "расширения", мне оно в MSSQL параллельно.

Зато Дмитрий приводил именно это расширение, как аргумент в несоответствии стандарту.

hvladКстати, эта конструкция уже научилась отпускать блокировки таблиц системного каталога до окончания оператора ? Насколько я знаю, именно за это её не очень-то рекомендуют к использованию.

Уже давно. ;)

hvladА плохо пользоваться не стандартом тем, что стандарт достаточно строго всё описывает и учитывает множество нюансов, чего могли не сделать разработчики конкретного продукта (или их любимые маркетологи настояли на включении "фичи"). Также это всегда вылазит боком при смене СУБД.

Безусловно, но заметьте, что не все и не каждый день меняют СУБД. А однажды включенная "фича" продолжает развиваться в следующих версиях.

hvladНе всегда добавляет, UPDATE FROM - отличный пример.

Кмк, добавляет, но с учетом описанного в документации поведения.

hvladА я не ограничиваю. Где я это делал ?

А я сказал, что ограничиваете лично Вы?! Последний раз чуть Выше: "А плохо пользоваться не стандартом тем...это всегда вылазит боком при смене СУБД". Ваше высказывание напоминает мне традиционные баталии 2-tier vs N-tier, где для написание СУБД-независмых решений использование только ANSI-SQL - один из вариантов реализации, заведомо ставящих разработчиков в определенные рамки и не позволяющие использовать весь функционал СУБД.

hvladКонкретно этот "сахар" есть совершенно не нужное "расширение" (возможно появившееся до стандартизации). Ибо INSERT INTO SELECT FROM есть совершенно понятный оператор, делающий INSERT. В отличие от аморфного SELECT INTO, который и CREATE TABLE, и SELECT, и INSERT.

Про ненужность... Позвольте мне опять привести некий афоризм: "Если этого нет в Oracle, значит этого никому не нужно", на что у меня есть стандартный ответ: "Если звезды зажигают, значит это кому-то нужно" ((с)Антуан Сент-Экзюпери). Опять же "аморфность" полностью описана в документации.

hvladНичего, а что ?

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

hvladОно не достижимо. Но приветствовать уродствования я не хочу.

Я же не против. Просто не обращайте на них внимания. Но не стоит скатываться до этого (это не Вы):

Конструкция Select Into

hvladДжойн не по ПК. Когда одной записи обновляемой таблицы соответствует несколько разных значений. Именно из-за этого мы его не добавили в FB в своё время.

Там есть неопределенность результата, а не одноназначность оператора. Согласитесь, это разные понятия. Причем эта непоределенность описана в документации.

hvladПочитайте его синтаксис

Спасибо, я не только его читал, но и писал: Покритикуйте Оракл 10г. И то, что в MERGE эта неопределенность утстранена я только приветствую.

hvladА вы перечитайте свои сообщения в этом топике. Если не противно будет.

Вы знаете, я не могу найти свои высказывания, от которых мне сделалось бы противно. М.б. Вы потрудитесь это сделать для меня с объяснениями "противности" оных.

hvladPS Когда-то мне на этом форуме советовали не принимать его всерьёз. Я пытаюсь так и делать :)

Ваше право. А я частенько на этом форуме имею честь общаться с высокопрофессиональными собеседниками.