Есть ещё такая актуальная проблемма для мобильных устройств — скорость разбора js. Да и cdn для библиотек всё же не так часто используют, скорее бандлят всё. А на счёт продуктов — в моей конторе я пишу на Svelte. Достаточно большую админку удерживаю в размерах 50кб.
Если я правильно помню, то хранимок нету и в MySQL/MariaDB и это никакого отношения к SQL не имеет. А так наверное да, но это всёравно применение SQL языка.
Это нормально если в бинармном дистрибутиве нету какойто нужной версии библиотеки.
т.е. невозможно собрать приложение без какойто сторонней библиотеки которой нету в нужной версии в конкретном дистре, а так как их много то лучше не мучится.
В Gentoo в любом случае пришлось бы собирать из исходников (на самом деле нет) и как минимум всегда можно было бы указать точно все зависимости и уже на плечи юзера ложится бремя поддержаня консистенции. Как то так… dependency hell он такой.
ЗЫ а может тут что то с лицензией?
Но это не результат отказа от SQL, а скорее ориентированность на их ниши.
На самом деле встроить SQL парсер и написать к нему оптимизатор это не такое простое занятие, куда проще (не факт что лучше) использовать JSON который повторяет ваши внутрении абстракции.
Как минимум они делают разные вещи внутри этого доступа. Собственно prepare statement не от хорошей жизни появился так что SQL имеет существенный оверхед особенно если в нём перечисленно много "таблиц".
Собственно если так подумать, то главная претензия к самому языку это отсуствие вменяемого синтаксиса (точно не как в новом стандарте) для доступа к сложным иерархиям внутри одного поля (документа). Если бы это было, то и Эластиксёрч с Монгой можно было бы перевести на этот язык.
ЗЫ хотя если так подумать, к примеру вложенные группировки в Эластике явно выглядят приятнее чем нагромождение которое будет в SQL.
Ну вот хотелось бы стандартизированного инструмента (языка) для существующих СУБД.
Ведь сделали же webassembly для веба и SPIRV для шейдеров, почему бы не сделать SQL Asembler? Некое промежуточное представление, которое было бы немного ниже текущего SQL но всё ещё сохраняло бы переносимость.
После чего результат стал крайне нестабильным т.к. зависит от собранной статистики и её качества. А что происходит если вам нужно много Join это вообще кромешный адъ. Собственно коррелацию между таблицами вообще может быть не получится эффективно сделать так как это слишком много доп. информации хранить надо.
Я говорю про то что в стандарте SQL этого нету, и в такой БД как Postgres то же нету. Мы же сейчас про язык, а не про конкретные хаки вашей СУБД. Хаки я и сам знаю, только не легче от них от перехода одной бд к другой.
И вы зря про SQLite это очень мощная СУБД и наглядный пример как можно использовать язык SQL (особенно их "компидятор" запроссов). И по колличеству инсталяций + работающего софта это наверная самая популярная СУБД в мире.
В любом случае в Svelte нету этих 58кб. И если я прав то камень был в огрод React.
тут это не нужно
У Svelte вообще нету vdom, о чём вы говорите?
Есть ещё такая актуальная проблемма для мобильных устройств — скорость разбора js. Да и cdn для библиотек всё же не так часто используют, скорее бандлят всё. А на счёт продуктов — в моей конторе я пишу на Svelte. Достаточно большую админку удерживаю в размерах 50кб.
А теперь пришёл ES6 и вместо require используем import и часто вместо webpack используем rollup.
Зная Японцев, они каждый тех осмотр будут менять ВСЁ. И ни в коем случае тут машины под солнцем не стоят т.к. летом тут АДъ.
Отвечу за авторов: он расчитан на жителей Японии, русские тут тоже есть. :)
Кажется нет… но тут дело не в языке т.к. гугл. транслейт решает почти любую задачу, даже оформление кредитной карточки. ^_^
Недавно проходил оффис с вывеской CarPrice в Токио. :)
Будем ждать истории про сайт.
ЗЫ а у вас то же при вводе email пользователи часто пытаются ввести email для СМС? :) Я так намучился с этим у себя на сайте…
а её никогда и небыло для неуголовных дел.
Если я правильно помню, то хранимок нету и в MySQL/MariaDB и это никакого отношения к SQL не имеет. А так наверное да, но это всёравно применение SQL языка.
В других стандартах этой проблеммы часто просто нету так как они привязанны к конкретным реализациям и нету двоякого прочтения.
Это нормально если в бинармном дистрибутиве нету какойто нужной версии библиотеки.
т.е. невозможно собрать приложение без какойто сторонней библиотеки которой нету в нужной версии в конкретном дистре, а так как их много то лучше не мучится.
В Gentoo в любом случае пришлось бы собирать из исходников (на самом деле нет) и как минимум всегда можно было бы указать точно все зависимости и уже на плечи юзера ложится бремя поддержаня консистенции. Как то так… dependency hell он такой.
ЗЫ а может тут что то с лицензией?
Это я поро применимость SQL в документо ориентированных БД.
Но это не результат отказа от SQL, а скорее ориентированность на их ниши.
На самом деле встроить SQL парсер и написать к нему оптимизатор это не такое простое занятие, куда проще (не факт что лучше) использовать JSON который повторяет ваши внутрении абстракции.
Ещё одна причина почему source based дистрибутивы хороши — всё консистентно в системе.
Ну да, это иллюзия универсальности.
Как минимум они делают разные вещи внутри этого доступа. Собственно prepare statement не от хорошей жизни появился так что SQL имеет существенный оверхед особенно если в нём перечисленно много "таблиц".
Собственно если так подумать, то главная претензия к самому языку это отсуствие вменяемого синтаксиса (точно не как в новом стандарте) для доступа к сложным иерархиям внутри одного поля (документа). Если бы это было, то и Эластиксёрч с Монгой можно было бы перевести на этот язык.
ЗЫ хотя если так подумать, к примеру вложенные группировки в Эластике явно выглядят приятнее чем нагромождение которое будет в SQL.
Ну вот хотелось бы стандартизированного инструмента (языка) для существующих СУБД.
Ведь сделали же webassembly для веба и SPIRV для шейдеров, почему бы не сделать SQL Asembler? Некое промежуточное представление, которое было бы немного ниже текущего SQL но всё ещё сохраняло бы переносимость.
После чего результат стал крайне нестабильным т.к. зависит от собранной статистики и её качества. А что происходит если вам нужно много Join это вообще кромешный адъ. Собственно коррелацию между таблицами вообще может быть не получится эффективно сделать так как это слишком много доп. информации хранить надо.
Я говорю про то что в стандарте SQL этого нету, и в такой БД как Postgres то же нету. Мы же сейчас про язык, а не про конкретные хаки вашей СУБД. Хаки я и сам знаю, только не легче от них от перехода одной бд к другой.
Я скорее про реализацию, толку от языка, который если хочется чего то предсказуемого по скорости, приходится писать под каждую СУБД свой запросс?
Даже тут https://ru.wikipedia.org/wiki/%D0%A3%D1%80%D0%BE%D0%B2%D0%B5%D0%BD%D1%8C_%D0%B8%D0%B7%D0%BE%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D1%82%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%B9 немного написанно про то что в мало каких СУБД это уровни реализованны строго по стандарту…
Есть же вроде устойчивое мнение что Read committed в Postgres это Repeatable read в Oracle.
И вы зря про SQLite это очень мощная СУБД и наглядный пример как можно использовать язык SQL (особенно их "компидятор" запроссов). И по колличеству инсталяций + работающего софта это наверная самая популярная СУБД в мире.