Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 81
Но зачем? :)
ну, во-первых, это весело.
а во вторых, появится возможность вместо ужасного и неудобного языка для хранимых процедур пользоваться хорошим и удобным яваскриптом.
и в-третьих, ну делают же что-то на яваскрипте в каком-нибудь монго, нужен же он там для чего-то.
а во вторых, появится возможность вместо ужасного и неудобного языка для хранимых процедур пользоваться хорошим и удобным яваскриптом.
и в-третьих, ну делают же что-то на яваскрипте в каком-нибудь монго, нужен же он там для чего-то.
Хранимые процедуры, в которых сам язык является проблемой, это УЖЕ проблема, на чём бы они не были. Не совмещайте сервер приложений и БД.
Понимаю, лето, делать нечего. Получилось прикольно, но уж если так хочется NoSQL и JavaScript, то изучите какую-нибудь True-NoSQL БД (CouchDB переполнена JavaScript — там его полным-полно), а не приделывайте 5-ю ногу… Если вам не нравится SQL, но нравится MySQL, то вам не стоит изобретать свой псевдо-SQL — лучше сразу сменить платформу по-душе, а не «жрать кактус и давиться» ©
По мне NoSQL + реляционная БД — ахтунг!
По мне NoSQL + реляционная БД — ахтунг!
Язык называется ДжаваСкрипт, не?
Для хранимых процедур есть достаточно хороших языков: plsql, ruby, python. Да, не в mysql, а в постгресе. Но проще воспользоваться другой РСУБД, чем придумывать ТАКОЕ.
ученые не спрашивают себя why?
они спрашивают себя why not?
они спрашивают себя why not?
не вижу целей переделывать один инструмент под другие масштабы.
нужны скриптовые языки в субд — переходим на PostgreSQL с его PL/Python, PL/Ruby, plPHP
нужны скриптовые языки в субд — переходим на PostgreSQL с его PL/Python, PL/Ruby, plPHP
>Во-вторых, у него нет встроенного яваскрипта.
WTF? Питона, руби, пхп там тоже нет, надо работать в этом направлении?
WTF? Питона, руби, пхп там тоже нет, надо работать в этом направлении?
во-первых, это такая особая шутка. она начиналась со слов «у MYSQL есть два недостатка» (на самом деле, у mysql больше недостатоков) и заканчивалась на слове «яваскрипта» (на самом деле, отсутствие встроеннго яваскрипта — не недостаток mysql).
во-вторых, разве у какого-нибудь монго есть встроенный интерпретатор питона, руби и пхп?
во-вторых, разве у какого-нибудь монго есть встроенный интерпретатор питона, руби и пхп?
Почему бы и нет? У постгреса, например, есть питон, перл, и ими даже иногда пользуются.
Бррр…
знать бы ещё, что значит «Бррр». это как-то связано с уже заданными вопросами, или у вас какое-то новое возражение?
/me тратит несколько дней, делает забавное применение одной технологии внутри другой технологии. делает код, тестирует, публикует, пишет статью, публикует.
/you пишет «Бррр»
/me тратит несколько дней, делает забавное применение одной технологии внутри другой технологии. делает код, тестирует, публикует, пишет статью, публикует.
/you пишет «Бррр»
Хорошая идея, успехов вам и развития. Даже если ничего не получится и не применения особого не будет, как вы правильно заметили, это весело )
Чего только не делают люди лишь бы не учить Postgresql в котором уже есть py-postgresql и многое другое.
скорее это его достоинства…
Разработчики, использующие mysql, имеют 2 недостатка. Во-первых, они уповают на mysql. Во-вторых, они винят во всем хранимые процедуры
интересная задумка =) придумать бы еще зачем это пригодится… но главное чтобы было, а применение найдем
удачи!
удачи!
Смешно читать про якобы «недостатки» MySQL, при том, что альтернатив из NoSQL практически нет: либо это невменяемые key-value хранилища без индексов (которые кроме как для примитивного кеша не годятся), либо еще что-то более непонятное, построенное на яваскрипте (а не на православном быстром С++).
Если кто-то использует хранимые процедуры, триггеры, вьюз, джойны ии прочую ересь (вместо того, чтобы по-человечески реализовать это в коде основного приложения) — он сам себе злобный буратино. А без них MySQL быстрее, стабильнее и надежнее любой альтернативы. Недаром фейсбук на ней сидит, а там нагрузки нешуточные.
База данных должны искать и возвращать данные, и все.
Если кто-то использует хранимые процедуры, триггеры, вьюз, джойны ии прочую ересь (вместо того, чтобы по-человечески реализовать это в коде основного приложения) — он сам себе злобный буратино. А без них MySQL быстрее, стабильнее и надежнее любой альтернативы. Недаром фейсбук на ней сидит, а там нагрузки нешуточные.
База данных должны искать и возвращать данные, и все.
> Смешно читать про якобы «недостатки» MySQL
вы, вероятно, не дочитали даже до середины
> либо еще что-то более непонятное, построенное на яваскрипте (а не на православном быстром С++).
если непонятным построенным на яваскрипте вы называете MongoDB, то вы ошиблись. он содержит интерпретатор javascript, но построен на C++. более того, использовать javascript вас никто не заставляет. более того, обычно время разработчиков дороже железа. и если задачу удобно решить на javascript и можно написать быстрое оптимизированное решение на c++, то нужно решать задачу на javascript.
> он сам себе злобный буратино
задачи-то разные бывают. я в целом согласен с тем, что бизнес-логику нужно пихать в код самого приложения, но бывают и исключения.
вы, вероятно, не дочитали даже до середины
> либо еще что-то более непонятное, построенное на яваскрипте (а не на православном быстром С++).
если непонятным построенным на яваскрипте вы называете MongoDB, то вы ошиблись. он содержит интерпретатор javascript, но построен на C++. более того, использовать javascript вас никто не заставляет. более того, обычно время разработчиков дороже железа. и если задачу удобно решить на javascript и можно написать быстрое оптимизированное решение на c++, то нужно решать задачу на javascript.
> он сам себе злобный буратино
задачи-то разные бывают. я в целом согласен с тем, что бизнес-логику нужно пихать в код самого приложения, но бывают и исключения.
>задачи-то разные бывают. я в целом согласен с тем, что бизнес-логику нужно пихать в код самого приложения, но бывают и исключения.
участвовал я в одном проекте, где наш «умный архитектор» перегрузил проект серверной логикой. Большую половину реализовали на хранимых процедурах. Яко бы так будет быстрее, чтоб данные по сети туда/сюда не гонять! Однако оказалось медленнее в десятки раз. Появились дедлоки. Вот тебе Бабушка и Юрьев день.
участвовал я в одном проекте, где наш «умный архитектор» перегрузил проект серверной логикой. Большую половину реализовали на хранимых процедурах. Яко бы так будет быстрее, чтоб данные по сети туда/сюда не гонять! Однако оказалось медленнее в десятки раз. Появились дедлоки. Вот тебе Бабушка и Юрьев день.
>Если кто-то использует… джойны ии прочую ересь
Вы только что прослушали мнение признанного эксперта в области построения баз данных.
Вы только что прослушали мнение признанного эксперта в области построения баз данных.
Вот будете презентовать один из своих проектов клиенту, выскочит у вас забытый вербоз «fuck yeah» из того места, про которое забыли.
Зачем языку запросов ещё и скриптовый? о_О
О какой тогда защите данных можно говорить? А если генерить готовый sql запрос на клиентской стороне, а потом передавать в мускул, что же это тогда будет? Конечный запрос у клиента поменяли на запрос «уничтожь всех и вся» и админам есть чем заняться, так получается?
О какой тогда защите данных можно говорить? А если генерить готовый sql запрос на клиентской стороне, а потом передавать в мускул, что же это тогда будет? Конечный запрос у клиента поменяли на запрос «уничтожь всех и вся» и админам есть чем заняться, так получается?
> Зачем языку запросов ещё и скриптовый?
ну а почему вы не удивляетесь существованию PL/SQL? это же точно то же самое, только синтаксис другой. принципиальной разницы нет.
> О какой тогда защите данных можно говорить?
сейчас — никакой. её нет.
в перспективе — разграничение доступа сделать можно. точно так же, как оно сделано в хранимых функциях mysql.
ну а почему вы не удивляетесь существованию PL/SQL? это же точно то же самое, только синтаксис другой. принципиальной разницы нет.
> О какой тогда защите данных можно говорить?
сейчас — никакой. её нет.
в перспективе — разграничение доступа сделать можно. точно так же, как оно сделано в хранимых функциях mysql.
PL/SQL я не удивляюсь по довольно таки понятной причине. Просто не думаю что MySQL'y надо ещё третью ногу прикручивать. Со своими основными целями он слава богу справляется, а требовать от него чего то более тяжкого ( как я уже из опыта заметил :D ) просто ненадо. 70% ПС которые по разным причинам используют мускул, не пользуются даже половиной доступного функционала. Всё статично, Select'но-Update'но-Delete'но и иногда даже Left join'ово, и на этом всё.
Поэтому использование js как «альтернативного источника» хранимок, мне не совсем понятно. Не берусь утверждать, но возможно было бы интересней тогда написать простой компилятор JS -> PL и кормить его мускулу. Как бы и вам приятно, пишете на js, и мускул не мутирует в «неведому зверушку».
Поэтому использование js как «альтернативного источника» хранимок, мне не совсем понятно. Не берусь утверждать, но возможно было бы интересней тогда написать простой компилятор JS -> PL и кормить его мускулу. Как бы и вам приятно, пишете на js, и мускул не мутирует в «неведому зверушку».
но почему вы считаете, что PL/SQL — это не «третья нога»?
мне не очень понятны критерии.
предположим, что в MySQL нет никаких встроенных функций и процедур и перед разработчиками стоит вопрос, какой язык выбрать:
— выберем javascript?
— ну, парсер модифицировать не нужно, интерпретатор и JIT готовы. но зачем нам третья нога?
— выберем PL/SQL?
— ну, нам придётся модифицировать парсер, чтобы он понимал, и написать интерпретатор. ещё придётся сделать оператор CALL для вызова процедур, набор операторов CREATE/ALTER/DELETE ROUTINE, несколько опций в mysql.ini. ДА, МЫ ВЫБЕРЕМ ЭТОТ СПОСОБ.
> Со своими основными целями он слава богу справляется, а требовать от него чего то более тяжкого ( как я уже из опыта заметил :D ) просто ненадо.
ну, вы хотите вообще остановить его в развитии. сейчас же есть форк, в котором все фичи обрезаны (drizzle), и есть основной форк со всеми фичами. я лично за свободу выбора — и я уверен, что у каждой фичи есть свои пользователи.
мне не очень понятны критерии.
предположим, что в MySQL нет никаких встроенных функций и процедур и перед разработчиками стоит вопрос, какой язык выбрать:
— выберем javascript?
— ну, парсер модифицировать не нужно, интерпретатор и JIT готовы. но зачем нам третья нога?
— выберем PL/SQL?
— ну, нам придётся модифицировать парсер, чтобы он понимал, и написать интерпретатор. ещё придётся сделать оператор CALL для вызова процедур, набор операторов CREATE/ALTER/DELETE ROUTINE, несколько опций в mysql.ini. ДА, МЫ ВЫБЕРЕМ ЭТОТ СПОСОБ.
> Со своими основными целями он слава богу справляется, а требовать от него чего то более тяжкого ( как я уже из опыта заметил :D ) просто ненадо.
ну, вы хотите вообще остановить его в развитии. сейчас же есть форк, в котором все фичи обрезаны (drizzle), и есть основной форк со всеми фичами. я лично за свободу выбора — и я уверен, что у каждой фичи есть свои пользователи.
Мне раньше часто говорили: «работает, не трогай!». Но как всегда я никого не слушал. (дурацкое любопытство и мечты об идеале ). Я не спорю. Да возможно у фичи будут свои поклонники. Но в чём профит? Что это кардинально поменяет в работе с данными? Или же это JFF? Т.к. если да, то «судья, я снимаю свои обвинения».
По поводу темы
> MySQL нет никаких встроенных функций и процедур и перед разработчиками стоит вопрос, какой язык выбрать
Тут уже полёт фантазии. В конретном контексте выбор будет в пользу языка, на котором программист пишет в данный период своей жизни/язык для которого будет намного проще это реализовать =) Так что тут уже как говорится, «как хочу». Но есть ещё и «как правильно».
> MySQL нет никаких встроенных функций и процедур и перед разработчиками стоит вопрос, какой язык выбрать
Тут уже полёт фантазии. В конретном контексте выбор будет в пользу языка, на котором программист пишет в данный период своей жизни/язык для которого будет намного проще это реализовать =) Так что тут уже как говорится, «как хочу». Но есть ещё и «как правильно».
Сотни тысяч разработчиков несколько десятилетий пишут на (PL/)SQL и довольны. Революции должны случаться, но, помоему, тут ей не место(она уже была с появлением NoSQL БД) — уж очень (PL/)SQL и Реляционная БД дружно и долго живут и все у них хорошо.
предположим, что в MySQL нет никаких встроенных функций и процедур и перед разработчиками стоит вопрос, какой язык выбрать:Ещё есть вариант отказаться от MySQL вообще — CouchDB, MongoDB, Raik вас давно ждут.
я лично за свободу выбора — и я уверен, что у каждой фичи есть свои пользователи.
правильно подмечено…
продолжай в заданном направлении
> А если генерить готовый sql запрос на клиентской стороне, а потом передавать в мускул, что же это тогда будет?
Вы о чём вообще?
Вы о чём вообще?
Каждый думает в меру своей распущенности =)
Я вот с первого взгляда подумал, что это дело будет как то прикручиваться к сайту, на клиентской стороне, какая то, к примеру, поисковая форма с данными при помощи функции кормится мускулу, он её экзекутит и мы видим какой то результат.
А о чём вы?
Я вот с первого взгляда подумал, что это дело будет как то прикручиваться к сайту, на клиентской стороне, какая то, к примеру, поисковая форма с данными при помощи функции кормится мускулу, он её экзекутит и мы видим какой то результат.
А о чём вы?
Вы не поверите — javascript может существовать не только в браузере.
Да и вы не поверите, человек это такое существо неуправляемое и всюду лезущее=)
Но вопрос в том что в js изначально и смысл другой владывали, по мимо слаботипизированного ооп и фукнционального <здесь ваш текст> языка. Так что теперь в поле ваш текст добавить " прикручиваемого везде, где только можно, ведь на нём так прияно писать"?
Но вопрос в том что в js изначально и смысл другой владывали, по мимо слаботипизированного ооп и фукнционального <здесь ваш текст> языка. Так что теперь в поле ваш текст добавить " прикручиваемого везде, где только можно, ведь на нём так прияно писать"?
Автор, пилите уж над percona server, нафига над исходным мускулем.
Весело весело… На сервере node, браузер с javascript, mysql с javascript — кажется тут есть закономерность, которую можно использовать…
намекаете на то, что надо бы по быстрому написать операционку на javascript'е?)
Зачем? Уже написана: www.masswerk.at/jsuix/
ну для начала можно ограничиться сайтами ) когда код какой-то обработки работает на любом уровне =)
А что, мило. Хорошего языка хранимых процедур MySQL от рождения не хватало.
А если кто-нибудь догадается симметрично/аналогично прикрутить V8 к PostgreSQL, то это может быть хорошим шагом к повышению их совместимости.
А если кто-нибудь догадается симметрично/аналогично прикрутить V8 к PostgreSQL, то это может быть хорошим шагом к повышению их совместимости.
Вобщем я подведу итог моего мнения.
Я не считаю идею ни плохой ни хорошей. Она интересна но не более. Возможно она бы лучше смотрелась с другой бд, но никак не мускулом. One good reason, где начинаются хранимки, там кончается зона влияния mysql IMO.
В оправдание скажу ещё такую вещь. Вот я никогда не понимал почему все стремятся «запхнуть» много вещей в одну. Вот современный телефон с камерой мрз плеером и функцией позвонить допустим. Вроде бы 3 в 1м, но и камера УГ и плеер УГ да и телефон в помещении тоже хреново ловит. Физику и закон сохраниения энергии никто не отменял, и обойти не может.
Я не считаю идею ни плохой ни хорошей. Она интересна но не более. Возможно она бы лучше смотрелась с другой бд, но никак не мускулом. One good reason, где начинаются хранимки, там кончается зона влияния mysql IMO.
В оправдание скажу ещё такую вещь. Вот я никогда не понимал почему все стремятся «запхнуть» много вещей в одну. Вот современный телефон с камерой мрз плеером и функцией позвонить допустим. Вроде бы 3 в 1м, но и камера УГ и плеер УГ да и телефон в помещении тоже хреново ловит. Физику и закон сохраниения энергии никто не отменял, и обойти не может.
dev.mysql.com/tech-resources/articles/whats-new-in-mysql-5.6.html#nosql
Как бы вот. Только неизвестно когда это все обкатают и можно будет полноценно пользоваться.
JS — это модно. Но запихивать его во всюду все таки не лучшая идея.
Как бы вот. Только неизвестно когда это все обкатают и можно будет полноценно пользоваться.
JS — это модно. Но запихивать его во всюду все таки не лучшая идея.
А теперь аргументированно поясните про два, как вы выразились недостатка.
Почему sql — недостаток?
Почему отсутствие javascripta — недостаток?
Почему sql — недостаток?
Почему отсутствие javascripta — недостаток?
1) из приведенной по теме ссылки, только первые три статьи, т.е половина соответствуют теме(и то все волей случая оказались моими). Хотя handlerSocket ни есть единственное noSQL решение в MySQL.
2) наличие JS ни есть признак NoSQL (это к вопросу о названии темы и введении к ней)
3) в целом за статью спасибо, работа проделана большая и положительная, фича интересная, но я не знаю на сколько она практична.
Лично я не вижу в ней особого смысла. Если уж реализовывать какой-либо функционал в качестве UDF или компилируемых процедур, то этого вполне достаточно на С++. Время инициализации съедает все преимущества. Это одна из основных причин, почему JS отказались встраивать в nginx
4) в статье ни слова про инсталляцию UDF, и в README проекта — тоже. Советую этот недостаток в README поправить.
2) наличие JS ни есть признак NoSQL (это к вопросу о названии темы и введении к ней)
3) в целом за статью спасибо, работа проделана большая и положительная, фича интересная, но я не знаю на сколько она практична.
Лично я не вижу в ней особого смысла. Если уж реализовывать какой-либо функционал в качестве UDF или компилируемых процедур, то этого вполне достаточно на С++. Время инициализации съедает все преимущества. Это одна из основных причин, почему JS отказались встраивать в nginx
4) в статье ни слова про инсталляцию UDF, и в README проекта — тоже. Советую этот недостаток в README поправить.
Осталось дождаться новых багов типа «пассивная XSSSQL-injection»
Спасибо большое, ваша код позволил заглянуть одним глазком во внутренности mysql, кода в исходниках на удивление мало, но понятно, что и функционал ещё далеко не весь.
Штука, конечно Just For Fun и врятли повторит историю линукса, да и зачем. Но вот сам процесс скрещивания очень познавателен и полезен для изучения. Для меня это лучший материал на хабре за последний месяц-два.
Штука, конечно Just For Fun и врятли повторит историю линукса, да и зачем. Но вот сам процесс скрещивания очень познавателен и полезен для изучения. Для меня это лучший материал на хабре за последний месяц-два.
Сохранить пользовательскую JavaScript-функцию, насколько я поняла, нельзя?
нет нельзя, но можно вызвать внешнюю JS функцию
я бы этот функционал реализовал как mysql_plugin а не udf
тогда возможностей на порядок было бы больше больше.
я бы этот функционал реализовал как mysql_plugin а не udf
тогда возможностей на порядок было бы больше больше.
Да, я сразу не отрефлексировала, что это UDF. Если бы можно было бы SP на JS писать, лучше было бы.
да, и это вполне реально реализовать как плагин. Это действительно была бы полезная фича.
Свет, а как ты думаешь — в данном варианте на сколько это интересно?
Свет, а как ты думаешь — в данном варианте на сколько это интересно?
В варианте UDF?
Если есть use case-ы для JS, то может быть интересно. Другое дело, что использование файлов — это потенциальная дыра в безопасности, а конкатенировать JS-строку для передачи в UDF-функцию как-то странно. И NoSQL-ом в таком случае тоже данное решение может называться с очень большой натяжкой.
Если есть use case-ы для JS, то может быть интересно. Другое дело, что использование файлов — это потенциальная дыра в безопасности, а конкатенировать JS-строку для передачи в UDF-функцию как-то странно. И NoSQL-ом в таком случае тоже данное решение может называться с очень большой натяжкой.
конкатенация там а) временная — пока я не сделал работу с несколькими типами данных; б) там не конкатенация, а конвертация типа из int в string
select execute_js(«require('/tmp/func.js');»,«func», CONCAT(num.i,"") )
вы же различаете flaws by design и flaws by implementation?
select execute_js(«require('/tmp/func.js');»,«func», CONCAT(num.i,"") )
вы же различаете flaws by design и flaws by implementation?
Я имела в виду несколько другое. Если мы хотим передать в execute_js что-нибудь сложнее, чем "«function func(x){ return x*1+10;}», «func»,«20»", то нужно либо читать файл, что является потенциальной дырой в безопасности плюс непонятно зачем в БД нужно (например такие js-файлы придётся включать в backup, а стандартные средства сами за вас этого не сделают), либо конкатенировать строку, используя SQL.
но за аргументированную критику спасибо
а чем лучше?
доступ к самим БД из UDF есть.
доступ к самим БД из UDF есть.
по большому счету вполне реально сделать поддержку языка my_JS
аналог pg_py или pg_perl
аналог pg_py или pg_perl
Ещё такой проект есть: forge.mysql.com/wiki/ProjectPage_External_Language_Stored_Procedures
а мне кажется, что недостаток в том, что латин1 ставится по дефолту везде, это как бы не критично, но крайне неопытный юзер может много наебаться, пока не поймет что трабл в этих кодировках, может я глупый, но у меня было так.
1. Нафик?
2. Какова скорость работы?
3. Целесообразно?
Если хотите поддержки кучи языков, правда все равно JS нет, поглядите к примеру на PostgreSQL.
2. Какова скорость работы?
3. Целесообразно?
Если хотите поддержки кучи языков, правда все равно JS нет, поглядите к примеру на PostgreSQL.
Использование интерпретируемого языка без строгой типизации для написания хранимых процедур БД — очевидное зло. Потому что сразу породит тонну ошибок, связанных с автоматическим приведением типов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MySQL is NoSQL!