forum.opennet.ru - "Опубликован PRQL, компилируемый в SQL язык обработки данных" (125)

"Опубликован PRQL, компилируемый в SQL язык обработки данных"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
Сообщение от opennews (??), 26-Июл-23, 16:25
Доступен выпуск языка формирования запросов и преобразования данных PRQL 0.9 (Pipelined Relational Query Language), развиваемого в качестве более простой и функциональной замены SQL, упрощающей создание сложных аналитических запросов. Код на языке PRQL компилируется в SQL, что позволяет использовать его с любыми реляционными СУБД. Компилятор PRQL написан на языке Rust и распространяется под лицензией Apache 2.0... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59499
Ответить \| Правка \| Cообщить модератору

Оглавление

а если сразу на SQL писать , Аноним (1), 16:25 , 26-Июл-23, (1) +13

Тогда PR не будет, Perlovka (ok), 16:26 , 26-Июл-23, (2) +22
Если если sql не больше нескольких строк то не проблема У Sql есть недостаток О, Дмитрий (??), 17:32 , 26-Июл-23, (27) +2

А ты не думал почему вы продолжаете делать именно так Может потому что по друго, Аноним (28), 17:38 , 26-Июл-23, (28) +5
views не помогает Или динамический sql , Твайлайт Спаркл (ok), 17:59 , 26-Июл-23, (31)

Да, динамический sql подходит Но если генерируется то что должно создаваться ру, Дмитрий (??), 19:39 , 26-Июл-23, (53) +2

Код писать нормально просто надо Это у вас проблемы, а не у SQL, Аноним (38), 18:41 , 26-Июл-23, (38) +3
про хранимки не слышал , Rodegast (ok), 19:22 , 26-Июл-23, (52)

Реляционные базы и так плохо маштабируются Как будет производительность с храни, Дмитрий (??), 19:47 , 26-Июл-23, (57) +1

Тебе никто не мешает сделать хранимку с обычным SQL-ом , Rodegast (ok), 20:18 , 26-Июл-23, (63)

Тогда непонятно для чего хранимка, Дмитрий (??), 00:43 , 28-Июл-23, (130) +1

Категорически не советую никакие хранимки - мало того, что это в принципе уё6с, Аноним (85), 01:57 , 27-Июл-23, (85) –3

Отнюдь не идеальная Как вы целостность данных собираетесь обеспечивать, если кт, Прохожий (??), 03:07 , 27-Июл-23, (86) +2

Если кто-то может мимо сервера приложений гадить , найдется и DBA, который это , Аноним (117), 16:56 , 27-Июл-23, (117)

Но к тому времени уже может оказаться поздно что-либо поправлять , Прохожий (??), 20:21 , 27-Июл-23, (121)

Давай такие ТУХЛЫЕ аргументы не приводить А то я скажу, что у тебя нет защиты о, Аноним (151), 06:02 , 06-Янв-24, (151)

Такая схема подходит для небольших, средних проектов Они могут себе позволить , Аноним (88), 04:21 , 27-Июл-23, (88) +2
Постоянно слышу этот аргумент, а в реальности как часто проекты меняют СУБД , ойвэй (?), 04:38 , 27-Июл-23, (89) +2

Вот прям сейчас идёт масштабный эксперимент по смене Oracle на PostgreSQL Даже п, 1 (??), 09:08 , 27-Июл-23, (101) +1

Потому что нельзя за год подогнать то, что создавалось десятки лет Могли бы с, Аноним (117), 16:58 , 27-Июл-23, (118) +1

Речь не про бесплатный Oracle , а про импортозамещение в связи с тем что Oracle, Нанонимус53 (?), 01:01 , 02-Авг-23, (145)

Человеку надо переиспользовать SQL Хранимки для этого вполне подходят Можно ещ, Rodegast (ok), 15:02 , 27-Июл-23, (114)
Есть разница между бизнес-логикой и логикой целостности данных Не всё можно уло, Аноним (137), 19:13 , 28-Июл-23, (137)

Зависит от архитектуры приложения вобще-то Например, отдельные модули в отдельн, Прохожий (??), 20:31 , 27-Июл-23, (122)

так прекратите писать sql-спагетти, и разгребите ваши запросы у вас видимо текуч, Аноним (91), 05:50 , 27-Июл-23, (91) +1
Чта Во первых в sql есть view Во вторых with Что покрывает все потребности в мо, Аноним (94), 06:56 , 27-Июл-23, (94) +3

VIEW, CTE и функции, включая табличные, решают проблему лишь частично Мне радика, ptr (??), 08:47 , 28-Июл-23, (134)

Модулей в SQL быть не может, однако от дублирования избавиться можно 1 Можно по, Аноним (117), 17:24 , 27-Июл-23, (119)

Я бы не был столь категоричным View - вполне себе самостоятельный модуль Есть , Прохожий (??), 20:41 , 27-Июл-23, (123)

Фактически это макросы Подсократить запросы получится, спору нет , Аноним (117), 15:35 , 28-Июл-23, (136)

Проблему решает просто препроцессинг SQL кода, например, C препроцессором Сразу, ptr (??), 07:15 , 28-Июл-23, (131)

Это изврат ради изврата Сиквелу совершенно ни к чему быть модульным , Аноним (146), 15:15 , 02-Авг-23, (146)

Тогда навеки один sql и отсанется Тут же есть шанс дать аналитику UML- инструме, Аноним (32), 18:03 , 26-Июл-23, (32) –4

Для Pandas, если не ошибаюсь, есть отдельный модуль, который позволяет обращатьс, Прохожий (??), 20:46 , 27-Июл-23, (124)

Пиши Сразу на несколько диалектов И переписывай И поддерживай Никаких пробле, Карлос Сношайтилис (ok), 18:40 , 26-Июл-23, (37) –3

вася - лечись давай --на ккой ляд на несколько диалектов писать 2 субд понянешь , Bob (??), 20:06 , 26-Июл-23, (60) +1

Писать на SQL и компилировать в PRQL И технологию поиспользовали и волки доволь, fuggy (ok), 21:15 , 27-Июл-23, (127)

Скрыто модератором, Аноним (3), 16:28 , 26-Июл-23, (3) –3

Скрыто модератором, Аноним (20), 17:10 , 26-Июл-23, (20)

То какую-то императивщину вместо регулярок, то SQL лишь бы не писать Эпоха OR, Аноним (4), 16:32 , 26-Июл-23, (4) +4

это вообще хлам Годится для тупого хранения данных и доступа к ним по ключу тол, Аноним (7), 16:37 , 26-Июл-23, (7) –1

Дружище, оптимизатор запросов задействует сама СУБД Ей навалить как был запрос , Ruslan (??), 03:42 , 27-Июл-23, (87) +1
Нормальные orm поверх sql баз данных предоставляют очень многого всего чего инач, cheburnator9000 (ok), 05:28 , 27-Июл-23, (90)

Это правда А это - нет В чём конкретно его недостатки В том, что ORM фигню ген, Прохожий (??), 20:51 , 27-Июл-23, (125) +1
https docs sqlalchemy org en 20 orm basic_relationships html many-to-manyЧего , Аноним (137), 19:17 , 28-Июл-23, (138)

ORM разные бывают, хлам - это твой коментарий, в нем нет даже доли истиныэто как, penetrator (?), 07:45 , 27-Июл-23, (96) –1

Есть, конечно ORM с точки зрения конечной производительности системы - это част, Прохожий (??), 20:56 , 27-Июл-23, (126)

брехня, квалифицированный программист не использует плохие орм, а те, которые , penetrator (?), 21:18 , 27-Июл-23, (128)
Нет, проблема ORM-ов не в адекватности запросов -- в сиквеле пофиг как ты написа, Аноним (146), 15:36 , 02-Авг-23, (147)

хорошо хоть АКТИВ РЕКОРД не вспомнил, Аноним (19), 17:10 , 26-Июл-23, (19)

А что с ним не так Можно развернуто , мимо (?), 18:25 , 26-Июл-23, (36) +2

Если вся логика - это тупой crud, то ничего плохого в нем нет А вот когда сложн, Аноним (45), 18:51 , 26-Июл-23, (45)

Другое дело, что 9 из 10 проектов - аккурат круд и есть, Бывалый смузихлёб (?), 07:09 , 27-Июл-23, (95)

может эксперт и не вкурсе, но АКТИВ РЕКОРД это собссно один из способов реализац, амоним (?), 18:56 , 26-Июл-23, (47)

а Linq provider это куда , penetrator (?), 07:47 , 27-Июл-23, (97)

LINQ это язык запросов ORM на которую мапятся LINQ запросы это Entity Framework, Онанистмус (?), 09:37 , 27-Июл-23, (105)

А как он будет оптимизировать запрос под конкретные базы И не только запрос, но, Аноним (6), 16:35 , 26-Июл-23, (6) +2

Да оно просто рассчитано только на примеры из книжки SQL для начинающих , BorichL (ok), 16:38 , 26-Июл-23, (8) +1

боюсь, что начинающий тут ты оно предлагает написать руками по сути query execu, амоним (?), 19:02 , 26-Июл-23, (49) –2

Да И какой сервер его будет выполнять , BorichL (ok), 19:03 , 26-Июл-23, (51) +1

а там вариантов много пг, мускл, мс скл и прочпрям в ассортименте , амоним (?), 20:27 , 26-Июл-23, (65)

но и ты ее не осилил, Аноним (80), 01:09 , 27-Июл-23, (80) +1

Естественно, я ж тебе не начинающий , BorichL (ok), 14:36 , 27-Июл-23, (112) +1

Я негодую Где поддержка Go , Golangdev (?), 16:39 , 26-Июл-23, (10)

Там прослойка элементарная - преобразование строк и прокидывание опций транслято, Карлос Сношайтилис (ok), 18:24 , 26-Июл-23, (35)
О чем ты Какая поддержка Го для хиптанов А PRQL для нормальных людей Они с х, Аноним (38), 18:45 , 26-Июл-23, (44)

Опубликован PRQL, компилируемый в SQL язык обработки данных, Аноним (64), 20:19 , 26-Июл-23, (64)

Каким образом это проще SQL Сложность SQL в понимании реляционной алгебры, а это, Аноним (45), 16:41 , 26-Июл-23, (12) +7

Проще чем кажется, на самом деле , alin (?), 17:02 , 26-Июл-23, (17)
Более ущербного синтаксиса, чем у sql, представить сложно А сабж читается легко, Аноним (19), 17:07 , 26-Июл-23, (18) +2

Ирония в том что ты считаешь что твоя лапша удобнее sql , Аноним (20), 17:11 , 26-Июл-23, (21)

лапша 8212 это WITH table_1 AS SELECT customer_id, total - 0 8 AS _expr_0, , Аноним (19), 17:21 , 26-Июл-23, (25)

Форматирование спасёт отца русской демократии , Аноним (29), 17:39 , 26-Июл-23, (29) +7
Объсни что не так Если ты не умеешь форматирование это не значит что все не уме, Аноним (28), 17:40 , 26-Июл-23, (30) +5
Отформатировать и будет все понятно Да, запрос очень простой Когда попишешь за, Аноним (4), 18:21 , 26-Июл-23, (33)
навалил в одну строку черти что - чертичто и называется лапшой, а не SQL ты пут, Аноним (38), 18:44 , 26-Июл-23, (43)

для программистов есть query builder-ы на том языке, на котором само приложение , Аноним (45), 18:53 , 26-Июл-23, (46)

тут как раз один язык запросов и биндинги под разные языки и бд, амоним (?), 19:03 , 26-Июл-23, (50)

Это плохо , Аноним (20), 19:45 , 26-Июл-23, (56)
А зачем Сколько раз в жизни приходилось переносить код query builder-а с одного , Аноним (45), 22:37 , 26-Июл-23, (77)

В чем сложность понимания реляционной алгебры Это что за такие сложности , Аноним (38), 18:42 , 26-Июл-23, (39)

ну если таблиц пара - легко а если 25 д, агалитика, та самая , то схему данных, амоним (?), 20:48 , 26-Июл-23, (70) –1

show tables 87 rows in set 0 000 sec , penetrator (?), 07:50 , 27-Июл-23, (98)

explain запроса сделай и посмотри, сколько там в плане шагов 87 таблиц может бы, Аноним (4), 14:56 , 27-Июл-23, (113)

я же не долбаеб делать такую убогую структуру базу данных, чтобы потом костылить, penetrator (?), 20:09 , 27-Июл-23, (120)

Короче наплодили сущностей, данных у вас толком нет, запросы простые Понтов мно, Аноним (117), 15:25 , 28-Июл-23, (135) –1

смешались у тебя кони люди в одном сообщении с логикой у тебя бедав этой бд , penetrator (?), 19:59 , 28-Июл-23, (139)

Когда у тебя большие таблицы, помимо схемы тебе надо думать еще и о количестве д, Аноним (117), 00:47 , 29-Июл-23, (140)

почитай оригинальный коментарий, и что именно обсуждаетсянет никакой сложности д, penetrator (?), 20:28 , 29-Июл-23, (141)

человек пытается сказать, что чем объемнее таблицы, тем аккуратнее надо быть при, амоним (?), 14:17 , 01-Авг-23, (143)

уже все давно придумано, называется CASE Tools, в частности для Data Modelingи н, penetrator (?), 00:21 , 03-Авг-23, (150)

Да меня это тоже удивляет, но 90 кандидатов на собеседованиях валятся на просте, Аноним (45), 16:27 , 27-Июл-23, (115)

а где биндинги для с и с , Васян из васяна (?), 17:01 , 26-Июл-23, (16) +1

Тут https github com PRQL prql tree main bindings prql-lib, Анонин (?), 20:07 , 26-Июл-23, (61)
лол, будто ты что-то пишешь на них, Аноним (80), 01:17 , 27-Июл-23, (83)

О Они переизобрели Natural Был такой язык для СУБД ADABAS в 80х 50 лет и к, 1 (??), 17:13 , 26-Июл-23, (22) +1

У меня устойчивое дежа-вю, что лет 10 назад уже было нечто похожее , Аноним (4), 18:22 , 26-Июл-23, (34)
Про любой язык так можно сказать Ничего они не переизобретали , Аноним (38), 18:44 , 26-Июл-23, (42) –1

Сейчас бы делать абстракцию над абстракцией И с SQL то не всегда непонятно как б, Аноним2 (?), 17:14 , 26-Июл-23, (23)

В чем тут непонятность И в чем не понятность как база будет запрос обрабатывать, Аноним (38), 18:43 , 26-Июл-23, (40)
Может быть просто надо вылезти из 2002 года и начать уже опльзоваться современны, Аноним (38), 18:43 , 26-Июл-23, (41)
Как будет выполняться запрос никак с SQL вообще не связано , Аноним (146), 15:40 , 02-Авг-23, (148)

Да вдогонку к 1 22 - это будет новый микросервисный, объекто-ориентированный, 1 (??), 17:21 , 26-Июл-23, (26)

как будто это что-то плохое, амоним (?), 20:40 , 26-Июл-23, (69)

Ты, наверное, любитель стимпанка , 1 (??), 09:21 , 27-Июл-23, (103)

Хороший язык На нём можно даже ОС написать , ИмяХ (?), 19:41 , 26-Июл-23, (54) +1

Почему никто не написал , Аноним (20), 19:44 , 26-Июл-23, (55)

говорят, написали, амоним (?), 20:51 , 26-Июл-23, (71)

PL pgSQL - меня вполне устраивает, а мускулём или машей не пользуюсь в сложных п, EuPhobos (ok), 19:58 , 26-Июл-23, (58) –1

Процедурки над сиквелом, кроме Оракла, везде плохо В Слоне тоже Использовать м, Аноним (146), 15:42 , 02-Авг-23, (149)

переизобрели 1с --для разового запроса, оно, возможно, подойдёт но если юзер ид, Bob (??), 20:11 , 26-Июл-23, (62) +1

угу, а потом отгребать нетестируемые баги из-за смеси непонятно каких подзапросо, амоним (?), 20:35 , 26-Июл-23, (67) –1
Да какой 1С, он вообще на всяких кассиров пятьорочки рассчитан и хотя бы концепт, C00l_ni66a (ok), 21:36 , 26-Июл-23, (73) –1

PR QL - в названии вся суть Такое ощущение, что ребятам от моднявок даже в SQL с, Tron is Whistling (?), 22:27 , 26-Июл-23, (76) +2
Скрыто модератором, Аноним (79), 01:03 , 27-Июл-23, (79) –1
SQL - декларативный, PROL - не декларативный, не процедурный и не объектный А, Простоник (ok), 08:39 , 27-Июл-23, (99)
Аналитические запросы - это когда запрашивают отдельные огромные столбцы и сразу, Пряник (?), 09:31 , 27-Июл-23, (104)

Apache Phoenix, Простоник (ok), 13:48 , 27-Июл-23, (110)
ClickHouse, ptr (??), 07:24 , 28-Июл-23, (132) +1
например Vertica, амоним (?), 14:26 , 01-Авг-23, (144)

А уже есть такой язык, наз-ся dplyr dbplyr из R Точно также может трансли, Анонимчик (?), 10:05 , 27-Июл-23, (106)
Выглядит прилично, посмотрим, что из этого выйдет, yilativs (?), 13:37 , 27-Июл-23, (108)
Не взлетит Можете скринитьЯ подобную поделку лет 15 назад делал, потом понял чт, vitalif (ok), 13:55 , 27-Июл-23, (111) +1
Они сделали версию Mule DataWave У мула эта штука очень удобная, но применимая , 3draven (ok), 16:36 , 27-Июл-23, (116)
Я только не понял - как тут с оконными функциями жить, вроде LAG, LEAD и т п - , ptr (??), 07:36 , 28-Июл-23, (133)

Сообщения [Сортировка по времени | RSS]

1. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +13 +/–

Сообщение от Аноним (1), 26-Июл-23, 16:25

а если сразу на SQL писать?

Ответить | Правка | Наверх | Cообщить модератору

2. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +22 +/–

Сообщение от Perlovka (ok), 26-Июл-23, 16:26

Тогда PR не будет

Ответить | Правка | Наверх | Cообщить модератору

27. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +2 +/–

Сообщение от Дмитрий (??), 26-Июл-23, 17:32

Если если sql не больше нескольких строк то не проблема.
У Sql есть недостаток. Он не модульный.
Нельзя сказать этот запрос такой же как этот только с небольшими изменения. У нас в проекте огромные запросы (по 3-4 страницы) а ещё код копипастится с десяток раз. Это очень плохо, код становится плохо поддерживаемым.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

28. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +5 +/–

Сообщение от Аноним (28), 26-Июл-23, 17:38

А ты не думал почему вы продолжаете делать именно так? Может потому что по другому просто не может работать?

Ответить | Правка | Наверх | Cообщить модератору

31. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Твайлайт Спаркл (ok), 26-Июл-23, 17:59

views не помогает? Или динамический sql?

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

53. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +2 +/–

Сообщение от Дмитрий (??), 26-Июл-23, 19:39

Да, динамический sql подходит. Но если генерируется то что должно создаваться руками - это признак что язык который генерируется - плохой.

Ответить | Правка | Наверх | Cообщить модератору

38. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +3 +/–

Сообщение от Аноним (38), 26-Июл-23, 18:41

Код писать нормально просто надо. Это у вас проблемы, а не у SQL

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

52. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Rodegast (ok), 26-Июл-23, 19:22

про хранимки не слышал?

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

57. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от Дмитрий (??), 26-Июл-23, 19:47

Реляционные базы и так плохо маштабируются. Как будет производительность с хранимкам не знаю, но да, там с повторным использованием кода получше

Ответить | Правка | Наверх | Cообщить модератору

63. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Rodegast (ok), 26-Июл-23, 20:18

> Как будет производительность с хранимкам не знаю
Тебе никто не мешает сделать хранимку с обычным SQL-ом.

Ответить | Правка | Наверх | Cообщить модератору

130. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от Дмитрий (??), 28-Июл-23, 00:43

>Тебе никто не мешает сделать
>хранимку с обычным SQL-ом.
Тогда непонятно для чего хранимка

Ответить | Правка | Наверх | Cообщить модератору

85. "Опубликован PRQL, компилируемый в SQL язык обработки данных" –3 +/–

Сообщение от Аноним (85), 27-Июл-23, 01:57

Категорически не советую никакие "хранимки" - мало того, что это в принципе уё6ство - писать на кривом недоязыке "процедуры" (привет новичкам проекта!), так ещё они не переносимы. Идеальная схема: СУБД исключительно для данных, вся логика на апп-сервере. В случае чего - можно СУБД даже полностью сменить, не говоря о простоте портирования на более свежие версии.

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

86. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +2 +/–

Сообщение от Прохожий (??), 27-Июл-23, 03:07

>Идеальная схема
Отнюдь не идеальная. Как вы целостность данных собираетесь обеспечивать, если кто-то решит мимо сервера приложений нагадить?
Как обеспечивать непротиворечивость данных, если будет больше одного сервера приложений?
>В случае чего - можно СУБД даже полностью сменить
Чего, например?
>не говоря о простоте портирования на более свежие версии
Какие там сложности?

Ответить | Правка | Наверх | Cообщить модератору

117. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (117), 27-Июл-23, 16:56

Если кто-то может мимо сервера приложений "гадить", найдется и DBA, который это дело поправит.

Ответить | Правка | Наверх | Cообщить модератору

121. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Прохожий (??), 27-Июл-23, 20:21

Но к тому времени уже может оказаться поздно что-либо поправлять.

Ответить | Правка | Наверх | Cообщить модератору

151. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (151), 06-Янв-24, 06:02

> если кто-то решит мимо сервера приложений нагадить?
Давай такие ТУХЛЫЕ аргументы не приводить? А то я скажу, что у тебя нет защиты от "уборщица пришла с пылесосом и выдернула розетку сервера". Ты как-то мыслишь вообще не по-программистски.
> Как обеспечивать непротиворечивость данных, если будет больше одного сервера приложений?
А в чём именно проблема-то?? Подробнее.
> Чего, например?
Чего "чего"? ДВИЖОК сменить! Что непонятного?
> Какие там сложности?
Все те же сложности, как и перенос чего-либо вообще на другой физический сервер - то с форматом дат напутали, то нашлись неконсистентные данные, то надо перенести блобы из файловой системы в новое место (а в старой базе пути). Я не просто про "бэкап-рестор", а аккуратный перенос данных, потому что незачем тащить на новый сервер все старые атавизмы. И конечно процедуры - обратная совместимость у них есть, но как всегда найдётся энтузазист, который захочет переписать короче (а ради чего тогда прогресс??). И вот уже у вас ДВЕ версии хранимок.
Я не понимаю, зачем вообще что-либо писать на сервере, используя неуклюжий T/SQL или PL/SQL. Есть родной ЯП, пусть даже это и пестон какой-нть, какой смысл ОТДЕЛЬНО писать на ещё одном языке??

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

88. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +2 +/–

Сообщение от Аноним (88), 27-Июл-23, 04:21

Такая схема подходит для небольших, средних проектов. Они могут себе позволить "эксперименты" с "а давай сегодня сменим СУБД на ту, а через месяц на вон ту...".

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

89. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +2 +/–

Сообщение от ойвэй (?), 27-Июл-23, 04:38

> В случае чего - можно СУБД даже полностью сменить
Постоянно слышу этот аргумент, а в реальности как часто проекты меняют СУБД?

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

101. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от 1 (??), 27-Июл-23, 09:08

Вот прям сейчас идёт масштабный эксперимент по смене Oracle на PostgreSQL.
Даже при том, что внутренний язык подогнали, всё идёт как-то не очень.

Ответить | Правка | Наверх | Cообщить модератору

118. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от Аноним (117), 27-Июл-23, 16:58

Потому что нельзя за год "подогнать" то, что создавалось десятки лет. Могли бы сменить парадигму, раз уж такое дело, но нет - хотят бесплатный оракл, альтернативные подходы не хотят.

Ответить | Правка | Наверх | Cообщить модератору

145. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Нанонимус53 (?), 02-Авг-23, 01:01

Речь не про "бесплатный Oracle", а про импортозамещение в связи с тем что Oracle теперь в РФ не продаётся.

Ответить | Правка | Наверх | Cообщить модератору

114. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Rodegast (ok), 27-Июл-23, 15:02

> Категорически не советую никакие "хранимки"
Человеку надо переиспользовать SQL. Хранимки для этого вполне подходят. Можно ещё и CTE использовать, но оно без параметров.
> в принципе уё6ство - писать на кривом недоязыке
Язык SQL.

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

137. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (137), 28-Июл-23, 19:13

Есть разница между бизнес-логикой и логикой целостности данных. Не всё можно уложить в constraints.
Типичный случай - умышленная денормализация в целях повышения производительности, например, всякие счётчики.
В Постгресе в большинстве случаев можно обойтись CREATE RULE, описывая событие и реакцию на него на чистом SQL. Это, конечно, не портабельно, но и триггеры-хранимки тоже не портабельны, зато не возникает соблазна засунуть туда ващевсё

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

122. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Прохожий (??), 27-Июл-23, 20:31

> Реляционные базы и так плохо масштабируются.
Зависит от архитектуры приложения вобще-то. Например, отдельные модули в отдельной схеме (базе данных) без сильных связей с другими схемами (базами данных) вполне себе отлично разносятся по разным хостам. Есть и другие способы разнесения нагрузки, типа репликации мастер-мастер, мастер-ведомый, и так далее.
Да, это не "СУБД" типа "ключ-значение", но зато РСУБД и гораздо больше чего умеет из коробки.
А так серебряной пули не бывает.

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

91. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от Аноним (91), 27-Июл-23, 05:50

так прекратите писать sql-спагетти, и разгребите ваши запросы.
у вас видимо текучка кадров большая  :)

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

94. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +3 +/–

Сообщение от Аноним (94), 27-Июл-23, 06:56

Чта?!
Во первых в sql есть view.
Во вторых with.
Что покрывает все потребности в модульности.

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

134. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от ptr (??), 28-Июл-23, 08:47

VIEW, CTE и функции, включая табличные, решают проблему лишь частично.
Мне радикально решить проблему модульности удалось лишь препроцессингом SQL кода средствами C препроцессора. Вот когда появились включаемые файлы и макросы - тогда действительно код стал модульным.
К сожалению, инлайн код в запросе намного производительней, чем тот же код, вынесенный в функции. А у меня даже такие запросики возникают: https://github.com/dbeaver/dbeaver/issues/10680 (смотрите аттач в zip). При том, что до препроцессора, это вполне себе компактный запрос:
SELECT ROUND(Q.Rez-UC_DISCOUNT,0)+CALC_JA_TOTAL
FROM ...

Ответить | Правка | Наверх | Cообщить модератору

119. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (117), 27-Июл-23, 17:24

Модулей в SQL быть не может, однако от дублирования избавиться можно.
1) Можно повторяющийся SQL инклюдить из файла.
2) Можно написать класс билдера запросов для моделей, одноклассники которого смогут экспортировать миксины для построения запроса, а также использовать их для построения своих запросов. Очень грубо, можно передать список вещей, которые нужно добавить в те или иные части запроса, и что нужно потом сделать с результатом запроса. Например, можно добавить в группировку и в селект, а после исполнения развернуть group_concat в массивчик айдишек и т.д. В одном из проектов я такую вещь сделал и несмотря на некую навороченность кода, SQL существовал в единственном экземпляре. Запросы на экран и более были нормой, да.

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

123. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Прохожий (??), 27-Июл-23, 20:41

> Модулей в SQL быть не может
Я бы не был столь категоричным. View - вполне себе самостоятельный модуль. Есть и ещё, попроще, не так, чтобы модули, но вполне нормальный способ сократить дублирование кода. В Oracle использование функций в теле SQL-запроса подвезли с 19-й версии. Кроме того, есть with, как уже отметили выше.

Ответить | Правка | Наверх | Cообщить модератору

136. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (117), 28-Июл-23, 15:35

Фактически это макросы. Подсократить запросы получится, спору нет.

Ответить | Правка | Наверх | Cообщить модератору

131. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от ptr (??), 28-Июл-23, 07:15

Проблему решает просто препроцессинг SQL кода, например, C препроцессором. Сразу же SQL модульный становится, благодаря макросам и включаемым файлам.

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

146. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (146), 02-Авг-23, 15:15

Это изврат ради изврата. Сиквелу совершенно ни к чему быть модульным.

Ответить | Правка | Наверх | Cообщить модератору

32. "Опубликован PRQL, компилируемый в SQL язык обработки данных" –4 +/–

Сообщение от Аноним (32), 26-Июл-23, 18:03

Тогда навеки один sql и отсанется. Тут же есть шанс дать аналитику UML- инструмент, а когда понадобиться скомпилировать, к примеру, в код для Pandas, своей биг даты и т.п.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

124. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Прохожий (??), 27-Июл-23, 20:46

Для Pandas, если не ошибаюсь, есть отдельный модуль, который позволяет обращаться к библиотеке в виде диалекта SQL. А всё почему? А всё потому, что родной API библиотеки Pandas для конструирования сколь-либо сложных запросов - редкое г..ще.

Ответить | Правка | Наверх | Cообщить модератору

37. "Опубликован PRQL, компилируемый в SQL язык обработки данных" –3 +/–

Сообщение от Карлос Сношайтилис (ok), 26-Июл-23, 18:40

Пиши. Сразу на несколько диалектов. И переписывай. И поддерживай. Никаких проблем. Ещё хранимками обмазаться для полноты ошушений.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

60. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от Bob (??), 26-Июл-23, 20:06

вася - лечись давай.
--
на ккой ляд на несколько диалектов писать?
2 субд понянешь за раз?)

Ответить | Правка | Наверх | Cообщить модератору

127. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от fuggy (ok), 27-Июл-23, 21:15

Писать на SQL и компилировать в PRQL. И технологию поиспользовали и волки довольны. Да по сути он ничем не отличается, просто порядок поменяли и функции поменяли на нечитаемые символы. В чём удобство? В том что нужно учить новый язык, которые затухнет через полгода?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. Скрыто модератором –3 +/–

Сообщение от Аноним (3), 26-Июл-23, 16:28

Посредники всегда источник проблем. Кроме того, тут точно будет куча багов из-за ржавчины. Я раньше нейтрально относился к ней, но это удивительно гнилая экосистема с низкоквалифицированным комьюнити разработчиков.

Ответить | Правка | Наверх | Cообщить модератору

20. Скрыто модератором +/–

Сообщение от Аноним (20), 26-Июл-23, 17:10

Так и сабж низкоквалифицированный. Для бенчмарков, которые они будут показывать тем кто ничего не понимает.

Ответить | Правка | Наверх | Cообщить модератору

4. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +4 +/–

Сообщение от Аноним (4), 26-Июл-23, 16:32

То какую-то императивщину вместо регулярок, то SQL лишь бы не писать... Эпоха ORM все? Оказались слишком сложны/тупы и нужен все-таки язык запросов? Теперь начинаем языки запросов лепить?
>как в Python
Кто занимается подобной ерундой? Ну конечно же они - питонисты.

Ответить | Правка | Наверх | Cообщить модератору

7. "Опубликован PRQL, компилируемый в SQL язык обработки данных" –1 +/–

Сообщение от Аноним (7), 26-Июл-23, 16:37

>ORM
это вообще хлам. Годится для тупого хранения данных и доступа к ним по ключу только. Движок и оптимизатор запроса в базе данных они не задействуют.

Ответить | Правка | Наверх | Cообщить модератору

87. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от Ruslan (??), 27-Июл-23, 03:42

Дружище, оптимизатор запросов задействует сама СУБД. Ей навалить как был запрос сформирован - руками написан или сгенерирован ORMкой. Для СУБД нет разницы. Так что странное высказывание.

Ответить | Правка | Наверх | Cообщить модератору

90. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от cheburnator9000 (ok), 27-Июл-23, 05:28

Нормальные orm поверх sql баз данных предоставляют очень многого всего чего иначе пришлось бы писать самому. Миграции, транзакции, сериализация данных на структуры в ЯП, логгер, даже всякие плагины к ORM, очередь на запись чтение даже внутри простого приложения. Другое дело что нормальных ORM реально практически не существует, я перепробовал почти все как для Go так и для Python, у всех адская боль и безобразие при работе с Many To Many relations. Many To Many можно реализовать практически каждым из типов JOIN но каждая ORM делает по своему. Есть такая проприетарная вендовая тулза Data Extractor v3 так вот она может оптимизировать SQL запросы сгенерированные каждым из ORM, то есть там с эффективностью тоже проблемы. Все из-за того что синтаксис SQL это устаревший шлак времен ледникового периода.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

125. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от Прохожий (??), 27-Июл-23, 20:51

> нормальных ORM реально практически не существует
Это правда.
> синтаксис SQL это устаревший шлак времен ледникового периода
А это - нет. В чём конкретно его недостатки? В том, что ORM фигню генерирует? Но причём тут SQL?

Ответить | Правка | Наверх | Cообщить модератору

138. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (137), 28-Июл-23, 19:17

https://docs.sqlalchemy.org/en/20/orm/basic_relationships.ht...
Чего не хватает?

Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

96. "Опубликован PRQL, компилируемый в SQL язык обработки данных" –1 +/–

Сообщение от penetrator (?), 27-Июл-23, 07:45

ORM разные бывают, хлам - это твой коментарий, в нем нет даже доли истины
это как со сломанными часами, которые показывают правильное время 2 раза в сутки

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

126. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Прохожий (??), 27-Июл-23, 20:56

> ORM разные бывают, хлам - это твой коментарий, в нем нет даже доли истины
Есть, конечно. ORM с точки зрения конечной производительности системы - это часто хлам. Обычно квалифицированный программист формирует куда как более эффективные запросы, чем вот эти поделия.

Ответить | Правка | Наверх | Cообщить модератору

128. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от penetrator (?), 27-Июл-23, 21:18

>> ORM разные бывают, хлам - это твой коментарий, в нем нет даже доли истины
> Есть, конечно. ORM с точки зрения конечной производительности системы - это часто
> хлам. Обычно квалифицированный программист формирует куда как более эффективные запросы,
> чем вот эти поделия.
брехня, "квалифицированный программист" не использует плохие орм, а те, которые пригодны точно знает как надо использовать, чтобы код получался такой же как и при ручном его написании

Ответить | Правка | Наверх | Cообщить модератору

147. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (146), 02-Авг-23, 15:36

Нет, проблема ORM-ов не в адекватности запросов -- в сиквеле пофиг как ты написал, гадалка всё равно сделает так, как нужно, главное, чтоб логически было верное выражение, а у ОРМов с этим более-менее. У ORM-ов просто много накладных расходов. А сейчас ещё и добавляет то, что вошли в моду ормы поверх ормов и поверх ормов. В  той же java сейчас модно лепить всякую жуть над jpa.

Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

19. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (19), 26-Июл-23, 17:10

хорошо хоть АКТИВ РЕКОРД не вспомнил

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

36. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +2 +/–

Сообщение от мимо (?), 26-Июл-23, 18:25

А что с ним не так? Можно развернуто?

Ответить | Правка | Наверх | Cообщить модератору

45. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (45), 26-Июл-23, 18:51

Если вся логика - это тупой crud, то ничего плохого в нем нет. А вот когда сложную бизнес-логику пытаются запихать в AR, начинается полная жесть.
https://www.mehdi-khalili.com/orm-anti-patterns-part-1-activ...
"active record gone crazy"

Ответить | Правка | Наверх | Cообщить модератору

95. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Бывалый смузихлёб (?), 27-Июл-23, 07:09

Другое дело, что 9 из 10 проектов - аккурат круд и есть

Ответить | Правка | Наверх | Cообщить модератору

47. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от амоним (?), 26-Июл-23, 18:56

может эксперт и не вкурсе, но АКТИВ РЕКОРД это собссно один из способов реализации ORM. подсказка: второй - это ДАТА МАППЕР.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

97. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от penetrator (?), 27-Июл-23, 07:47

а Linq provider это куда? )))

Ответить | Правка | Наверх | Cообщить модератору

105. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Онанистмус (?), 27-Июл-23, 09:37

LINQ это язык запросов. ORM на которую мапятся LINQ запросы это Entity Framework. Entity Framework это паттерн Data mapper, не active record.

Ответить | Правка | Наверх | Cообщить модератору

6. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +2 +/–

Сообщение от Аноним (6), 26-Июл-23, 16:35

А как он будет оптимизировать запрос под конкретные базы? И не только запрос, но и схему самих баз. Мне однажды пришлось паковать два поля в целое число - rowid для SQLite. По другому было бы жутко медленно. А так был жутко медленный импорт, а остальные релевантные запросы - быстры.

Ответить | Правка | Наверх | Cообщить модератору

8. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от BorichL (ok), 26-Июл-23, 16:38

Да оно просто рассчитано только на примеры из книжки "SQL для начинающих".

Ответить | Правка | Наверх | Cообщить модератору

49. "Опубликован PRQL, компилируемый в SQL язык обработки данных" –2 +/–

Сообщение от амоним (?), 26-Июл-23, 19:02

боюсь, что начинающий тут ты. оно предлагает написать руками по сути query execution plan.
из минусов, только 2 конверсии внутри в скл, и в план обратно.

Ответить | Правка | Наверх | Cообщить модератору

51. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от BorichL (ok), 26-Июл-23, 19:03

> боюсь, что начинающий тут ты. оно предлагает написать руками по сути query
> execution plan.
> из минусов, только 2 конверсии внутри в скл, и в план обратно.
Да? И какой сервер его будет выполнять?

Ответить | Правка | Наверх | Cообщить модератору

65. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от амоним (?), 26-Июл-23, 20:27

а там вариантов много... пг, мускл, мс скл и проч
прям "в ассортименте"

Ответить | Правка | Наверх | Cообщить модератору

80. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от Аноним (80), 27-Июл-23, 01:09

> Да оно просто рассчитано только на примеры из книжки "SQL для начинающих".
но и ты ее не осилил

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

112. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от BorichL (ok), 27-Июл-23, 14:36

>> Да оно просто рассчитано только на примеры из книжки "SQL для начинающих".
> но и ты ее не осилил
Естественно, я ж тебе не начинающий!

Ответить | Правка | Наверх | Cообщить модератору

10. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Golangdev (?), 26-Июл-23, 16:39

> Обвязки для использования PRQL развиваются для языков Java, JavaScript, .NET, Elixir, R, Rust, PHP и Python
Я негодую! Где поддержка Go ?!

Ответить | Правка | Наверх | Cообщить модератору

35. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Карлос Сношайтилис (ok), 26-Июл-23, 18:24

Там прослойка элементарная - преобразование строк и прокидывание опций транслятору, даже раст не особо нужно знать.
Прояви себя вместо негодования - набросай свою интеграцию.

Ответить | Правка | Наверх | Cообщить модератору

44. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (38), 26-Июл-23, 18:45

О чем ты? Какая поддержка? Го для хиптанов. А PRQL для нормальных людей. Они с хиптанами не связываются.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

64. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (64), 26-Июл-23, 20:19

> Rust

Ответить | Правка | Наверх | Cообщить модератору

12. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +7 +/–

Сообщение от Аноним (45), 26-Июл-23, 16:41

Каким образом это проще SQL?
Сложность SQL в понимании реляционной алгебры, а это никакими изменениями синтаксиса не решить: тут либо понял, либо нет.
А читается эта фигня точно сложнее, чем SQL.

Ответить | Правка | Наверх | Cообщить модератору

17. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от alin (?), 26-Июл-23, 17:02

Проще чем кажется, на самом деле.

Ответить | Правка | Наверх | Cообщить модератору

18. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +2 +/–

Сообщение от Аноним (19), 26-Июл-23, 17:07

> читается эта фигня точно сложнее, чем SQL
Более ущербного синтаксиса, чем у sql, представить сложно. А сабж читается легко, на уровне привычного разрабам array.filter(...).groupBy(...).filter(...).sort(...).
Ирония в том, что sql начинался как язык для непрограммистов. Типа бухгалтеры будут напрямую вбивать запросы на английском языке. Оказалось, что язык, изначально рассчитанный для программистов, читается легче, чем тот, что рассчитывался для непрограммистов. Сравни синтаксис си и бейсика например. В си все предсказуемо, а в бейсике каждая новая функция -- это каждый раз новый синтаксис.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

21. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (20), 26-Июл-23, 17:11

Ирония в том что ты считаешь что твоя лапша удобнее sql.

Ответить | Правка | Наверх | Cообщить модератору

25. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (19), 26-Июл-23, 17:21

> лапша
лапша — это 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

Ответить | Правка | Наверх | Cообщить модератору

29. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +7 +/–

Сообщение от Аноним (29), 26-Июл-23, 17:39

Форматирование спасёт отца русской демократии!

Ответить | Правка | Наверх | Cообщить модератору

30. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +5 +/–

Сообщение от Аноним (28), 26-Июл-23, 17:40

Объсни что не так? Если ты не умеешь форматирование это не значит что все не умеют в форматирование.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

33. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (4), 26-Июл-23, 18:21

Отформатировать и будет все понятно. Да, запрос очень простой. Когда попишешь запросы сложные, расхочется заменять на императивщину.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

43. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (38), 26-Июл-23, 18:44

навалил в одну строку черти что - чертичто и называется лапшой, а не SQL. ты путаешься.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

46. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (45), 26-Июл-23, 18:53

для программистов есть query builder-ы на том языке, на котором само приложение.
Тот же SQLAlchemy ничем не хуже (и даже лучше) описанного, при этом нет никакого разделения на разные языки.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

50. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от амоним (?), 26-Июл-23, 19:03

тут как раз один язык запросов и биндинги под разные языки и бд

Ответить | Правка | Наверх | Cообщить модератору

56. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (20), 26-Июл-23, 19:45

Это плохо.

Ответить | Правка | Наверх | Cообщить модератору

77. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (45), 26-Июл-23, 22:37

А зачем?
Сколько раз в жизни приходилось переносить код query builder-а с одного языка программирования на другой? Большинству 0, кому-то, может, 1 раз за 10 лет.
При этом query builder на том же языке, что и всё приложение, имеет очевидные преимущества как по интеграции с остальным кодом, так и по использованию инструментария.

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

39. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (38), 26-Июл-23, 18:42

В чем сложность понимания реляционной алгебры? Это что за такие сложности?

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

70. "Опубликован PRQL, компилируемый в SQL язык обработки данных" –1 +/–

Сообщение от амоним (?), 26-Июл-23, 20:48

ну если таблиц пара - легко. а если 25 (д, агалитика, та самая), то схему данных удерживать в голове... на 24 шага слияния... сложно.
но может есть гении..

Ответить | Правка | Наверх | Cообщить модератору

98. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от penetrator (?), 27-Июл-23, 07:50

show tables;
87 rows in set (0.000 sec)

Ответить | Правка | Наверх | Cообщить модератору

113. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (4), 27-Июл-23, 14:56

explain запроса сделай и посмотри, сколько там в плане шагов. 87 таблиц может быть из-за того, что 5 сервисов в одну базу сpут. Половина таблиц справочники. Знаем мы вас. Сколько из этих табличек содержат более 100000 строк?
У тебя есть запросики, где ты одну и ту же табличку джойнишь чуть-чуть по-разному 3-5 раз? Колбасы из 10-20 лефт джойнов, зависящие друг от друга и от 5 иннер джойнов выше? Запросы более чем в пару экранов в высоту? Случалось ли придумывать логику запроса больше трех дней, а не за чашечкой кофе?

Ответить | Правка | Наверх | Cообщить модератору

120. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от penetrator (?), 27-Июл-23, 20:09

> У тебя есть запросики, где ты одну и ту же табличку джойнишь чуть-чуть по-разному 3-5 раз? Колбасы из 10-20 лефт джойнов, зависящие друг от друга и от 5 иннер джойнов выше?
> Случалось ли придумывать логику запроса больше трех дней, а не за чашечкой кофе?
я же не долбаеб делать такую убогую структуру базу данных, чтобы потом костылить это запросами
сложные запросы конечно есть, но то, что ты написал это не маст-хэв
> Половина таблиц справочники.
конкретно в этой БД, справочников нет вообще
> Знаем мы вас.
ты и себя то с трудом )))
> Сколько из этих табличек содержат более 100000 строк?
если речь о "схему данных удерживать в голове" то какая разница, это таблица на 100 тыс, 5 тыс, или вообще очищаемая очередь?
> 87 таблиц может быть из-за того, что 5 сервисов в одну базу сpут.
это одно веб приложение, параллельно с ним в базу обращаются только сервисы например занимающиеся почтовой рассылкой, но ВНЕЗАПНО )) обращающиеся к тем же таблицам, даже если предположить, что их 5 (почта + еще 4 каких-то), то для контроля состояния фонофых задач, на каждый тип задачи не потребуется больше одной таблицы, т.е. условно 82 вместо 87
так что ты там знаешь? ))))

Ответить | Правка | Наверх | Cообщить модератору

135. "Опубликован PRQL, компилируемый в SQL язык обработки данных" –1 +/–

Сообщение от Аноним (117), 28-Июл-23, 15:25

Короче наплодили сущностей, данных у вас толком нет, запросы простые. Понтов много :)
У меня стабильно проекты, где больше 100 только основных сущностей, а всякие связи вообще никто не считает.
>это не маст-хэв
Начальству как будешь объяснять, что им на самом деле не нужны эти данные/отчеты/аналитика?
>какая разница, это таблица на 100 тыс, 5 тыс, или вообще очищаемая очередь?
С таблицами на 5 тысяч можно писать в принципе любые запросы и ничего тормозить не будет, с 100т уже требуется думать головой, а когда часть таблиц имеет миллионы и десятки миллионов строк, уже приходится как-то изворачиваться.
Понятно, если ты г-кодишь новые проекты, ты никогда не увидишь ничего подобного. Пустые таблицы, не усложненная нюансами практики бизнес-логика, аналитики нет или она в зачатке.

Ответить | Правка | Наверх | Cообщить модератору

139. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от penetrator (?), 28-Июл-23, 19:59

смешались у тебя кони люди в одном сообщении ))) с логикой у тебя беда
в этой бд есть таблицы на десятки миллионов строк, но какое отношение это имеет к "удержанию в голове СХЕМЫ"?

Ответить | Правка | Наверх | Cообщить модератору

140. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (117), 29-Июл-23, 00:47

Когда у тебя большие таблицы, помимо схемы тебе надо думать еще и о количестве данных. Не сталкивался с таким? Ну да, это не маст-хэв, ведь у тебя работу принимают с пустыми базами.

Ответить | Правка | Наверх | Cообщить модератору

141. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от penetrator (?), 29-Июл-23, 20:28

почитай оригинальный коментарий, и что именно обсуждается
нет никакой сложности держать схему базы данных больше 24 таблиц в голове (количества строк это вообще не касается), может поэтому тебе и тяжело держать все голове потому что там постоянная каша из котлет и мух?

Ответить | Правка | Наверх | Cообщить модератору

143. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от амоним (?), 01-Авг-23, 14:17

> почитай оригинальный коментарий, и что именно обсуждается
> нет никакой сложности держать схему базы данных больше 24 таблиц в голове
> (количества строк это вообще не касается), может поэтому тебе и тяжело
> держать все голове потому что там постоянная каша из котлет и
> мух?
человек пытается сказать, что чем объемнее таблицы, тем аккуратнее надо быть при написании запросов. и тем сложнее держать в умер все ньюансы. если у тебя 25 таблиц - это круто. я видел например базы данных MS Dynamics, в которой если не изменяет память их было больше 4х тысяч. да, бизнес сущностей.
тут проблема в чем - подход который у тебя - бессмысленнаю трата ресурсов мозга. а тот подход, который предлаете интрумент описаный в статье - он позволяет оперировать информацией с меньшими ментальными издержками.

Ответить | Правка | Наверх | Cообщить модератору

150. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от penetrator (?), 03-Авг-23, 00:21

уже все давно придумано, называется CASE Tools, в частности для Data Modeling
и неважно сколько строк в таблицах, запрос к правильно спроектированной БД, будет оптимальным чаще всего только одним единственным способом (если не считать Views), вот его и пишешь независимо от того сколько строк
а подход "там будет строк немного, поэтому тут мы можем недопроектировать или на отъeбись сделать" это не ко мне с такими дискуссиями )))

Ответить | Правка | Наверх | Cообщить модератору

115. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (45), 27-Июл-23, 16:27

Да меня это тоже удивляет, но 90% кандидатов на собеседованиях валятся на простейших вопросах на join-ы.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

16. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от Васян из васяна (?), 26-Июл-23, 17:01

а где биндинги для с++ и с????????????????

Ответить | Правка | Наверх | Cообщить модератору

61. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Анонин (?), 26-Июл-23, 20:07

Тут https://github.com/PRQL/prql/tree/main/bindings/prql-lib

Ответить | Правка | Наверх | Cообщить модератору

83. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (80), 27-Июл-23, 01:17

лол, будто ты что-то пишешь на них

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

22. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от 1 (??), 26-Июл-23, 17:13

О ! Они переизобрели Natural !!! Был такой язык для СУБД ADABAS в 80х.
50 лет и круг замкнулся.
Ещё немного подождать и появится новый SQL "на стероидах"

Ответить | Правка | Наверх | Cообщить модератору

34. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (4), 26-Июл-23, 18:22

У меня устойчивое дежа-вю, что лет 10 назад уже было нечто похожее.

Ответить | Правка | Наверх | Cообщить модератору

42. "Опубликован PRQL, компилируемый в SQL язык обработки данных" –1 +/–

Сообщение от Аноним (38), 26-Июл-23, 18:44

Про любой язык так можно сказать. Ничего они не переизобретали.

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

23. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним2 (?), 26-Июл-23, 17:14

Сейчас бы делать абстракцию над абстракцией.
И с SQL то не всегда непонятно как будет база запрос обрабатывать, а с этой штукой и по давно.
Ну от растоманов ничего другого и не ждал.

Ответить | Правка | Наверх | Cообщить модератору

40. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (38), 26-Июл-23, 18:43

В чем тут непонятность? И в чем не понятность как база будет запрос обрабатывать? Обрадую вас: повсюду тонна инструмнетов для анализа - и это уже давно решенная проблема (обрадую вас №2).

Ответить | Правка | Наверх | Cообщить модератору

41. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (38), 26-Июл-23, 18:43

Может быть просто надо вылезти из 2002 года и начать уже опльзоваться современными инструментами?

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

148. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (146), 02-Авг-23, 15:40

Как будет выполняться запрос никак с SQL вообще не связано.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

26. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от 1 (??), 26-Июл-23, 17:21

Да ... вдогонку к 1.22 - это будет новый микросервисный, объекто-ориентированный, с параллельной обработкой, SQL !!!

Ответить | Правка | Наверх | Cообщить модератору

69. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от амоним (?), 26-Июл-23, 20:40

как будто это что-то плохое

Ответить | Правка | Наверх | Cообщить модератору

103. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от 1 (??), 27-Июл-23, 09:21

Ты, наверное, любитель стимпанка.

Ответить | Правка | Наверх | Cообщить модератору

54. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от ИмяХ (?), 26-Июл-23, 19:41

Хороший язык. На нём можно даже ОС написать.

Ответить | Правка | Наверх | Cообщить модератору

55. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (20), 26-Июл-23, 19:44

Почему никто не написал?

Ответить | Правка | Наверх | Cообщить модератору

71. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от амоним (?), 26-Июл-23, 20:51

говорят, написали

Ответить | Правка | Наверх | Cообщить модератору

58. "Опубликован PRQL, компилируемый в SQL язык обработки данных" –1 +/–

Сообщение от EuPhobos (ok), 26-Июл-23, 19:58

PL/pgSQL - меня вполне устраивает, а мускулём или машей не пользуюсь в сложных проектах, но проект выглядит интересным, нужно будет потыкать палочкой.

Ответить | Правка | Наверх | Cообщить модератору

149. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Аноним (146), 02-Авг-23, 15:42

Процедурки над сиквелом, кроме Оракла, везде плохо. В Слоне тоже. Использовать можно только строго для реализации констраинтов или простейших триггеров.

Ответить | Правка | Наверх | Cообщить модератору

62. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от Bob (??), 26-Июл-23, 20:11

переизобрели 1с?
--
для разового запроса, оно, возможно, подойдёт. но если юзер идийот - то сервер ляжет нахер...
--
а вообще - нехер каждой амёбе давать доступ к базе. знание sql - как тест на профпригодность: можно к отдельным строкам r\o давать и организовать несколько шаблонов запросов)

Ответить | Правка | Наверх | Cообщить модератору

67. "Опубликован PRQL, компилируемый в SQL язык обработки данных" –1 +/–

Сообщение от амоним (?), 26-Июл-23, 20:35

угу, а потом отгребать нетестируемые баги из-за смеси непонятно каких подзапросов, и sql injection, потому, что подставили, ой, нитуда и нито, и ниправерили.

Ответить | Правка | Наверх | Cообщить модератору

73. "Опубликован PRQL, компилируемый в SQL язык обработки данных" –1 +/–

Сообщение от C00l_ni66a (ok), 26-Июл-23, 21:36

Да какой 1С, он вообще на всяких кассиров пятьорочки рассчитан и хотя бы концептуально (ЯП для непрограммистов) смысл имеет. А это - попытка впихнуть ещё один слой абстракции над и так очень абстрактной шелухой, типичный пример поделия от последователей карго-культа.

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

76. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +2 +/–

Сообщение от Tron is Whistling (?), 26-Июл-23, 22:27

PR QL - в названии вся суть.
Такое ощущение, что ребятам от моднявок даже в SQL сложно.

Ответить | Правка | Наверх | Cообщить модератору

79. Скрыто модератором –1 +/–

Сообщение от Аноним (79), 27-Июл-23, 01:03

уточняйте сразу что поделка на расте, чтобы время наше не тратить. Посмотрел cargo.lock и понял что надо выбрасывать: https://github.com/PRQL/prql/blob/main/Cargo.lock

Ответить | Правка | Наверх | Cообщить модератору

99. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Простоник (ok), 27-Июл-23, 08:39

SQL -  декларативный, PROL  - не декларативный, не процедурный и не объектный.
А программисты любят ORM - из объектов ходят в SQL. Это как раз понять можно, автоматические методы CRUD многим нравятся.Хотя даже такое нужно с осторожность использовать.Проблемы с производительностью таки бывают. ORM API есть для C++,Java,Python.
Для чего здесь не объектный PROL и где его место?

Ответить | Правка | Наверх | Cообщить модератору

104. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Пряник (?), 27-Июл-23, 09:31

Аналитические запросы - это когда запрашивают отдельные огромные столбцы и сразу с аггрегацией. Это не про релационные базы данных, где всё строками. А какая вообще аналитическая БД использует SQL?

Ответить | Правка | Наверх | Cообщить модератору

110. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Простоник (ok), 27-Июл-23, 13:48

Apache Phoenix

Ответить | Правка | Наверх | Cообщить модератору

132. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от ptr (??), 28-Июл-23, 07:24

ClickHouse

Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

144. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от амоним (?), 01-Авг-23, 14:26

например Vertica

Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

106. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от Анонимчик (?), 27-Июл-23, 10:05

А уже есть такой язык, наз-ся "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)

Ответить | Правка | Наверх | Cообщить модератору

108. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от yilativs (?), 27-Июл-23, 13:37

Выглядит прилично, посмотрим, что из этого выйдет

Ответить | Правка | Наверх | Cообщить модератору

111. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +1 +/–

Сообщение от vitalif (ok), 27-Июл-23, 13:55

Не взлетит. Можете скринить
Я подобную поделку лет 15 назад делал, потом понял что это нафиг никому не нужный мусор
А в классических книжках был QUEL. И тоже его что-то никто не юзает

Ответить | Правка | Наверх | Cообщить модератору

116. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от 3draven (ok), 27-Июл-23, 16:36

Они сделали версию Mule DataWave? У мула эта штука очень удобная, но применимая к абсолютно любому потоку данных например из сети.

Ответить | Правка | Наверх | Cообщить модератору

133. "Опубликован PRQL, компилируемый в SQL язык обработки данных" +/–

Сообщение от ptr (??), 28-Июл-23, 07:36

Я только не понял:
- как тут с оконными функциями жить, вроде LAG, LEAD и т.п.?
- как сюда GROUPING SETS прикрутить?
- как APPLY/LATERAL описать?
- как с интервалами, диапазонами и массивами этим работать?
- как динамический SQL этим формировать?
Короче, больше вопросов, чем ответов. Этой шняге еще годы и годы расти до возможности практического применения.
Можно, конечно, добавить его, как еще один процедурный язык в PostgreSQL. Но толку?

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+13 +/–
Сообщение от Аноним (1), 26-Июл-23, 16:25
а если сразу на SQL писать?
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+22 +/–
	Сообщение от Perlovka (ok), 26-Июл-23, 16:26
	Тогда PR не будет
	Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+2 +/–
	Сообщение от Дмитрий (??), 26-Июл-23, 17:32
	Если если sql не больше нескольких строк то не проблема. У Sql есть недостаток. Он не модульный. Нельзя сказать этот запрос такой же как этот только с небольшими изменения. У нас в проекте огромные запросы (по 3-4 страницы) а ещё код копипастится с десяток раз. Это очень плохо, код становится плохо поддерживаемым.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	28. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+5 +/–
	Сообщение от Аноним (28), 26-Июл-23, 17:38
	А ты не думал почему вы продолжаете делать именно так? Может потому что по другому просто не может работать?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от Твайлайт Спаркл (ok), 26-Июл-23, 17:59
	views не помогает? Или динамический sql?
	Ответить \| Правка \| К родителю #27 \| Наверх \| Cообщить модератору


	53. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+2 +/–
	Сообщение от Дмитрий (??), 26-Июл-23, 19:39
	Да, динамический sql подходит. Но если генерируется то что должно создаваться руками - это признак что язык который генерируется - плохой.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	38. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+3 +/–
	Сообщение от Аноним (38), 26-Июл-23, 18:41
	Код писать нормально просто надо. Это у вас проблемы, а не у SQL
	Ответить \| Правка \| К родителю #27 \| Наверх \| Cообщить модератору


	52. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от Rodegast (ok), 26-Июл-23, 19:22
	про хранимки не слышал?
	Ответить \| Правка \| К родителю #27 \| Наверх \| Cообщить модератору


	57. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+1 +/–
	Сообщение от Дмитрий (??), 26-Июл-23, 19:47
	Реляционные базы и так плохо маштабируются. Как будет производительность с хранимкам не знаю, но да, там с повторным использованием кода получше
	Ответить \| Правка \| Наверх \| Cообщить модератору


	63. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от Rodegast (ok), 26-Июл-23, 20:18
	> Как будет производительность с хранимкам не знаю Тебе никто не мешает сделать хранимку с обычным SQL-ом.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	130. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+1 +/–
	Сообщение от Дмитрий (??), 28-Июл-23, 00:43
	>Тебе никто не мешает сделать >хранимку с обычным SQL-ом. Тогда непонятно для чего хранимка
	Ответить \| Правка \| Наверх \| Cообщить модератору


	85. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	–3 +/–
	Сообщение от Аноним (85), 27-Июл-23, 01:57
	Категорически не советую никакие "хранимки" - мало того, что это в принципе уё6ство - писать на кривом недоязыке "процедуры" (привет новичкам проекта!), так ещё они не переносимы. Идеальная схема: СУБД исключительно для данных, вся логика на апп-сервере. В случае чего - можно СУБД даже полностью сменить, не говоря о простоте портирования на более свежие версии.
	Ответить \| Правка \| К родителю #57 \| Наверх \| Cообщить модератору


	86. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+2 +/–
	Сообщение от Прохожий (??), 27-Июл-23, 03:07
	>Идеальная схема Отнюдь не идеальная. Как вы целостность данных собираетесь обеспечивать, если кто-то решит мимо сервера приложений нагадить? Как обеспечивать непротиворечивость данных, если будет больше одного сервера приложений? >В случае чего - можно СУБД даже полностью сменить Чего, например? >не говоря о простоте портирования на более свежие версии Какие там сложности?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	117. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от Аноним (117), 27-Июл-23, 16:56
	Если кто-то может мимо сервера приложений "гадить", найдется и DBA, который это дело поправит.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	121. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от Прохожий (??), 27-Июл-23, 20:21
	Но к тому времени уже может оказаться поздно что-либо поправлять.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	151. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от Аноним (151), 06-Янв-24, 06:02
	> если кто-то решит мимо сервера приложений нагадить? Давай такие ТУХЛЫЕ аргументы не приводить? А то я скажу, что у тебя нет защиты от "уборщица пришла с пылесосом и выдернула розетку сервера". Ты как-то мыслишь вообще не по-программистски. > Как обеспечивать непротиворечивость данных, если будет больше одного сервера приложений? А в чём именно проблема-то?? Подробнее. > Чего, например? Чего "чего"? ДВИЖОК сменить! Что непонятного? > Какие там сложности? Все те же сложности, как и перенос чего-либо вообще на другой физический сервер - то с форматом дат напутали, то нашлись неконсистентные данные, то надо перенести блобы из файловой системы в новое место (а в старой базе пути). Я не просто про "бэкап-рестор", а аккуратный перенос данных, потому что незачем тащить на новый сервер все старые атавизмы. И конечно процедуры - обратная совместимость у них есть, но как всегда найдётся энтузазист, который захочет переписать короче (а ради чего тогда прогресс??). И вот уже у вас ДВЕ версии хранимок. Я не понимаю, зачем вообще что-либо писать на сервере, используя неуклюжий T/SQL или PL/SQL. Есть родной ЯП, пусть даже это и пестон какой-нть, какой смысл ОТДЕЛЬНО писать на ещё одном языке??
	Ответить \| Правка \| К родителю #86 \| Наверх \| Cообщить модератору


	88. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+2 +/–
	Сообщение от Аноним (88), 27-Июл-23, 04:21
	Такая схема подходит для небольших, средних проектов. Они могут себе позволить "эксперименты" с "а давай сегодня сменим СУБД на ту, а через месяц на вон ту...".
	Ответить \| Правка \| К родителю #85 \| Наверх \| Cообщить модератору


	89. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+2 +/–
	Сообщение от ойвэй (?), 27-Июл-23, 04:38
	> В случае чего - можно СУБД даже полностью сменить Постоянно слышу этот аргумент, а в реальности как часто проекты меняют СУБД?
	Ответить \| Правка \| К родителю #85 \| Наверх \| Cообщить модератору


	101. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+1 +/–
	Сообщение от 1 (??), 27-Июл-23, 09:08
	Вот прям сейчас идёт масштабный эксперимент по смене Oracle на PostgreSQL. Даже при том, что внутренний язык подогнали, всё идёт как-то не очень.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	118. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+1 +/–
	Сообщение от Аноним (117), 27-Июл-23, 16:58
	Потому что нельзя за год "подогнать" то, что создавалось десятки лет. Могли бы сменить парадигму, раз уж такое дело, но нет - хотят бесплатный оракл, альтернативные подходы не хотят.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	145. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от Нанонимус53 (?), 02-Авг-23, 01:01
	Речь не про "бесплатный Oracle", а про импортозамещение в связи с тем что Oracle теперь в РФ не продаётся.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	114. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от Rodegast (ok), 27-Июл-23, 15:02
	> Категорически не советую никакие "хранимки" Человеку надо переиспользовать SQL. Хранимки для этого вполне подходят. Можно ещё и CTE использовать, но оно без параметров. > в принципе уё6ство - писать на кривом недоязыке Язык SQL.
	Ответить \| Правка \| К родителю #85 \| Наверх \| Cообщить модератору


	137. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от Аноним (137), 28-Июл-23, 19:13
	Есть разница между бизнес-логикой и логикой целостности данных. Не всё можно уложить в constraints. Типичный случай - умышленная денормализация в целях повышения производительности, например, всякие счётчики. В Постгресе в большинстве случаев можно обойтись CREATE RULE, описывая событие и реакцию на него на чистом SQL. Это, конечно, не портабельно, но и триггеры-хранимки тоже не портабельны, зато не возникает соблазна засунуть туда ващевсё
	Ответить \| Правка \| К родителю #85 \| Наверх \| Cообщить модератору


	122. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от Прохожий (??), 27-Июл-23, 20:31
	> Реляционные базы и так плохо масштабируются. Зависит от архитектуры приложения вобще-то. Например, отдельные модули в отдельной схеме (базе данных) без сильных связей с другими схемами (базами данных) вполне себе отлично разносятся по разным хостам. Есть и другие способы разнесения нагрузки, типа репликации мастер-мастер, мастер-ведомый, и так далее. Да, это не "СУБД" типа "ключ-значение", но зато РСУБД и гораздо больше чего умеет из коробки. А так серебряной пули не бывает.
	Ответить \| Правка \| К родителю #57 \| Наверх \| Cообщить модератору


	91. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+1 +/–
	Сообщение от Аноним (91), 27-Июл-23, 05:50
	так прекратите писать sql-спагетти, и разгребите ваши запросы. у вас видимо текучка кадров большая :)
	Ответить \| Правка \| К родителю #27 \| Наверх \| Cообщить модератору


	94. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+3 +/–
	Сообщение от Аноним (94), 27-Июл-23, 06:56
	Чта?! Во первых в sql есть view. Во вторых with. Что покрывает все потребности в модульности.
	Ответить \| Правка \| К родителю #27 \| Наверх \| Cообщить модератору


	134. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от ptr (??), 28-Июл-23, 08:47
	VIEW, CTE и функции, включая табличные, решают проблему лишь частично. Мне радикально решить проблему модульности удалось лишь препроцессингом SQL кода средствами C препроцессора. Вот когда появились включаемые файлы и макросы - тогда действительно код стал модульным. К сожалению, инлайн код в запросе намного производительней, чем тот же код, вынесенный в функции. А у меня даже такие запросики возникают: https://github.com/dbeaver/dbeaver/issues/10680 (смотрите аттач в zip). При том, что до препроцессора, это вполне себе компактный запрос: SELECT ROUND(Q.Rez-UC_DISCOUNT,0)+CALC_JA_TOTAL FROM ...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	119. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от Аноним (117), 27-Июл-23, 17:24
	Модулей в SQL быть не может, однако от дублирования избавиться можно. 1) Можно повторяющийся SQL инклюдить из файла. 2) Можно написать класс билдера запросов для моделей, одноклассники которого смогут экспортировать миксины для построения запроса, а также использовать их для построения своих запросов. Очень грубо, можно передать список вещей, которые нужно добавить в те или иные части запроса, и что нужно потом сделать с результатом запроса. Например, можно добавить в группировку и в селект, а после исполнения развернуть group_concat в массивчик айдишек и т.д. В одном из проектов я такую вещь сделал и несмотря на некую навороченность кода, SQL существовал в единственном экземпляре. Запросы на экран и более были нормой, да.
	Ответить \| Правка \| К родителю #27 \| Наверх \| Cообщить модератору


	123. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от Прохожий (??), 27-Июл-23, 20:41
	> Модулей в SQL быть не может Я бы не был столь категоричным. View - вполне себе самостоятельный модуль. Есть и ещё, попроще, не так, чтобы модули, но вполне нормальный способ сократить дублирование кода. В Oracle использование функций в теле SQL-запроса подвезли с 19-й версии. Кроме того, есть with, как уже отметили выше.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	136. "Опубликован PRQL, компилируемый в SQL язык обработки данных"	+/–
	Сообщение от Аноним (117), 28-Июл-23, 15:35
	Фактически это макросы. Подсократить запросы получится, спору нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору