как в независимости от базы сложить строки?
юзать ANSI SQL
А вообще в чем смысл написания кросспалтформенного сиквела? Если тупо следовать стандарту, но просто далеко не всегда будет работать, если не следовать - ну, вперед 
Ну и потом, для чего отказываться от возможностей субд в угоду мифической кроссплатформенности
Ну и потом, для чего отказываться от возможностей субд в угоду мифической кроссплатформенностину, просто я понемногу практически на всех базах работал, и привык что все они стандарт поддерживают.
Стараюсь писать попроще, чтобы каждый раз не вникать в отличая.
а тут полчаса искал где у меня ошибка:
SELECT A + CAST(B AS VARCHAR(6 FROM Table
А - string
B - number
главное пакет компилится, но потом ошибку выдаёт мол "invalid number"
Стараюсь писать попроще, чтобы каждый раз не вникать в отличая.
а тут полчаса искал где у меня ошибка:
SELECT A + CAST(B AS VARCHAR(6 FROM Table
А - string
B - number
главное пакет компилится, но потом ошибку выдаёт мол "invalid number"
ну-ну, и вместо ISNULL/NVL ты всегда пишешь COALESCE, и вместо GETDATE/SYSDATE - CURRENT_TIMESTAMP, ага? Насчет стандарта - его вроде бы все "почти поддерживают", но скажем, оконные функции те же в мсскл реализованы не полностью.
Ну и раз уж речь зашла про пакеты - тебе не хочется случаем, чтоб он в MSSQL работал?
Ну и раз уж речь зашла про пакеты - тебе не хочется случаем, чтоб он в MSSQL работал?
на всех базах работал, и привык что все они стандарт поддерживают
Читаем стандарт:
И хаим все другие базы потому как по стандарту правильно:
<concatenation operator> is an operator, ||, that returns the character string made by joining its character
string operands in the order given.
И хаим все другие базы потому как по стандарту правильно:
SELECT A || B FROM Table
я всегда coalesce пишу - еще со спецкурса какого-то привычка 
и привык что все они стандарт поддерживаютчо
ты не афигел загоняться то?
в стандарте || как раз
ну накрайняк функция concat
и ваще
какие нафик все?
плюс ты где окромя mssql встречал?
чо
ты не афигел загоняться то?
ну был не прав, признаю, чё. просто для меня стандарт - это скорее то, что поддерживает большинство, а не то что на бумажке написано.
и ваще
какие нафик все?
плюс ты где окромя mssql встречал?
Access, MySQL, и могу ошибаться, но в фаербёрде тоже вроде + работает
конкат кстати вот как раз как минимум MS SQL не поддерживает (к остальным нет доступа, чтобы проверить)
Access, MySQL, и могу ошибаться, но в фаербёрде тоже вроде + работаетAccess делает тот же производитель что и MS SQL, было бы странно если бы там был другой синтаксис
MySQL - ты точно уверен про плюс?
гугл говорит: MySQL Is Different Most DBMSs use operators + or || for concatenation; MySQL uses the Concat function. Keep this in mind when converting SQL statements to MySQL.
фаербёрд вроде гордится тем что он придерживает стандарта, поэтому я почти уверен что там || а не плюс
конкат кстати вот как раз как минимум MS SQL не поддерживает (к остальным нет доступа, чтобы проверить)я с тебя не могу
ты вообще в курсе кто производитель ms sql?
подсказка: компания которая на стандарты всегда клала
вот это твое "кстати вот как раз" абсурдно, это абсолютно нормально что у ms sql всё по-другому, никаких тебе конкатов или ||
и еще добавлю
если ты не знаешь как такие простейшие вещи как сложение строк делается в разных субд, то твое утверждение что ты практически на всех базах работал ну явное вранье
на крайняк это не работал, а видел (или там щупал)
P.S.
сорри, я чото грубовато наверна, но ведь ты сам виноват что стал выпендриваться...
ты вообще в курсе кто производитель ms sql?подсказка: компания для которых важно удобство пользователей.
подсказка: компания которая на стандарты всегда клала
оператор || - очень и очень не интуитивно понятный, и это конечно минус стандарта SQL
1. мало того, что везде принят полиморфизм, что сложение записывается через + в независимости от типов данных (в том числе и для строк)
2. так в C-шном синтаксисе - operator || зарезервирован под operator or
3. еще и форма operator-а || - никак не намекает на то, что это конкатенация, а не что-то еще.
ps
в целом, выбор mssql - чтобы работал знак + вместо || мне нравится, т.к. спасает здорово нервов при написании запросов к базе
но минус microsoft в том, что они не пошли дальше и не пролоббировали в стандарте функцию concat для сложения строк, и уж совсем плохо, что они не поддержали функцию concat.
такое решение позволило большинству писать запросы быстро как они привыкли, через + или через || (в зависимости от базы)
но также можно было бы записать длиньше, через concat, но при этом кроссплатформерно
pps
на крайняк это не работал, а видел (или там щупал)чем первое отличается от второго?
если много трахался - и смазывал геморрой вазелином - то работал?
а если получал удовольстие от выполнения задач - то видел/щупал?
вот я тоже только из этого треда узнал, что все плохо - и в стандарте sql записан такой плохой вариант - как operator || для сложения строк.
А вообще в чем смысл написания кросспалтформенного сиквела?нервы бережет.
если поддерживаешь зоопарк баз, то проще один раз запомнить как надо писать кроссплатформенно (пусть может даже более громоздко чем каждый раз вспоминать - а как в данном случае надо, и почему оно не пашет так как хотелось...
плюс ты где окромя mssql встречал?по ощущениям, везде кроме oracle
т.к. только при работе с oracle-ом - этот вопрос возникает.
но может это в связи с тем, что сложные вещи только с mssql и oracle-ом делаются,
а из остальных баз данные просто выдергиваются
а сложение строк - это уже нетипичная операция для выдергивания данных
хм, ну у тебя же не возникает вопросов, когда вместо C# надо писать на VB (например, подправить код другого разработчика или скажем SSRS имеет свой диалект VB, а C# не поддерживает). Разные языки? ну да, а тут разные базы. Сиквел очень простой язык, чтобы из этого делать трагедию. Ну и потом, обычно простым сиквелом дело не ограничивается, а тут уже можно сказать про разные языки. Я согласен, что было бы намного удобнее, если б стандартные операции (те же подстроки - как только их не называют - и SUBSTRING, и SUBSTR, и даже MID) везде писались одинаково - не только в диалектах сиквела, но также и в .net и java, итд. Но реальность немного другая, и чтобы беречь нервы надо не плакаться в форум по таким простым вопросам, а просто открыть хелп.
Насчет более громоздко - абсолютно несогласен. Важно, чтоб была понятна логика запроса при взгляде на него, а не переносимость запроса на другую субд. Как минимум, таблицы/колонки менять все равно придется - можно и запрос написать нормально с учетом особенностей другой субд
Насчет более громоздко - абсолютно несогласен. Важно, чтоб была понятна логика запроса при взгляде на него, а не переносимость запроса на другую субд. Как минимум, таблицы/колонки менять все равно придется - можно и запрос написать нормально с учетом особенностей другой субд
Но реальность немного другая, и чтобы беречь нервы надо не плакаться в форум по таким простым вопросамда, есть жесткая реальность, которую исторически сложилась, и которую надо менять чтобы мир стал лучше, а не молиться на какие-то стандарты особенно таким, которые противоречат другим стандартам.
а стандарт sql именно противоречит стандарту де-факто на именование оператора сложения
, а просто открыть хелп.в хелпе не пишут как сделать мир лучше.
и раз ты посылаешь в хелп, то скажи, пожалуйста, на какой странице какого хелпа можно получить ответ на изначальный вопрос топистартера, а именно ответ на вопрос "как сделать чтобы один и тот же запрос работал в основных базах?"
если базы свои, то можно написать свою кроссплатформенную библиотечку, которую потом таскать вместе с базами.
в данном случае, можно написать функцию Concat для тех баз, где ее нет.
тогда запросы станут единообразными
в данном случае, можно написать функцию Concat для тех баз, где ее нет.
тогда запросы станут единообразными
на чем библиотечку? CLR? Java? или ты про БД? Ну вперед, получишь одинаковые запросы, конечно, но в том же MSSQL скорость упадет в те же абстрактные 10 раз
Ну вперед, получишь одинаковые запросы, конечно, но в том же MSSQL скорость упадет в те же абстрактные 10 разsql-ная детерминированная функция роняет так сильно скорость?
из-за чего?
особенно если учесть, что в БД тормозят обычно дисковые запросы, а не вычисления в памяти.
можно почитать например тут http://www.sqlmag.com/Articles/ArticleID/101104/101104.html?... - в первом абзаце про причину
User defined functions give you great benefits in terms of encapsulation and code reusability. Unfortunately though, when you invoke a scalar UDF as part of a query, and pass the function a column from the table as input, the function is invoked separately for each row. This is true even when all the function has is a RETURN clause with a single expression that theoretically could have been inlined in the query. This is how SQL Server always handled scalar UDFs from the moment those were introduced in the product (version 2000) and still does today (version 2008). The result is that a query that uses such a function would typically run significantly slower than a query that embeds the original expression inline instead of invoking the function.
User defined functions give you great benefits in terms of encapsulation and code reusability. Unfortunately though, when you invoke a scalar UDF as part of a query, and pass the function a column from the table as input, the function is invoked separately for each row. This is true even when all the function has is a RETURN clause with a single expression that theoretically could have been inlined in the query. This is how SQL Server always handled scalar UDFs from the moment those were introduced in the product (version 2000) and still does today (version 2008). The result is that a query that uses such a function would typically run significantly slower than a query that embeds the original expression inline instead of invoking the function.
но это будет играть роль, если функция используется под where,order и т.д.
а если просто выбирать, то торможения не должно быть.
а если просто выбирать, то торможения не должно быть.
можно узнать, на чем основывается это мнение? можешь привести сравнение как по моей ссылке?
можно узнать, на чем основывается это мнение? можешь привести сравнение как по моей ссылке?по твоей ссылке функция запихивается под order, и соответственно, идет речь о том, что отключается параллелизм на сортировке.
можешь привести сравнение как по моей ссылке?для того, чтобы проводить сравнение - сначала надо хотя бы понимать, что надо сравнивать.
пока не полностью понимаю, что именно и где начинает тормозить - поэтому пока никаких сравнений проводить не буду
можно узнать, на чем основывается это мнение? можешь привести сравнение как по моей ссылке?что-то погонял.
стабильно получается 14 с против 16 с на выборке первых 100000 тыс. больших записей (без сортировки, и с сортировкой по левому полю)
хм, базы под рукой нет, завтра тоже погоняю. У меня помню было раза в два медленнее, притом, что данные просто выбирались. Изменение на табличную функцию помогло. Но в принципе не так важно - как факт, введение такой функции может заметно испортить жизнь - не будешь же ты в одном месте использовать функцию, а в другом писать через плюсы и тд (т.е. нафига тогда вообще писать)
а стандарт sql именно противоречит стандарту де-факто на именование оператора сложения
вообще-то странно конкатенацию называть сложением, ибо де-факто где сложение там и вычитание, а как из 'aa' вычесть 'bbb' я лично хз
как из 'aa' вычесть 'bbb' я лично хзвычитание - это обратная операция для суммирования.
а bbb - не является суммой для aa
зы
причем для строк, сложение еще коммутативность не поддерживает
но ассоциативность поддерживается
вообще-то странно конкатенацию называть сложением, ибо де-факто где сложение там и вычитание, а как из 'aa' вычесть 'bbb' я лично хзесли ввести строки отрицательной длины (например, строка из backspace-ов
то сложение над строками будет даже группу образовывать.http://ru.wikipedia.org/wiki/%D0%93%D1%80%D1%83%D0%BF%D0%BF%...
>1. мало того, что везде принят полиморфизм, что сложение записывается через + в независимости от типов данных (в том числе и для строк)
бред, назвать тебе пару-тройку языков, в которых не так?
бред, назвать тебе пару-тройку языков, в которых не так?
бред, назвать тебе пару-тройку языков, в которых не так?да, я могу пару десятков - если не сотню таких назвать. и чё?
ps
только почему-то такие языки обычно относятся к группам вымирающих или нишевых...
>только почему-то такие языки обычно относятся к группам вымирающих или нишевых...
sql - не нишевый язык?
sql - не нишевый язык?
sql - не нишевый язык?так потому что он не нишевой, и наблюдается, что в нем активно используется + для сложения вместо положеного || по стандарту
активно?по крайней мере, 1/5 всех БД - причем той компании, которая во главу угла ставит именно TCO (стоимость обслуживания)
а низкая стоимость обслуживания очень близка к хорошему удобству.
вот представь что ты бы сегодня разрабатывал sql.
во главу бы угла ставил - легкость использования, легкость освоения.
или ты бы что-то другое поставил?
ты для сложения строк чтобы выбрал:
1. operator ||
2. функцию Concat
3. operator +
что-то еще?
и почему?
во главу бы угла ставил - легкость использования, легкость освоения.
или ты бы что-то другое поставил?
ты для сложения строк чтобы выбрал:
1. operator ||
2. функцию Concat
3. operator +
что-то еще?
и почему?
> вот представь что ты бы сегодня разрабатывал sql
а нафиг это сейчас надо?
а нафиг это сейчас надо?
а нафиг это сейчас надо?гипотетическая проверка старого (исторически сложившегося) решения на соответствие сегодняшнему дню.
или хочешь сказать что такое делать не надо?
если ввести строки отрицательной длины (например, строка из backspace-ов
http://ru.wikipedia.org/wiki/%D0%93%D1%80%D1%83%D0%BF%D0%BF%...
не надо давать ссылку на определение группы - я его знаю (при чем, судя по всему, лучше некоторых
)ЗЫ вот еще пример на счет того, что "сложение строк такое сложение"
вполне может буть, что a + b < b (например, 'a' + 'b' < 'b' что выглядит веьма странно (при остутсвии отрицательных строк)
ИМХО || вместо + как раз и призвано показать, что это вовсе не сложение, а конкатенация
если я ничего не путаю, SQL был придуман, чтобы всякие бухгалтеры и прочие аналитики вбивали запросы руками - затея в итоге провалилась, а проблемы остались: несовместимость типов данных с языками, на которых пишут приложения, например
сейчас бы такое не стали придумывать, потому что у бухгалтеров есть ёксели и прочие 1с
сейчас бы такое не стали придумывать, потому что у бухгалтеров есть ёксели и прочие 1с
сейчас бы такое не стали придумывать, потому что у бухгалтеров есть ёксели и прочие 1скак твое утверждение согласуется с тем, что был разработан тот же xquery?
ps
может тебе просто удобно верить, что типа, сегодня пользователи тупые - разврашены excel-ем, а раньше пользователи был ух! все на подбор! ? каждый мог на перфокартах в слепую дырки набить в нужном порядке.
если я ничего не путаю, SQL был придуман, чтобы всякие бухгалтеры и прочие аналитики вбивали запросы рукамигы лол
, а точнее СЗМ 
, открой хоть одну серьезную книжку по SQL, а лучше сходи на первую лекцию на ВМиКкак твое утверждение согласуется с тем, что был разработан тот же xquery?нормально согласуется - xquery явно не предназначен для ручного набора запросов
Из истории SQL:Книжки для первокурсников под рукой нет, увёл в своё время другой первокурсник!
В начале 70-х годов в компании IBM была разработана экспериментальная СУБД System R на основе языка SEQUEL (Structured English Qeury Language - структурированный английский язык запросов который можно считать непосредственным предшественником SQL. Целью разработки было создание простого непроцедурного языка, которым мог воспользоваться любой пользователь, даже не имеющий навыков программирования. В 1981 году IBM объявила о своем первом, основанном на SQL программном продукте, SQL/DS. Чуть позже к ней присоединились Oracle и другие производители. Первый стандарт языка SQL был принят Американским национальным институтом стандартизации (ANSI) в 1987 (так называемый SQL level /уровень/ 1) и несколько уточнен в 1989 году (SQL level 2). Дальнейшее развитие языка поставщиками СУБД потребовало принятия в 1992 нового расширенного стандарта (ANSI SQL-92 или просто SQL-2). В настоящее время ведется работа по подготовке третьего стандарта SQL, который должен включать элементы объекто-ориентрованного доступа к данным.
Необходимо сказать, что хотя SQL и задумывался как средство работы конечного пользователя, в конце концов он стал настолько сложным, что превратился в инструмент программиста. Вопросы создания приложений обработки данных с использованием SQL рассматриваются в конце данной главы.
нормально согласуется - xquery явно не предназначен для ручного набора запросоввот видишь ты сам и ответил на вопрос.
что даже если sql не было, то его все равно бы сделали, но он меньше был бы заточен под ручной ввод, а больше под машинную обработку
я думаю, что сейчас бы сделали в виде такого API, в котором было бы бессмысленно говорить о символе, обозначающем конкатенацию строк - это бы зависило от языка приложения
xquery не такой - но у его задачи своя специфика
xquery не такой - но у его задачи своя специфика
я думаю, что сейчас бы сделали в виде такого API, в котором было бы бессмысленно говорить о символе, обозначающем конкатенацию строк - это бы зависило от языка приложенияпример таких API можно?
примерно как в MSSQL загружают встроенные функции на CLR
примерно как в MSSQL загружают встроенные функции на CLRно это внутри одного производителя внутри одной платформы.
а мы говорим про стандарт доступа к реляционным данным - которые вне производителей и вне платформы.
так можно пример такого API (вне производителя и вне платформы)?
но это внутри одного производителя внутри одной платформы.CLR хотят же продвинуть как кросплатформенную шнягу
и есть кроссплатформенные API типа web services
а мы говорим про стандарт доступа к реляционным данным - которые вне производителей и вне платформы.существующие средства такого рода основаны на SQL благодаря унаследованному коду и концепциям; моя позиция в том, что если бы вдруг таких средств не было - изобретать SQL для них не стали бы, а взяли б что-нибудь на основе существующих виртуальных машин
так можно пример такого API?
а взяли б что-нибудь на основе существующих виртуальных машинтак язык бы был или нет?
т.е. как бы запрос загружался в эту виртуальную машину? в каком виде?
Ps
самое главное, что ты отчасти прав - такие api делают: аналог будет шейдеры и т.д., .net, java, android, но эта игра стоит свечь, когда разбор текстового языка начинает занимать больше времени, чем сама обработка запроса.
для sql-я же сам парсинг запроса копейки по сравнению с его выполнением.
поэтому скорее всего никто парится с api бы не стал, т.к. такой api намного дороже в эксплуатации чем текстовый язык.
т.е. как бы запрос загружался в эту виртуальную машину? в каком виде?байткод, наверное
но эта игра стоит свечь, когда разбор текстового языка начинает занимать больше времени, чем сама обработка запроса.дело не только во времени выполнения, но и в неудобствах, связанных с представлением кода в виде строки
Целью разработки было создание простого непроцедурного языка, которым мог воспользоваться любой пользователь, даже не имеющий навыков программирования.Я же написал серьезную книжку. Неплохо бы указать источник при цитировании.
Вот тут указаны цели проекта System R
http://citforum.ru/database/osbd/glava_8.shtml#_1_2_3
А объявлять целью проекта System R "создание простого непроцедурного языка, которым мог воспользоваться любой пользователь, даже не имеющий навыков программирования" просто смешно.
не вижу, как эти цели противоречат тому, что я написал
дело не только во времени выполнения, но и в неудобствах, связанных с представлением кода в виде строкиэти неудобства меньше, чем отсутствие текстового представления.
причем заметь и у байт-кода java-ы, и у байт-кода .net - есть текстовое представление: у одного для этого язык Java, у другого язык C#.
тем более байт-код - это императивщина, а sql - это все-таки декларация.
ты кстати примеры деклараций в виде байт-кода можешь привести?
и в неудобствах, связанных с представлением кода в виде строкикстати какие неудобства есть при представлении кода в виде строки?
и почему этих неудобств нет в байт коде?
причем заметь и у байт-кода java-ы, и у байт-кода .net - есть текстовое представлениеа для документации по ним есть English language, но мы нередко читаем и пишем по-русски, обозначая многие сущности совсем другими символами кириллического алфавита!
тем более байт-код - это императивщина, а sql - это все-таки декларация.не такая уж декларация: create, insert, select, update - это императивы
более декларативный язык - например, что-то вроде пролога, на котором тоже можно писать запросы
предложения sql - это скорее функции высшего порядка, чуть посложнее map и reduce
кстати какие неудобства есть при представлении кода в виде строки?необходимость квотинга и эскейпинга и связанных с этим ошибок
и почему этих неудобств нет в байт коде?
невозможность проанализировать код на этапе компиляции, потому что (правильный) транслятор sql на данном этапе недоступен
самое главное, что байт-код не сможет получить широкое распространения, если будет тоже самое решение - но в виде текстового представления.
возьмем инет, там есть аж 4 решения:
html + javascript (все текстовое)
java-applet (байт-код)
flash (байт-код)
silverlight (байт-код + текст для gui)
самый неоптимальных их них html+javascript, сплошное текстовое представление, никакого байт-кода, но при этом он чувствует себя лучше всех
java - не смотря на свой возраст так и не смогла вообще закрепиться.
flash - занял нишевую часть
silverlight - хз, пока непонятно.
чем же хорошо текстовое представление?
1. скоростью освоения
2. скоростью получения обратной связи. временем от изменения кода человека до получения результата
для текстового представления - это обычно секунды: что-то не работает, поменял - о! уже все хорошо.
для байт-кода же начинается - найди утилиту для отладки, найди утилиту для просмотра байт-кода, найди утилиту для изменения кода налету и т.д.
3. легкостью обмена и повторного использования.
кто-то придумал оригинальное решение в виде двух строчек. как этим поделиться для текстового представления - все понятно. но как поделиться тремя операндами байт-кода - хз.
понравилось чужая реализация, залез в текстовое представление - а вот оказывается, как это делается, с байт-кодом - опять же хз
возьмем инет, там есть аж 4 решения:
html + javascript (все текстовое)
java-applet (байт-код)
flash (байт-код)
silverlight (байт-код + текст для gui)
самый неоптимальных их них html+javascript, сплошное текстовое представление, никакого байт-кода, но при этом он чувствует себя лучше всех
java - не смотря на свой возраст так и не смогла вообще закрепиться.
flash - занял нишевую часть
silverlight - хз, пока непонятно.
чем же хорошо текстовое представление?
1. скоростью освоения
2. скоростью получения обратной связи. временем от изменения кода человека до получения результата
для текстового представления - это обычно секунды: что-то не работает, поменял - о! уже все хорошо.
для байт-кода же начинается - найди утилиту для отладки, найди утилиту для просмотра байт-кода, найди утилиту для изменения кода налету и т.д.
3. легкостью обмена и повторного использования.
кто-то придумал оригинальное решение в виде двух строчек. как этим поделиться для текстового представления - все понятно. но как поделиться тремя операндами байт-кода - хз.
понравилось чужая реализация, залез в текстовое представление - а вот оказывается, как это делается, с байт-кодом - опять же хз
необходимость квотинга и эскейпинга и связанных с этим ошибока в байткоде квотить и эскейпить не надо?
противопоставлять же надо задачу генерации байт-кода задачи генерации текстового представления.
проблемы с квотингом будут и там, и там. только в байт-коде будет меньше проблем с текстовыми константами, но больше проблем по структуре.
причем в байт-коде они хуже, т.к. требуется спец-инструмент чтобы увидеть эти проблемы.
ну я же не против текстового представления, но я против представления кода обработки данных в виде строк, когда в языках программирования есть более подходящие конструкции - функции, например
а в байткоде квотить и эскейпить не надо?нет вроде, ты пишешь на своём C# , а байткод потом сам получается
не вижу, как эти цели противоречат тому, что я написалпротиворечий может и нет (анализировать не буду). Но главное то, что между твоей формулировкой и приведенной мной нет ничего общего.
нет вроде, ты пишешь на своём C# , а байткод потом сам получаетсятак это потому что для меня этот байт-код родной, а ты посмотри на задачу - сгенерить байт-код на неродной системе.
вот представь, сижу я на какой-нибудь БЭСМ-6 и мне надо придумать и загрузить этот же байт-код на спутник (который только .net-байт-код и понимает).
на этой бэсм-6 никакого C# нет, и вот приходится руками этот байт-код генерить, отправлять на спутник и смотреть что получилось.
или ты знаешь магический способ - это обойти?
вот представь, сижу я на какой-нибудь БЭСМ-6 и мне надо придумать и загрузить этот же байт-код на спутник (который только .net-байт-код и понимает).на бэсм-6 так и было бы (и во время разработки sql примерно так и было)
на этой бэсм-6 никакого C# нет, и вот приходится руками этот байт-код генерить, отправлять на спутник и смотреть что получилось
но сейчас на твоём компьютере есть компилятор в clr
когда в языках программирования есть более подходящие конструкции - функции, напримернет такого представления.
мы же говорим сейчас о транспорте между двумя системами: в транспорте нет никаких функций.
в транспорте - есть либо текст, либо бинарное представление.
у бинарного представления - есть лишь один плюс, на него требуется меньше ресурсов на преобразование в готовый для исполнения вид. больше у него плюсов нет, сплошные минусы.
на бэсм-6 так и было бы (и во время разработки sql примерно так и было)т.е первично все-таки текстовое представление?
но сейчас на твоём компьютере есть компилятор в clr
тогда зачем компилятор у меня, а не на стороне выполнения?
т.е. если я хочу автоматизировать создание каких-то конструкций, то мне надо генерить текст, или байт-код?
мы же говорим сейчас о транспорте между двумя системами: в транспорте нет никаких функций.не совсем
в транспорте - есть либо текст, либо бинарное представление.
мы ещё говорим о коде, который пишут руками
иначе никто не узнает, плюс там или две черты - главное, чтоб преобразовалка (ака драйвер) работала
кстати зачем для api именно байт-кодное представление?
почему api нельзя делать поверх текстового представления?
вот, например, linq же сделан поверх текстового представления, и нормально пашет.
почему api нельзя делать поверх текстового представления?
вот, например, linq же сделан поверх текстового представления, и нормально пашет.
иначе никто не узнает, плюс там или две черты - главное, чтоб преобразовалка (ака драйвер) работалаи что делать если драйвера нет? или он не устраивает?
вот, например, linq же сделан поверх текстового представления, и нормально пашет.вроде бы скорее поверх AST - нормальный вариант, по-моему
а в каком представлении гонять AST по каналам связи (будет ли там операция сложения строк записана текстом, и если да, то какими символами) - дело десятое
вроде бы скорее поверх AST - нормальный вариант, по-моемучто значит поверх ast?
до базы же не ast идет, а текстовое представление.
а в каком представлении гонять AST по каналам связи (будет ли там операция сложения строк записана текстом, и если да, то какими символами) - дело десятоеэто для пользователя дело десятое, а с точки зрения стандарта и реализации этого стандарта - это куча человеко-часов.
Уже не в тему последних сообщений, но все же
print '1-------'
select str1 + str2
from test_udf
print '2-------'
select dbo.concatenate(str1, str2)
from test_udf
print '3-------'
1-------
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 1 ms.
(1000000 row(s) affected)
SQL Server Execution Times:
CPU time = 625 ms, elapsed time = 8029 ms.
2-------
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 1 ms.
(1000000 row(s) affected)
SQL Server Execution Times:
CPU time = 46375 ms, elapsed time = 51140 ms.
3-------
у тебя записи в кэше сидели?
если приглядеться, видно, что функция дергалась после простой выборки
если приглядеться, видно, что функция дергалась после простой выборкиэто мне понятно.
мне не понятно как ты миллион записей вытянул за 8 с, таких чтобы их обработка заняла 50 с
а функция как описана?
create function [dbo].[concatenate](
@str1 varchar(10)
, @str2 varchar(10)
) returns varchar(20)
as
begin
return @str1 + @str2
end
Билл Гейтс в своё время придумал машинный код для загрузки программы с ленты, при чём у него компа под руками не было
вот представь что ты бы сегодня разрабатывал sql.Ya otvechu: ya vyberu 'concat' i '||', potomuchto esli ispol'zovat' '+' to nuzno po analogii so slozeniem chisel delat' otdel'nuyu obrabotku na NULL, t.e. vmesto:
во главу бы угла ставил - легкость использования, легкость освоения.
или ты бы что-то другое поставил?
ты для сложения строк чтобы выбрал:
1. operator ||
2. функцию Concat
3. operator +
что-то еще?
и почему?
'aaa' || NULLpridetsya pisat':
[code]'aaa' + case when b is NULL then '' else b end case [\code]
Ya otvechu: ya vyberu 'concat' i '||', potomuchto esli ispol'zovat' '+' to nuzno po analogii so slozeniem chisel delat' otdel'nuyu obrabotku na NULL, t.e. vmesto:в этом есть определенная логика, но:
ты в курсе, что в стандарте написано, что строка || null должно быть null?
и только в оракле строка || null = строка.
зы
под такую логику лучше бы какой-нибудь +? сделали, так как такое обычно надо и для чисел, и для остальных операций тоже
Билл Гейтс в своё время придумал машинный код для загрузки программы с ленты, при чём у него компа под руками не былот.е. ты веришь, что если ты сегодня придумаешь маш. код для обмена программ, то ты тоже станешь такой же богатый как Билл Гейтс?
т.е. примеры из истории, конечно, хорошо, но стоит же делать поправки на текущее состояние дел.
В контексте твоего случая, у тебя, соответственно, на компе скорее всего будет компилятор под нужный байткод.
Кстати, фанаты php предложат использовать точку.
В контексте твоего случая, у тебя, соответственно, на компе скорее всего будет компилятор под нужный байткод.а если не будет?
Не, Шурик, не пойдет - раз в оракле '' is null, пускай в оракле и обрабатывают как считают нужным. Я догадываюсь, почему так сделали, но правильным не считаю
Ну и по поводу операторов - я бы оставил только плюс.
1. Словами писать неудобно, особенно учитывая убогость средств разработки - так что функция отпадает
2. Плюс - намного естественнее, чем ||. Не думаю, что при взгляде на str1 + str2 кто-нибудь может представить себе что либо другое, тогда как str1 || str2 - хз что такое. Ну да это писал все уже. Я бы вообще заменил в sql and и or на && и || на самом деле
По поводу "а что тогда вычитание" - ну блин, бред же! Никому почему-то в голову не приходит делить вектор на вектор, не правда ли? Хотя умножение вроде есть
1. Словами писать неудобно, особенно учитывая убогость средств разработки - так что функция отпадает
2. Плюс - намного естественнее, чем ||. Не думаю, что при взгляде на str1 + str2 кто-нибудь может представить себе что либо другое, тогда как str1 || str2 - хз что такое. Ну да это писал все уже. Я бы вообще заменил в sql and и or на && и || на самом деле
По поводу "а что тогда вычитание" - ну блин, бред же! Никому почему-то в голову не приходит делить вектор на вектор, не правда ли? Хотя умножение вроде есть
Никому почему-то в голову не приходит делить вектор на вектор, не правда ли? Хотя умножение вроде есть
ты, прости, про какое умножение говоришь и про какие векторы :?
я про векторное произведение
ну это вообще недопроизведение:
1) оно только для пар 3-х мерных векторов
2) оно необратимо: [a,x] = b имеет беск. много решений (ну кроме вырожденных случаев)
3) возвращаясь к нашим баранам про обозначения - оно не обозначается как "обычное" произведение - для него есть спец обозначение
1) оно только для пар 3-х мерных векторов
2) оно необратимо: [a,x] = b имеет беск. много решений (ну кроме вырожденных случаев)
3) возвращаясь к нашим баранам про обозначения - оно не обозначается как "обычное" произведение - для него есть спец обозначение
это все понятно - я к тому, что примеров подобного можно много придумать (матрицы те же - умножаешь на обратный элемент, если существует, а не делишь) и придумывать обратную операцию там где ее нет не надо. Насчет обозначений - их много разных бывает, ага. Я пишу как [a x b], некоторые просто a x b
Я пишу как [a x b], некоторые просто a x b
ага, а на заборе хуем "мел" написано..
касаемо матриц - ну принято, и что :? обратная операция же есть )
а для строк нет )
так что пока что примеров нема
так что пока что примеров немадопустим сложение по модулю использует для записи + (или в ряде случаев, + в кружке)
http://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D0%BE%D0%B6%D0%B5%...
и что?
там по той ссылке вообще XOR написано, а это только для модуля два - а там и вычитание и деление есть
при сложении по любому модулю есть обратный элемент, так что пример на катит...
вот умножение по модулю - да, может быть "необратимым".. но мы-то про сложение
да и в любом случае, по модулю обычно пишут типа
7 * 5 = 5 (mod 30) - так что тут тоже особое обозначение )
там по той ссылке вообще XOR написано, а это только для модуля два - а там и вычитание и деление есть
при сложении по любому модулю есть обратный элемент, так что пример на катит...
вот умножение по модулю - да, может быть "необратимым".. но мы-то про сложение
да и в любом случае, по модулю обычно пишут типа
7 * 5 = 5 (mod 30) - так что тут тоже особое обозначение )
Hm, deystvitel'no.
A chemu v mssql ravno 5+'5' i '5'+5?
A chemu v mssql ravno 5+'5' i '5'+5?
10 будет, хотя на мой взгляд должна быть ошибка - нехрен числа со строками складывать
Оставить комментарий
kill-still
как написать запрос, который бы выполнялся и в PL/SQL и в других базах?PL:
Другие базы:
A и B - строки