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