|
2.27, Дмитрий (??), 17:32, 26/07/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Если если sql не больше нескольких строк то не проблема.
У Sql есть недостаток. Он не модульный.
Нельзя сказать этот запрос такой же как этот только с небольшими изменения. У нас в проекте огромные запросы (по 3-4 страницы) а ещё код копипастится с десяток раз. Это очень плохо, код становится плохо поддерживаемым.
| |
|
3.28, Аноним (28), 17:38, 26/07/2023 [^] [^^] [^^^] [ответить]
| +5 +/– |
А ты не думал почему вы продолжаете делать именно так? Может потому что по другому просто не может работать?
| |
|
4.53, Дмитрий (??), 19:39, 26/07/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Да, динамический sql подходит. Но если генерируется то что должно создаваться руками - это признак что язык который генерируется - плохой.
| |
|
3.38, Аноним (38), 18:41, 26/07/2023 [^] [^^] [^^^] [ответить]
| +3 +/– |
Код писать нормально просто надо. Это у вас проблемы, а не у SQL
| |
|
4.57, Дмитрий (??), 19:47, 26/07/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Реляционные базы и так плохо маштабируются. Как будет производительность с хранимкам не знаю, но да, там с повторным использованием кода получше
| |
|
5.63, Rodegast (ok), 20:18, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
> Как будет производительность с хранимкам не знаю
Тебе никто не мешает сделать хранимку с обычным SQL-ом.
| |
|
6.130, Дмитрий (??), 00:43, 28/07/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Тебе никто не мешает сделать
>хранимку с обычным SQL-ом.
Тогда непонятно для чего хранимка
| |
|
5.85, Аноним (85), 01:57, 27/07/2023 [^] [^^] [^^^] [ответить]
| –3 +/– |
Категорически не советую никакие "хранимки" - мало того, что это в принципе уё6ство - писать на кривом недоязыке "процедуры" (привет новичкам проекта!), так ещё они не переносимы. Идеальная схема: СУБД исключительно для данных, вся логика на апп-сервере. В случае чего - можно СУБД даже полностью сменить, не говоря о простоте портирования на более свежие версии.
| |
|
6.86, Прохожий (??), 03:07, 27/07/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
>Идеальная схема
Отнюдь не идеальная. Как вы целостность данных собираетесь обеспечивать, если кто-то решит мимо сервера приложений нагадить?
Как обеспечивать непротиворечивость данных, если будет больше одного сервера приложений?
>В случае чего - можно СУБД даже полностью сменить
Чего, например?
>не говоря о простоте портирования на более свежие версии
Какие там сложности?
| |
|
7.117, Аноним (117), 16:56, 27/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
Если кто-то может мимо сервера приложений "гадить", найдется и DBA, который это дело поправит.
| |
7.151, Аноним (151), 06:02, 06/01/2024 [^] [^^] [^^^] [ответить] | +/– | Давай такие ТУХЛЫЕ аргументы не приводить А то я скажу, что у тебя нет защиты о... большой текст свёрнут, показать | |
|
6.88, Аноним (88), 04:21, 27/07/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Такая схема подходит для небольших, средних проектов. Они могут себе позволить "эксперименты" с "а давай сегодня сменим СУБД на ту, а через месяц на вон ту...".
| |
6.89, ойвэй (?), 04:38, 27/07/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
> В случае чего - можно СУБД даже полностью сменить
Постоянно слышу этот аргумент, а в реальности как часто проекты меняют СУБД?
| |
|
7.101, 1 (??), 09:08, 27/07/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вот прям сейчас идёт масштабный эксперимент по смене Oracle на PostgreSQL.
Даже при том, что внутренний язык подогнали, всё идёт как-то не очень.
| |
|
8.118, Аноним (117), 16:58, 27/07/2023 [^] [^^] [^^^] [ответить] | +1 +/– | Потому что нельзя за год подогнать то, что создавалось десятки лет Могли бы с... текст свёрнут, показать | |
|
|
6.114, Rodegast (ok), 15:02, 27/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
> Категорически не советую никакие "хранимки"
Человеку надо переиспользовать SQL. Хранимки для этого вполне подходят. Можно ещё и CTE использовать, но оно без параметров.
> в принципе уё6ство - писать на кривом недоязыке
Язык SQL.
| |
6.137, Аноним (137), 19:13, 28/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
Есть разница между бизнес-логикой и логикой целостности данных. Не всё можно уложить в constraints.
Типичный случай - умышленная денормализация в целях повышения производительности, например, всякие счётчики.
В Постгресе в большинстве случаев можно обойтись CREATE RULE, описывая событие и реакцию на него на чистом SQL. Это, конечно, не портабельно, но и триггеры-хранимки тоже не портабельны, зато не возникает соблазна засунуть туда ващевсё
| |
|
5.122, Прохожий (??), 20:31, 27/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
> Реляционные базы и так плохо масштабируются.
Зависит от архитектуры приложения вобще-то. Например, отдельные модули в отдельной схеме (базе данных) без сильных связей с другими схемами (базами данных) вполне себе отлично разносятся по разным хостам. Есть и другие способы разнесения нагрузки, типа репликации мастер-мастер, мастер-ведомый, и так далее.
Да, это не "СУБД" типа "ключ-значение", но зато РСУБД и гораздо больше чего умеет из коробки.
А так серебряной пули не бывает.
| |
|
|
3.91, Аноним (91), 05:50, 27/07/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
так прекратите писать sql-спагетти, и разгребите ваши запросы.
у вас видимо текучка кадров большая :)
| |
3.94, Аноним (94), 06:56, 27/07/2023 [^] [^^] [^^^] [ответить]
| +3 +/– |
Чта?!
Во первых в sql есть view.
Во вторых with.
Что покрывает все потребности в модульности.
| |
|
4.134, ptr (??), 08:47, 28/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
VIEW, CTE и функции, включая табличные, решают проблему лишь частично.
Мне радикально решить проблему модульности удалось лишь препроцессингом SQL кода средствами C препроцессора. Вот когда появились включаемые файлы и макросы - тогда действительно код стал модульным.
К сожалению, инлайн код в запросе намного производительней, чем тот же код, вынесенный в функции. А у меня даже такие запросики возникают: https://github.com/dbeaver/dbeaver/issues/10680 (смотрите аттач в zip). При том, что до препроцессора, это вполне себе компактный запрос:
SELECT ROUND(Q.Rez-UC_DISCOUNT,0)+CALC_JA_TOTAL
FROM ...
| |
|
3.119, Аноним (117), 17:24, 27/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
Модулей в SQL быть не может, однако от дублирования избавиться можно.
1) Можно повторяющийся SQL инклюдить из файла.
2) Можно написать класс билдера запросов для моделей, одноклассники которого смогут экспортировать миксины для построения запроса, а также использовать их для построения своих запросов. Очень грубо, можно передать список вещей, которые нужно добавить в те или иные части запроса, и что нужно потом сделать с результатом запроса. Например, можно добавить в группировку и в селект, а после исполнения развернуть group_concat в массивчик айдишек и т.д. В одном из проектов я такую вещь сделал и несмотря на некую навороченность кода, SQL существовал в единственном экземпляре. Запросы на экран и более были нормой, да.
| |
|
4.123, Прохожий (??), 20:41, 27/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
> Модулей в SQL быть не может
Я бы не был столь категоричным. View - вполне себе самостоятельный модуль. Есть и ещё, попроще, не так, чтобы модули, но вполне нормальный способ сократить дублирование кода. В Oracle использование функций в теле SQL-запроса подвезли с 19-й версии. Кроме того, есть with, как уже отметили выше.
| |
|
5.136, Аноним (117), 15:35, 28/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
Фактически это макросы. Подсократить запросы получится, спору нет.
| |
|
|
3.131, ptr (??), 07:15, 28/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
Проблему решает просто препроцессинг SQL кода, например, C препроцессором. Сразу же SQL модульный становится, благодаря макросам и включаемым файлам.
| |
|
4.146, Аноним (146), 15:15, 02/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Это изврат ради изврата. Сиквелу совершенно ни к чему быть модульным.
| |
|
|
2.32, Аноним (32), 18:03, 26/07/2023 [^] [^^] [^^^] [ответить]
| –4 +/– |
Тогда навеки один sql и отсанется. Тут же есть шанс дать аналитику UML- инструмент, а когда понадобиться скомпилировать, к примеру, в код для Pandas, своей биг даты и т.п.
| |
|
3.124, Прохожий (??), 20:46, 27/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
Для Pandas, если не ошибаюсь, есть отдельный модуль, который позволяет обращаться к библиотеке в виде диалекта SQL. А всё почему? А всё потому, что родной API библиотеки Pandas для конструирования сколь-либо сложных запросов - редкое г..ще.
| |
|
2.37, Карлос Сношайтилис (ok), 18:40, 26/07/2023 [^] [^^] [^^^] [ответить]
| –3 +/– |
Пиши. Сразу на несколько диалектов. И переписывай. И поддерживай. Никаких проблем. Ещё хранимками обмазаться для полноты ошушений.
| |
|
3.60, Bob (??), 20:06, 26/07/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
вася - лечись давай.
--
на ккой ляд на несколько диалектов писать?
2 субд понянешь за раз?)
| |
|
2.127, fuggy (ok), 21:15, 27/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
Писать на SQL и компилировать в PRQL. И технологию поиспользовали и волки довольны. Да по сути он ничем не отличается, просто порядок поменяли и функции поменяли на нечитаемые символы. В чём удобство? В том что нужно учить новый язык, которые затухнет через полгода?
| |
|
1.4, Аноним (4), 16:32, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
То какую-то императивщину вместо регулярок, то SQL лишь бы не писать... Эпоха ORM все? Оказались слишком сложны/тупы и нужен все-таки язык запросов? Теперь начинаем языки запросов лепить?
>как в Python
Кто занимается подобной ерундой? Ну конечно же они - питонисты.
| |
|
2.7, Аноним (7), 16:37, 26/07/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
>ORM
это вообще хлам. Годится для тупого хранения данных и доступа к ним по ключу только. Движок и оптимизатор запроса в базе данных они не задействуют.
| |
|
3.87, Ruslan (??), 03:42, 27/07/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Дружище, оптимизатор запросов задействует сама СУБД. Ей навалить как был запрос сформирован - руками написан или сгенерирован ORMкой. Для СУБД нет разницы. Так что странное высказывание.
| |
|
4.125, Прохожий (??), 20:51, 27/07/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
> нормальных ORM реально практически не существует
Это правда.
> синтаксис SQL это устаревший шлак времен ледникового периода
А это - нет. В чём конкретно его недостатки? В том, что ORM фигню генерирует? Но причём тут SQL?
| |
|
3.96, penetrator (?), 07:45, 27/07/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
ORM разные бывают, хлам - это твой коментарий, в нем нет даже доли истины
это как со сломанными часами, которые показывают правильное время 2 раза в сутки
| |
|
4.126, Прохожий (??), 20:56, 27/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
> ORM разные бывают, хлам - это твой коментарий, в нем нет даже доли истины
Есть, конечно. ORM с точки зрения конечной производительности системы - это часто хлам. Обычно квалифицированный программист формирует куда как более эффективные запросы, чем вот эти поделия.
| |
|
5.128, penetrator (?), 21:18, 27/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
>> ORM разные бывают, хлам - это твой коментарий, в нем нет даже доли истины
> Есть, конечно. ORM с точки зрения конечной производительности системы - это часто
> хлам. Обычно квалифицированный программист формирует куда как более эффективные запросы,
> чем вот эти поделия.
брехня, "квалифицированный программист" не использует плохие орм, а те, которые пригодны точно знает как надо использовать, чтобы код получался такой же как и при ручном его написании
| |
5.147, Аноним (146), 15:36, 02/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Нет, проблема ORM-ов не в адекватности запросов -- в сиквеле пофиг как ты написал, гадалка всё равно сделает так, как нужно, главное, чтоб логически было верное выражение, а у ОРМов с этим более-менее. У ORM-ов просто много накладных расходов. А сейчас ещё и добавляет то, что вошли в моду ормы поверх ормов и поверх ормов. В той же java сейчас модно лепить всякую жуть над jpa.
| |
|
|
|
|
3.47, амоним (?), 18:56, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
может эксперт и не вкурсе, но АКТИВ РЕКОРД это собссно один из способов реализации ORM. подсказка: второй - это ДАТА МАППЕР.
| |
|
|
5.105, Онанистмус (?), 09:37, 27/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
LINQ это язык запросов. ORM на которую мапятся LINQ запросы это Entity Framework. Entity Framework это паттерн Data mapper, не active record.
| |
|
|
|
|
1.6, Аноним (6), 16:35, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
А как он будет оптимизировать запрос под конкретные базы? И не только запрос, но и схему самих баз. Мне однажды пришлось паковать два поля в целое число - rowid для SQLite. По другому было бы жутко медленно. А так был жутко медленный импорт, а остальные релевантные запросы - быстры.
| |
|
2.8, BorichL (ok), 16:38, 26/07/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да оно просто рассчитано только на примеры из книжки "SQL для начинающих".
| |
|
3.49, амоним (?), 19:02, 26/07/2023 [^] [^^] [^^^] [ответить]
| –2 +/– |
боюсь, что начинающий тут ты. оно предлагает написать руками по сути query execution plan.
из минусов, только 2 конверсии внутри в скл, и в план обратно.
| |
|
4.51, BorichL (ok), 19:03, 26/07/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
> боюсь, что начинающий тут ты. оно предлагает написать руками по сути query
> execution plan.
> из минусов, только 2 конверсии внутри в скл, и в план обратно.
Да? И какой сервер его будет выполнять?
| |
|
5.65, амоним (?), 20:27, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
а там вариантов много... пг, мускл, мс скл и проч
прям "в ассортименте"
| |
|
|
3.80, Аноним (80), 01:09, 27/07/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Да оно просто рассчитано только на примеры из книжки "SQL для начинающих".
но и ты ее не осилил
| |
|
4.112, BorichL (ok), 14:36, 27/07/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Да оно просто рассчитано только на примеры из книжки "SQL для начинающих".
> но и ты ее не осилил
Естественно, я ж тебе не начинающий!
| |
|
|
|
1.10, Golangdev (?), 16:39, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Обвязки для использования PRQL развиваются для языков Java, JavaScript, .NET, Elixir, R, Rust, PHP и Python
Я негодую! Где поддержка Go ?!
| |
|
2.35, Карлос Сношайтилис (ok), 18:24, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
Там прослойка элементарная - преобразование строк и прокидывание опций транслятору, даже раст не особо нужно знать.
Прояви себя вместо негодования - набросай свою интеграцию.
| |
2.44, Аноним (38), 18:45, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
О чем ты? Какая поддержка? Го для хиптанов. А PRQL для нормальных людей. Они с хиптанами не связываются.
| |
|
1.12, Аноним (45), 16:41, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
Каким образом это проще SQL?
Сложность SQL в понимании реляционной алгебры, а это никакими изменениями синтаксиса не решить: тут либо понял, либо нет.
А читается эта фигня точно сложнее, чем SQL.
| |
|
2.18, Аноним (19), 17:07, 26/07/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
> читается эта фигня точно сложнее, чем SQL
Более ущербного синтаксиса, чем у sql, представить сложно. А сабж читается легко, на уровне привычного разрабам array.filter(...).groupBy(...).filter(...).sort(...).
Ирония в том, что sql начинался как язык для непрограммистов. Типа бухгалтеры будут напрямую вбивать запросы на английском языке. Оказалось, что язык, изначально рассчитанный для программистов, читается легче, чем тот, что рассчитывался для непрограммистов. Сравни синтаксис си и бейсика например. В си все предсказуемо, а в бейсике каждая новая функция -- это каждый раз новый синтаксис.
| |
|
|
4.25, Аноним (19), 17:21, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
> лапша
лапша — это WITH table_1 AS ( SELECT customer_id, total - 0.8 AS _expr_0, invoice_date FROM invoices ), table_0 AS ( SELECT COALESCE(SUM(_expr_0), 0) AS sum_income, COUNT(*) AS ct, customer_id FROM table_1 WHERE _expr_0 > 5 AND invoice_date >= DATE '2010-01-16' GROUP BY customer_id ) SELECT c.customer_id, CONCAT(c.last_name, ', ', c.first_name) AS name, table_0.sum_income, table_0.ct, version() AS db_version FROM table_0 JOIN customers AS c ON table_0.customer_id = c.customer_id ORDER BY table_0.sum_income DESC LIMIT 10
| |
|
5.30, Аноним (28), 17:40, 26/07/2023 [^] [^^] [^^^] [ответить]
| +5 +/– |
Объсни что не так? Если ты не умеешь форматирование это не значит что все не умеют в форматирование.
| |
5.33, Аноним (4), 18:21, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
Отформатировать и будет все понятно. Да, запрос очень простой. Когда попишешь запросы сложные, расхочется заменять на императивщину.
| |
5.43, Аноним (38), 18:44, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
навалил в одну строку черти что - чертичто и называется лапшой, а не SQL. ты путаешься.
| |
|
|
3.46, Аноним (45), 18:53, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
для программистов есть query builder-ы на том языке, на котором само приложение.
Тот же SQLAlchemy ничем не хуже (и даже лучше) описанного, при этом нет никакого разделения на разные языки.
| |
|
|
5.77, Аноним (45), 22:37, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
А зачем?
Сколько раз в жизни приходилось переносить код query builder-а с одного языка программирования на другой? Большинству 0, кому-то, может, 1 раз за 10 лет.
При этом query builder на том же языке, что и всё приложение, имеет очевидные преимущества как по интеграции с остальным кодом, так и по использованию инструментария.
| |
|
|
|
2.39, Аноним (38), 18:42, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
В чем сложность понимания реляционной алгебры? Это что за такие сложности?
| |
|
3.70, амоним (?), 20:48, 26/07/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
ну если таблиц пара - легко. а если 25 (д, агалитика, та самая), то схему данных удерживать в голове... на 24 шага слияния... сложно.
но может есть гении..
| |
|
|
5.113, Аноним (4), 14:56, 27/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
explain запроса сделай и посмотри, сколько там в плане шагов. 87 таблиц может быть из-за того, что 5 сервисов в одну базу сpут. Половина таблиц справочники. Знаем мы вас. Сколько из этих табличек содержат более 100000 строк?
У тебя есть запросики, где ты одну и ту же табличку джойнишь чуть-чуть по-разному 3-5 раз? Колбасы из 10-20 лефт джойнов, зависящие друг от друга и от 5 иннер джойнов выше? Запросы более чем в пару экранов в высоту? Случалось ли придумывать логику запроса больше трех дней, а не за чашечкой кофе?
| |
|
|
7.135, Аноним (117), 15:25, 28/07/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
Короче наплодили сущностей, данных у вас толком нет, запросы простые. Понтов много :)
У меня стабильно проекты, где больше 100 только основных сущностей, а всякие связи вообще никто не считает.
>это не маст-хэв
Начальству как будешь объяснять, что им на самом деле не нужны эти данные/отчеты/аналитика?
>какая разница, это таблица на 100 тыс, 5 тыс, или вообще очищаемая очередь?
С таблицами на 5 тысяч можно писать в принципе любые запросы и ничего тормозить не будет, с 100т уже требуется думать головой, а когда часть таблиц имеет миллионы и десятки миллионов строк, уже приходится как-то изворачиваться.
Понятно, если ты г-кодишь новые проекты, ты никогда не увидишь ничего подобного. Пустые таблицы, не усложненная нюансами практики бизнес-логика, аналитики нет или она в зачатке.
| |
|
|
9.140, Аноним (117), 00:47, 29/07/2023 [^] [^^] [^^^] [ответить] | +/– | Когда у тебя большие таблицы, помимо схемы тебе надо думать еще и о количестве д... текст свёрнут, показать | |
|
|
11.143, амоним (?), 14:17, 01/08/2023 [^] [^^] [^^^] [ответить] | +/– | человек пытается сказать, что чем объемнее таблицы, тем аккуратнее надо быть при... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
3.115, Аноним (45), 16:27, 27/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
Да меня это тоже удивляет, но 90% кандидатов на собеседованиях валятся на простейших вопросах на join-ы.
| |
|
|
1.22, 1 (??), 17:13, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
О ! Они переизобрели Natural !!! Был такой язык для СУБД ADABAS в 80х.
50 лет и круг замкнулся.
Ещё немного подождать и появится новый SQL "на стероидах"
| |
|
2.34, Аноним (4), 18:22, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
У меня устойчивое дежа-вю, что лет 10 назад уже было нечто похожее.
| |
2.42, Аноним (38), 18:44, 26/07/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
Про любой язык так можно сказать. Ничего они не переизобретали.
| |
|
1.23, Аноним2 (?), 17:14, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Сейчас бы делать абстракцию над абстракцией.
И с SQL то не всегда непонятно как будет база запрос обрабатывать, а с этой штукой и по давно.
Ну от растоманов ничего другого и не ждал.
| |
|
2.40, Аноним (38), 18:43, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
В чем тут непонятность? И в чем не понятность как база будет запрос обрабатывать? Обрадую вас: повсюду тонна инструмнетов для анализа - и это уже давно решенная проблема (обрадую вас №2).
| |
2.41, Аноним (38), 18:43, 26/07/2023 [^] [^^] [^^^] [ответить]
| +/– |
Может быть просто надо вылезти из 2002 года и начать уже опльзоваться современными инструментами?
| |
|
1.26, 1 (??), 17:21, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Да ... вдогонку к 1.22 - это будет новый микросервисный, объекто-ориентированный, с параллельной обработкой, SQL !!!
| |
1.58, EuPhobos (ok), 19:58, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
PL/pgSQL - меня вполне устраивает, а мускулём или машей не пользуюсь в сложных проектах, но проект выглядит интересным, нужно будет потыкать палочкой.
| |
|
2.149, Аноним (146), 15:42, 02/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Процедурки над сиквелом, кроме Оракла, везде плохо. В Слоне тоже. Использовать можно только строго для реализации констраинтов или простейших триггеров.
| |
|
1.62, Bob (??), 20:11, 26/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
переизобрели 1с?
--
для разового запроса, оно, возможно, подойдёт. но если юзер идийот - то сервер ляжет нахер...
--
а вообще - нехер каждой амёбе давать доступ к базе. знание sql - как тест на профпригодность: можно к отдельным строкам r\o давать и организовать несколько шаблонов запросов)
| |
|
2.67, амоним (?), 20:35, 26/07/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
угу, а потом отгребать нетестируемые баги из-за смеси непонятно каких подзапросов, и sql injection, потому, что подставили, ой, нитуда и нито, и ниправерили.
| |
2.73, C00l_ni66a (ok), 21:36, 26/07/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да какой 1С, он вообще на всяких кассиров пятьорочки рассчитан и хотя бы концептуально (ЯП для непрограммистов) смысл имеет. А это - попытка впихнуть ещё один слой абстракции над и так очень абстрактной шелухой, типичный пример поделия от последователей карго-культа.
| |
|
1.99, Простоник (ok), 08:39, 27/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
SQL - декларативный, PROL - не декларативный, не процедурный и не объектный.
А программисты любят ORM - из объектов ходят в SQL. Это как раз понять можно, автоматические методы CRUD многим нравятся.Хотя даже такое нужно с осторожность использовать.Проблемы с производительностью таки бывают. ORM API есть для C++,Java,Python.
Для чего здесь не объектный PROL и где его место?
| |
1.104, Пряник (?), 09:31, 27/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Аналитические запросы - это когда запрашивают отдельные огромные столбцы и сразу с аггрегацией. Это не про релационные базы данных, где всё строками. А какая вообще аналитическая БД использует SQL?
| |
1.106, Анонимчик (?), 10:05, 27/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А уже есть такой язык, наз-ся "dplyr" / "dbplyr" из R. Точно также может транслироваться в различные диалекты SQL или вообще просто выполняться локально. Пример переводится буквально построчно:
employees |>
filter(start_date > as_date('2021-01-01')) |>
mutate(
gross_salary = salary + tax,
gross_cost = gross_salaray + benefits_cost
) |>
filter(gross_cost > 0) |>
group_by(title, country) |>
summarise(
gross_summary = mean(gross_salary),
sum_gross_cost = sum(gross_cost)
) |>
ungroup() |>
filter(sum_gross_cost > 1e5) |>
mutate(
id = glue_data('{title}_{country}'),
coutry_code = str_sub(country, 1, 2)
) |>
arrange(sum_gross_cost, -country) |>
slice_head(n = 20)
| |
1.111, vitalif (ok), 13:55, 27/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Не взлетит. Можете скринить
Я подобную поделку лет 15 назад делал, потом понял что это нафиг никому не нужный мусор
А в классических книжках был QUEL. И тоже его что-то никто не юзает
| |
1.116, 3draven (ok), 16:36, 27/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Они сделали версию Mule DataWave? У мула эта штука очень удобная, но применимая к абсолютно любому потоку данных например из сети.
| |
1.133, ptr (??), 07:36, 28/07/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Я только не понял:
- как тут с оконными функциями жить, вроде LAG, LEAD и т.п.?
- как сюда GROUPING SETS прикрутить?
- как APPLY/LATERAL описать?
- как с интервалами, диапазонами и массивами этим работать?
- как динамический SQL этим формировать?
Короче, больше вопросов, чем ответов. Этой шняге еще годы и годы расти до возможности практического применения.
Можно, конечно, добавить его, как еще один процедурный язык в PostgreSQL. Но толку?
| |
|