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 Когда-то мне на этом форуме советовали не принимать его всерьёз. Я пытаюсь так и делать :)

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