https://www.opennet.ru/openforum/vsluhforumID3/131077.html Доступен выпуск языка формирования запросов и преобразования данных PRQL 0.9 (Pipelined Relational Query Language), развиваемого в качестве более простой и функциональной замены SQL, упрощающей создание сложных аналитических запросов. Код на языке PRQL компилируется в SQL, что позволяет использовать его с любыми реляционными СУБД. Компилятор PRQL написан на языке Rust и распространяется под лицензией Apache 2.0...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59499<br> https://www.opennet.ru/openforum/vsluhforumID3/131077.html#151 Sat, 06 Jan 2024 03:02:50 GMT &gt; если кто-то решит мимо сервера приложений нагадить?<br><br>Давай такие ТУХЛЫЕ аргументы не приводить? А то я скажу, что у тебя нет защиты от "уборщица пришла с пылесосом и выдернула розетку сервера". Ты как-то мыслишь вообще не по-программистски.<br><br>&gt; Как обеспечивать непротиворечивость данных, если будет больше одного сервера приложений?<br><br>А в чём именно проблема-то?? Подробнее.<br><br>&gt; Чего, например?<br><br>Чего "чего"? ДВИЖОК сменить! Что непонятного?<br><br>&gt; Какие там сложности?<br><br>Все те же сложности, как и перенос чего-либо вообще на другой физический сервер - то с форматом дат напутали, то нашлись неконсистентные данные, то надо перенести блобы из файловой системы в новое место (а в старой базе пути). Я не просто про "бэкап-рестор", а аккуратный перенос данных, потому что незачем тащить на новый сервер все старые атавизмы. И конечно процедуры - обратная совместимость у них есть, но как всегда найдётся энтузазист, который захочет переписать короче (а ради чего тогда прогресс??). И вот уже у вас ДВЕ версии хранимок.<br> https://www.opennet.ru/openforum/vsluhforumID3/131077.html#150 Wed, 02 Aug 2023 21:21:30 GMT уже все давно придумано, называется CASE Tools, в частности для Data Modeling<br><br>и неважно сколько строк в таблицах, запрос к правильно спроектированной БД, будет оптимальным чаще всего только одним единственным способом (если не считать Views), вот его и пишешь независимо от того сколько строк<br><br>а подход "там будет строк немного, поэтому тут мы можем недопроектировать или на отъeбись сделать" это не ко мне с такими дискуссиями )))<br> https://www.opennet.ru/openforum/vsluhforumID3/131077.html#149 Wed, 02 Aug 2023 12:42:05 GMT Процедурки над сиквелом, кроме Оракла, везде плохо. В Слоне тоже. Использовать можно только строго для реализации констраинтов или простейших триггеров.<br> https://www.opennet.ru/openforum/vsluhforumID3/131077.html#148 Wed, 02 Aug 2023 12:40:22 GMT Как будет выполняться запрос никак с SQL вообще не связано.<br> https://www.opennet.ru/openforum/vsluhforumID3/131077.html#147 Wed, 02 Aug 2023 12:36:28 GMT Нет, проблема ORM-ов не в адекватности запросов -- в сиквеле пофиг как ты написал, гадалка всё равно сделает так, как нужно, главное, чтоб логически было верное выражение, а у ОРМов с этим более-менее. У ORM-ов просто много накладных расходов. А сейчас ещё и добавляет то, что вошли в моду ормы поверх ормов и поверх ормов. В той же java сейчас модно лепить всякую жуть над jpa.<br> https://www.opennet.ru/openforum/vsluhforumID3/131077.html#146 Wed, 02 Aug 2023 12:15:37 GMT Это изврат ради изврата. Сиквелу совершенно ни к чему быть модульным.<br> https://www.opennet.ru/openforum/vsluhforumID3/131077.html#145 Tue, 01 Aug 2023 22:01:03 GMT Речь не про "бесплатный Oracle", а про импортозамещение в связи с тем что Oracle теперь в РФ не продаётся.<br> https://www.opennet.ru/openforum/vsluhforumID3/131077.html#144 Tue, 01 Aug 2023 11:26:34 GMT например Vertica<br> https://www.opennet.ru/openforum/vsluhforumID3/131077.html#143 Tue, 01 Aug 2023 11:17:23 GMT &gt; почитай оригинальный коментарий, и что именно обсуждается <br>&gt; нет никакой сложности держать схему базы данных больше 24 таблиц в голове <br>&gt; (количества строк это вообще не касается), может поэтому тебе и тяжело <br>&gt; держать все голове потому что там постоянная каша из котлет и <br>&gt; мух?<br><br>человек пытается сказать, что чем объемнее таблицы, тем аккуратнее надо быть при написании запросов. и тем сложнее держать в умер все ньюансы. если у тебя 25 таблиц - это круто. я видел например базы данных MS Dynamics, в которой если не изменяет память их было больше 4х тысяч. да, бизнес сущностей.<br>тут проблема в чем - подход который у тебя - бессмысленнаю трата ресурсов мозга. а тот подход, который предлаете интрумент описаный в статье - он позволяет оперировать информацией с меньшими ментальными издержками.<br>