softwarerВ моем представлении, "табличная функция - это функция, которая вычисляет и возвращает таблицу". Подчеркну, именно "вычисляет" - и в этом смысле, насколько я понимаю, это соответствует multistatement table function.Непонятное ограничение. Обе функции возвращают результат одного и того же типа, и, в общем случае, только по синтаксису вызова Вы никак не сможете определить, что там "у ей внутре", parametrized view или multistatement. Так почему же одну из них можно называть табличной, а другую нет ? Соответственно, не совсем понятно, почему свою трактовку понятия "табличная функция" Вы считате более правильной, чем трактовку MS.
softwarerПростите великодушно, но мой собеседник, ставя задачу, настаивал именно на 2000. Полагаете, с моей стороны было бы корректно забыть об этом?Виноват. Действительно, был невнимателен, со стороны bpost было условие на версию MSSQL. И, кстати, более чем странное. Вроде потенциально рассматривается новый проект, зачем привязываться к версии, которой уже больше 7 лет, которую и купить-то уже нельзя ? Впрочем, этот вопрос должен быть адресован уже не Вам.

softwarerПринципиально различная механика работы.Вас не смущает, например, что самолеты бывают реактивные, а бывают винтовые ? Или, что мониторы есть ЭЛТ, а есть ЖК ? Впрочем, аналогии могут лишь помочь понять разницу, но не являются доказательствами, так что, по-видимому, эту веточку можно было бы и закончить.

softwarerВ общем случае, только по синтаксису вызова


я не смогу определить, что такое p - таблица, представление, процедура, материализованное представление, внешняя таблица, синоним к источнику данных в другой БД и так далее.В то же время, столкнувшись с конструкцией вряд ли Вы будете сильно сомневаться, что это вызов функции, и что он возвращает некий рекордсет(таблицу). Или таки засомневаетесь ?

softwarerПо двум причинам. Во-первых, потому что inline table function - это не "функция". Она не соответствует ни математическому понятию функции (как отображения множества входных данных на множество результатов), ни компьютерному (как "подпрограммы, возвращающей значение").Ну тогда и ваше трактовка не устраивает ровно по тем же причинам, да и multistatement туда же. Хотя, мне кажется, Вы просто погорячились, особенно в математическом смысле. Да и в компьютерном, пожалуй, тоже. Это такая же подпрограмма, просто состоит из одного, хотя и, возможно, сложного оператора, что позволяет оптимизатору развернуть его при включении функции в другой запрос. Но это уже его, оптимизатора, внутреннее дело.

softwarerВ гугле, кстати, мне понравилась одна фраза, хорошо иллюстрирующая это соображение:

Just like views, inline table functions are macros that are expanded into the query plan.

Надеюсь, разница между функцией и макросом понятна.Лично я не склонен считать такое различие слишком уж принципиальным. Так же, как между простой функцией и которой указали модификатор inline. На нижнем уровне разница может и есть, но совсем необязательно, так как оптимизирующий компилятор вполне может по месту развернуть функцию вместо ее вызова. В любом случае, это обычно не влияет на результат выполнения, особенно, когда нет доступа к исходнику. Важным это становиться лишь тогда, когда механизм выполнения действительно играет значение. IMHO, в подавляющем большинстве случаев, дела обстоят не так.

softwarer ChAВас не смущает, например, что самолеты бывают реактивные, а бывают винтовые ?
Нет, не смущает, потому что разница малопринципиальна по сравнению с общностью. Вот "подводный самолет" меня бы смутил.IMHO, между inline и multistatement разница такого же порядка.
softwarerБезусловно, засомневаюсь.И какие могут быть версии ? С позиции человека, знакомого с программированием вообще и SQL в частности.

softwarer

Поясните, пожалуйста, чем она не соответствует тому или иному определению.Так в том то и дело, что соответствует. Отображение множества аргумента(ов) на множество результатов. А теперь возьмем другой пример Почему вдруг этой функции отказано в математическом смысле, в сравнении с вышеупомянутым примером ? Разве здесь отсутствует отображение аргументов на результат ? И чем она не похожа на подпрограмму, которая возвращает результат ? Тем, что нет явного цикла ?

softwarerА чтобы конструктивно.... я так понимаю, вопрос сводится к тому, "на что больше похоже - на view или на procedure". Чтобы ответить на этот вопрос, придется для начала договариваться о критериях похожести, что наверное перебор.На мой взгляд, view ничем принципиально не отличается от procedure. Ведь есть же функции и процедуры без параметров, когда результат зависит только от некоей внутренней логики. И с этой точки зрения не очевидна разница между view и, например, той же функцией, но без параметров, или параметрами по умолчанию.

softwarerТот же самый параметризованный view.Да хоть горшком обзовите. Вы явно указываете значения параметров в аналогичной вызову функции манере. А с учетом синтаксиса SQL, явно получаете результат и он имеет табличный характер. У меня есть сильное подозрение, что если подобное выражение показать 10 программистам БД, даже MSSQL-щикам, и они не знают, что OPENROWSET можно использовать в модифицирующих операторах, по крайней мере 9 из них уверенно скажут, что это вызов функции, и только 10 просто почувствует подвох в вопросе, хотя по-прежнему не будет знать правильного ответа. Короче, если двигаться в предложенном Вами направлении, то мало, что оно выглядит как утка, ходит как утка и крякает как утка, надо непременно знать, что у нее внутри, чтобы убедиться, что это утка. Позиция понятна, хотя не готов разделить ее в данном случае. Есть много нюансов, обсуждение которых может занять неоправданно много времени с мизерным результатом.
softwarerНу так Вы уж выберите, пожалуйста, что-нибудь одно. Когда в одном письме Вы соглашаетесь с "не соответствует" (говоря "не устраивает в таком же смысле"), а в другом - "соответствует", немного трудно беседовать.
Вашу мысль "они одинаковы" я понимаю, но не разделяю. Свою позицию - эта соответствует, та не соответстует - я определил. Хотелось бы четкости и от Вас.Ну, это просто, не надо отходить от контекста, в котором фраза была сказана. От противного, если inline-функция не удовлетворяет Вашему пониманию табличной функции, хотя, на мой, и, уверен, не только на мой, взгляд, имеет все те же самые признаки, как multistatement или вариант, предложенный Вами, то наверное имеет смысл выбрать другие критерии, по которым можно судить о том, что такое функция вообще и ее "табличность" в частности.
Версия об inline-функции, как о параметризованном view, безусловно имеет право на жизнь, но вряд ли ее можно доказать в буквальном смысле, не имея доступа к исходникам. Мы просто не можем "разобрать эту утку". Не исключено, что эта версия лишь метафора, применимая в определенном контексте, степень удачности который сильно зависит от ситуации.
softwarer ChAПочему вдруг этой функции отказано в математическом смысле, в сравнении с вышеупомянутым примером ? Разве здесь отсутствует отображение аргументов на результат ?здесь отсутствует отображение параметров на результат. Результатом этой "функции" является не "выборка", а "константный объект (запрос, или селектор, или как угодно еще его можно назвать), который может быть будет выполнен позже".
Параметры - не передаются в эту функцию, они всего лишь описываются в ее заголовке, а реально передаются в тот самый результат, который из функции возвращается (а вернее даже и не туда, а в запрос, сконструированный в том числе из переделанного "результата").Как-то не очень удачно сформулировано, не находите ? Интересно было бы узнать, как много программистов поймут и согласятся с подобной формулировкой ? Мне, к сожалению, даже после многократного перечитывания, понять ход мысли не удалось. Особенно - "реально передаются в тот самый результат". Даже не касаясь смысла "реальности передачи", то это признак чего ? Функции или ее "табличности". Впрочем, по ходу, возникает другой вопрос. Если внутри функции, приведенной Вами в качестве примера, использовать запросы к каким-либо таблицам, хотя бы аналогично моему примеру, она останется табличной функцией или нет ? И если "да", то почему ?

softwarerТо есть Вы предпочитаете продвигаться в другую обрисованную мной сторону - объявить одним словом все "источники данных". Собственно, это показывает успех кампании СУБД по абстрагированию оных, но все же не всегда практично.Возможно не всегда, но, IMHO, более чем часто. Особенно учитывая, что программирование, в целом, явно движется в сторону закрытости кода в форме компонент, доступ к которым осуществляется только посредством интерфейса. В таких случаях, мы можем судить о том, что за ним скрывается лишь по некоторым формальным признакам, например, синтаксису вызова. То же свойство может быть просто переменной, но может и представлять собой пару методов Get/Set.
Таким образом, в обсуждаемом нами примере, мы передаем параметры определенным образом, обычно принятом при вызове функций, получаем результат, который можно использовать в качестве таблицы, значит это функция табличного вида. В определенных ситуациях можно подняться в абстрагировании на уровень выше, например, в клиентских компонентах часто используется понятие datasource, и его вполне достаточно, чтобы понимать, что мы можем получить некие данные, а в контексте работы с СУБД, наверняка в табличном виде. Хотя в общем случае, это просто некий массив данных, у которого есть количество измерений и границы. Далее, вы используете эту метафору независимо от того, что на самом деле послужило источником данных.

softwarerВозвращаясь к примеру самолетов - есть общее понятие "летательный аппарат", ЛА. Сюда включают самолеты, вертолеты, ракеты, винтокрылы, более экзотические конструкции, скажем экранопланы. Не знаю, включают ли аэростаты, но скорее всего да. У самолетов есть куча классификаций, как устаревших, так и действующих; скажем, по двигателям они делятся на поршневые (винтовые), реактивные (прямоточные, пульсирующие) и газотурбинные (турбовинтовые, турбореактивные и их вариации). Почему инженеры придумывают такую кучу слов, а не используют одно-единственное "ЛА"? Имхо, ответ вполне очевиден: так удобнее.Все это конечно правильно, но если я, допустим, скажу, что прилечу на самолете, насколько важно собеседнику, какого именно вида самолет ? А если я просто скажу, что прилечу ? Т.е., уточнение может играть роль лишь в определенном контексте. Даже в обыденной жизни мы постоянно пользуемся абстрагированием, уровень которого сильно зависит от контекста.

softwarerТо есть предлагаете подстраиваться под ламеров? Извините, не нравится мне этот путь.Можно ли понять так, что если кто-то не знает того, что знаете Вы, то он ламер ? А если бы Вам были неизвестны особенности OPENROWSET, Вы тоже были бы им ?
*Вообще, когда начинают поминать ламеров всуе, то лично я начинаю подозревать, что у человека комплекс кулхацкера. Предлагается, в дальнейшем, не использовать уничижительные оценки там, где, IMHO, этому не место. В любом случае, именование кого-либо ламером не может являться аргументом.
softwarerЕще раз: эта "функция" не возвращает никакого результата. Вообще. И даже не вызывается. Это просто запись в системной таблице - "вот такая константа есть то, что следует подставить в запрос вместо упоминания этой функции".Inline-функция ? Так все функции и процедуры в MSSQL, насколько мне известно, это записи в системных таблицах.
И не просто подставляется в запрос, а учитывая значения параметров, указанные в момент вызова, и результат будет от них зависеть. softwarerБезусловно, останется. Потому что берет и по-прежнему таки вычисляет результат на основании входных параметров. Текущий контекст - включая снапшот состояния БД - есть неявный параметр любых ХП, точно так же, как например в Oracle - состояние пакетов, установленные переменные контекста, политики доступа.По-прежнему, несколько бессвязно, IMHO. Особенно непонятно, при чем здесь снапшоты, состояния пакетов и политики доступа, бишь контекст времени выполнения кода. Inline-функция тоже его вполне учитывает.
softwarerОднако, специфицированный интерфейс никогда не отменял необходимости знать особенности реализации. Его роль в том, что он позволяет думать о реализации не каждую минуту, а только при необходимости - при планировании эффективности и при оптимизации.Если имеется закрытый компонент, то каким образом он реализован, как правило, неизвестно. Более того, сами производители таких компонент не очень охотно раскрывают, если раскрывают, детали реализации. А дизассемблирование, на мой взгляд, не оправдано в промышленных разработках, разве что в редчайших случаях, когда цена получения функционального аналога неоправданно высока. Впрочем, эта ветка слишком сильно ушла в сторону от темы обсуждения, так что есть предложение ее закрыть.
softwarerНет. Параметры никуда не передаются. Мы "записываем параметры в том же синтаксисе, что и при вызове функций". Аналогично с "получаем результат".В данном случае, у вас нет другого способа доказать это, кроме как предьявить исходники. Остальное, не более чем домыслы, основанные на одной фразе из Google. Причем не разработчика, надо заметить, а пусть и квалифицированного, но пользователя MSSQL.
То, что inline-функцию можно воспринимать, как parameterised views, не значит, что она ею и является. Но даже если не цепляться к букве, почему parameterised views не является функцией ? Т.е., где граница, до которой "не вычисляет", а после "вычисляет" ? Короче, хотелось бы какой-нибудь внятной ссылки на явное и четкое определение ? А то может получается, что мы обсуждаем только Ваше личное понимание табличных функций, которое противоставляено трактовке MSSQL. Если дела обстоят таким образом, то не вижу смысла продолжать прения.
softwarerНастолько же, насколько вашему пользователю важно, пишете ли Вы программу на Клиппере или на Каше. Однако, Вы - не Ваш пользователь, и если полагаете сходство между ними - в том, что оба начинаются на "К" - более существенным, нежели все остальное..... не хотел бы я лететь на Вашем самолете.Без обид, но это один из Ваших стандартных приемов. Приписать собеседнику нечто, и сделать из этого неутешительный вывод. Если хотите продолжать и далее в таком же духе, то я, опять же, не вижу смысла в продолжении.