к сожалению, на практике оказывается, что иногда нужно указывать версии не только непосредственно используемой библиотеки, но и транзитивных зависимостей. Разработчики библиотек тоже увлекаются использованием ~ или ^, и потому в один прекрасный момент мир ломается в самых неожиданных местах.
я и не утверждаю, что схема ломается постоянно.
На одной итерации добавилось поле, на другой стало not null, на третьей потребовалось поменять логику взаимодействия этого поля с другими, на четвертой — материализовать значение/агрегат в другую таблицу.
Просто такие изменения потихоньку наслаиваются друг на друга и потом становится очевидно, что мы из существующего решения уже выросли и время немножко поменять нормализацию в отдельных кусочках итд.
Неприятность заключается в том, что при рефакторинге надо очень хорошо тестировать, а SQL штука сильно завязанная на данные и требует большое количество тестов, если хочется надёжности.
Думаю, следует заметить, что у разных ERP разные возможности и, соответственно, разные схемы хранения.
Также следует заметить, что всё не укладывающееся в стандартную схему как правило дописывается сбоку внедренцами, в той или иной степени костылями, за исключением случаев, когда это не реализуемо на данной платформе в принципе.
Увы, не всё можно загнать под общую готовую схему.
Иначе заказчик уже купил и внедрял бы готовое решение.
Иначе бы всё ПО уже давно бы написали.
Оракл и постгрес прекрасно справляется с сотнями джойнов, он для этого и предназначен.
Кем и как это проверено? Это сильно зависит от структуры таблиц, данных, статистики, индексов, объёма данных.
Вы не справляетесь.
Справляемся, достаточно хорошо справляемся. И оракловый оптимизатор, в среднем по больнице, справляется, но в любом деле есть нюансы, упомянутые выше.
мы не умеем в скл
Мой пойнт в том, что не существует единого SQL, который всегда одинаково хорошо работает на любой СУБД. В каждом движке есть грабли и тонкости, из-за которых часто приходится делать иначе, чем в другой СУБД. Запрос, который идеально работает в pgsql, может быть неэффективным в oracle или в принципе не реализуемым (привет, пагинация в oracle 11, боже, как я ржал, когда увидел правильное решение). И это нормально.
выбрасываем деньги на оракл
Не мы выбрасываем, это было требование заказчика — использовать оракл, потому что у него уже готовая инфраструктура, админы, итд.
но пользуем иерархическую бд 30-летней давности
??? не понял, откуда такой вывод.
P.S. а можно без ad hominem и апломба? раздражает же и убивает адекватную дискуссию.
А теперь новая вводная — требуется импортозамещение на Postgresql. =)
Глупости, можно конечно.
А теперь добавляем корректировки старых требований, вносим новые требования и получаем регулярную необходимость пересматривать и менять этот код. И приходим к проблеме экспоненциального роста инвариантов, которые необходимо протестировать, с ростом сложности запроса, о которой я упоминал выше.
Хранимые процедуры оказываются более удачным решением, т.к. их легко разбивать на блоки, тестировать, читать и писать.
Если слова «десяток джойнов» смущают ораклиста то его надо заменить, этот негодный
Десяток джойнов куда больше смущают оракловый оптимизатор, у которого случается горе от ума. И помимо ораклиста есть ещё другие члены команды, которые пишут и читают SQL, так что не поможет. Уж лучше аккуратненько писать ХП и потом их бить на кусочки, да оптимизировать помаленьку.
Это не недоработка архитекта. Это жизнь такая — требования к системе меняются по мере её работы в продакшене, по мере уменьшения бардака на предприятии заказчика в уже автоматизированных областях и внесения под автоматизированный контроль нового бардака.
Архитект не всевидящее око — он не может предусмотреть всего.
Кстати, это не очень связано с невозможностью работать с большими данными. Размер данных зависит от возможностей файловой системы.
Что есть большие данные? Я раньше слышал определение — они не влазят в ни в один из доступных на массовом рынке серверов. И там далеко не только в файловой системе возникают проблемы.
Не было бы нормальных людей, шарящих в СУБД, мы бы за хранимые процедуры даже не стали бы браться. Писали бы всё на аппсервере. Другое дело, что с большинство ораклом раньше не работали.
Есть у нас хороший ораклист. Целый один. Но скорость развития проекта просто не та, при которой он бы успевал что-то сделать.
И ещё живых ораклистов за вменяемые деньги найти — это огромная проблема.
И нет, нельзя написать запрос так, чтобы он был одновременно читабельным, поддерживаемым и при этом всегда делал что надо, в условиях, когда нужно регулярно менять что-то в схеме, добавлять/убирать возврат каких-то полей, когда поля скачут из not null в nullable итд.
Обычные запросы в таких условиях очень быстро превращается в убористую кашу с десятком джойнов и вложенных запросов, которая завешивает и оптимизатор, и ораклиста.
Тупые хранимые процедуры с последовательной логикой работают просто чудесно на этом фоне. И никаких вопросов с транзакционностью.
в MySQL и MariaDB есть хранимые процедуры.
Кривые, косые, но есть. Тоже не от хорошей жизни они там появились =)
Я имел ввиду, что SQLite нельзя назвать "взрослой" клиент-серверной СУБД, которая умеет работать с большим объёмом данных и большим числом одновременных клиентов.
На нынешнем проекте у меня оракл и хранимые процедуры, потому что нельзя просто так и взять и правильно написать запрос, который сделает то, что надо и как надо. Если писать то, что нам надо чистыми запросами, оптимизатор встаёт в позу и начинает выдавать совершенно наркоманские планы. И статистика тут ни при чём. А много простых запросов — это лишние раундтрипы между сервером приложений и БД, лишние заморочки с транзакционностью и код в аппсервере начинает выглядеть ужасно.
SQL побеждает, потому что немалое значение имеет также скорость реализации.
Отчасти потому взлетели далеко не лучшие языки программирования вроде PHP и JS — на них просто накидать поделку, которая будет хоть как-то работать.
SQL-запрос, делающий нужное, в среднем легко накидать. Непросто его поддерживать, изменять и сделать эффективным.
И в спарке побеждает SQL вовсе не потому, что нельзя оптимизировать запросы лучше автомата, просто так намного быстрее написать хоть какой-то работающий код. А руками оптимизировать, если автоматика с ума сходить начинает, можно и потом, когда деньги будут.
Так что да, автоматические планировщики и оптимизаторы лучше. Но не потому что они работают быстрее, чем написанный и отлаженный вручную код, а потому что они сильно ускоряют начальную разработку.
Потом пришли разработчики и потребовали хранимых процедур и писали по сути императивный код, чтобы БД периодически не выдавала "Ну у вас и запросы" и не зависала наглухо.
Потом пришёл веб, и юзеров стало так много, что один сервер БД стал загибаться и логика поехала в приложение, где разработчики по сути закатывали солнце вручную.
Потом пришли разработчики и потребовали ORM, потому что SQL — это слишком сложно и продолжили закатывать солнце вручную на толстых аппликейшн серверах, используя БД просто как тупую хранилку данных.
А потом дырявая абстракция cost based оптимизатора начала протекать и через ORM.
А потом...
SQL не очень хорош, и я бы его ставил в ряд с каким-нибудь JS по причинам появления багов, но лучше пока не сделали. Так и живём.
Конечно, посчитать все андроид-девайсы — будет самой популярной :-)
Я скорее к тому, что в SQLite нет как таковой необходимости иметь уровни изоляции — это по дизайну встраиваемая БД для локального применения в рамках одного процесса.
Там нет и хранимых процедур, и многопользовательского доступа по примерно тем же причинам. Это просто библиотека (не СУБД) с SQL-like синтаксисом. Очень полезная в хозяйстве, надо сказать. Отдельно хочется похвалить автора за его любовь к автотестам.
Сложность отладки и тестирования. Каждое условие в запросе — это по сути if, который создает минимум две ветки, которые нужно протестировать.
Т.е. даже на честную отладку самого обычного запроса нужно проверить минимум 2^(n+k) инвариантов, где n — это количество сравнений полей, а k — это количество входных параметров запроса.
Поведение с NULL. Мне конечно все говорят, что это норма, такова жизнь и вотэтовсё, но чёрт подери, это ещё сильнее ухудшает (1), делая мне 3^(n+k), и при этом всё начинает очень весело стрелять в рантайме, вываливая этот NULL, то туда, то сюда, когда кто-то внезапно сменит inner join на left join, просто потому что так стало надо.
Протекающие абстракции слоя хранения и оптимизатора запросов.
Знание SQL не освобождает от ответственности написания эффективных запросов. В каждом движке есть свои заморочки, как данные эффективно запрашивать и для того, чтобы работать действительно грамотно, надо точить запрос под каждый движок отдельно.
На рынке работодателю не слишком интересно знаешь ты SQL или нет, куда важнее, работал ли ты с конкретной СУБД. Неофиты в каком-то движке имеют привычку писать совершенно по-другому и поливать тоннами ругани СУБД, когда она ведёт себя неожиданным образом, и это будет продолжаться, пока человек не разберётся, как СУБД данные хранит и как работают планировщик/оптимизатор/исполнитель запроса. Увы, не существует единого стандарта SQL, который будет абсолютно одинаково эффективно работать на всех рантаймах. И никогда не будет существовать, потому что есть требования обратной совместимости. // никогда не прощу ораклу, что у них NULL и пустая строка — это одно и тоже.
В случае, когда я делаю закат солнца вручную (пишу джойны, аггрегации, подзапросы прямо в коде приложения, делаю руками выборку, вотэтовсё), я могу это легко контролировать — сделать декомпозицию на несколько простых, часто чистых, функций, каждую из которых обложить тестами и комбинировать уже готовые абстрагированные блоки, контролируя таким образом сложность, как алгоритмическую, так и тестирования.
// опустим сложный вопрос эффективности работы со слоем хранения.
В случае с SQL запросы быстро разрастаются сами собой из-за кажущейся простоты и необходимости быстро напилить фичу. Они выглядят компактно и создаётся иллюзия, что ты точно знаешь, как он работает и что вернёт. На самом деле это не так.
Наверное, стоит разделить слой хранения данных и слой DML.
В Oracle, строго говоря, данные хранятся не в плоской таблице, а в дереве, но это не делает его NoSQL СУБД. Слой хранения может быть разным — может быть на одном узле как в MySQL, может быть на распределенном block storage, как в Aurora, может быть размазан по многим узлам, как в CockroachDB или Spanner. Значение имеет всё же интерфейс взаимодействия.
И реляционная модель ни слова не говорит про хранение — это логическая модель данных, не физическая, которая просто утверждает, мы можем оперировать с данными как с множествами кортежей, и можем пользоваться булевой алгеброй для задания предиката, применение которого вернет множество нужных элементов.
Запросы проще и выразительней чем SQL на порядки
модифицированный XQuery
а можно пример, пожалуйста? Интересно стало.
Просто всегда думал, что XML — это не тот язык, который могут писать живые люди.
не совсем так. Каноничный пример иерархической БД — это файловая система.
В ней можно легко создать папку для пользователя и в неё положить все его просмотренные сайты.
Документные СУБД всё же отдельный класс с ограничением на размер документа. т.е. нельзя будет всю историю одного человека запихать в один документ.
Прошу меня извинить, но уровни изоляции — это то, что выбито гвоздями в SQL-92. Это стандарт.
Его в том или ином виде полностью поддерживают почти все движки. Да, немножко со своими странностями, но тем не менее. Если СУБД не поддерживает уровни изоляции и транзакции, то это какое-то недоразумение, а не полноценная СУБД. SQLite в расчет не берем — это встраиваемая записная книжка с SQL-синтаксисом.
Вот здесь я склонен немного не согласиться, потому что
или часто правильно написанный +0 при джойне в Firebird,
или грамотно подсунутый хинт индекса в MySQL,
или грамотно построенный индекс для MS SQL,
или грамотно переписанный запрос с использованием фишечек (оконные функции, CTE) в PostgreSQL,
или переписывание запроса на (о ужас :-) ) хранимую процедуру PL/SQL с простой линейной логикой (привет, Oracle),
способны исправить любую глупость оптимизатора.
И это всё тоже остаётся в рамках SQL (за исключениме хранимых процедур разве что).
Проблема в другом — эти решения применимы только для конкретного движка СУБД, т.е. имеем примерно такую же фигню как с NoSQL — для эффективной работы с каждым хранилищем данных приходится как-то по-особенному приседать — писать запросы, продумывать структуру таблиц, что развеивает миф о возможности существования всемогущего, одинакового для всех БД, языке.
Сейчас веб-версию слака сильно переписали в лучшую сторону. Десктопная версия пока что ужас-ужас. =(
к сожалению, на практике оказывается, что иногда нужно указывать версии не только непосредственно используемой библиотеки, но и транзитивных зависимостей. Разработчики библиотек тоже увлекаются использованием ~ или ^, и потому в один прекрасный момент мир ломается в самых неожиданных местах.
я и не утверждаю, что схема ломается постоянно.
На одной итерации добавилось поле, на другой стало not null, на третьей потребовалось поменять логику взаимодействия этого поля с другими, на четвертой — материализовать значение/агрегат в другую таблицу.
Просто такие изменения потихоньку наслаиваются друг на друга и потом становится очевидно, что мы из существующего решения уже выросли и время немножко поменять нормализацию в отдельных кусочках итд.
Неприятность заключается в том, что при рефакторинге надо очень хорошо тестировать, а SQL штука сильно завязанная на данные и требует большое количество тестов, если хочется надёжности.
Думаю, следует заметить, что у разных ERP разные возможности и, соответственно, разные схемы хранения.
Также следует заметить, что всё не укладывающееся в стандартную схему как правило дописывается сбоку внедренцами, в той или иной степени костылями, за исключением случаев, когда это не реализуемо на данной платформе в принципе.
Увы, не всё можно загнать под общую готовую схему.
Иначе заказчик уже купил и внедрял бы готовое решение.
Иначе бы всё ПО уже давно бы написали.
Кем и как это проверено? Это сильно зависит от структуры таблиц, данных, статистики, индексов, объёма данных.
Справляемся, достаточно хорошо справляемся. И оракловый оптимизатор, в среднем по больнице, справляется, но в любом деле есть нюансы, упомянутые выше.
Мой пойнт в том, что не существует единого SQL, который всегда одинаково хорошо работает на любой СУБД. В каждом движке есть грабли и тонкости, из-за которых часто приходится делать иначе, чем в другой СУБД. Запрос, который идеально работает в pgsql, может быть неэффективным в oracle или в принципе не реализуемым (привет, пагинация в oracle 11, боже, как я ржал, когда увидел правильное решение). И это нормально.
Не мы выбрасываем, это было требование заказчика — использовать оракл, потому что у него уже готовая инфраструктура, админы, итд.
??? не понял, откуда такой вывод.
P.S. а можно без ad hominem и апломба? раздражает же и убивает адекватную дискуссию.
А теперь новая вводная — требуется импортозамещение на Postgresql. =)
А теперь добавляем корректировки старых требований, вносим новые требования и получаем регулярную необходимость пересматривать и менять этот код. И приходим к проблеме экспоненциального роста инвариантов, которые необходимо протестировать, с ростом сложности запроса, о которой я упоминал выше.
Хранимые процедуры оказываются более удачным решением, т.к. их легко разбивать на блоки, тестировать, читать и писать.
Десяток джойнов куда больше смущают оракловый оптимизатор, у которого случается горе от ума. И помимо ораклиста есть ещё другие члены команды, которые пишут и читают SQL, так что не поможет. Уж лучше аккуратненько писать ХП и потом их бить на кусочки, да оптимизировать помаленьку.
Это не недоработка архитекта. Это жизнь такая — требования к системе меняются по мере её работы в продакшене, по мере уменьшения бардака на предприятии заказчика в уже автоматизированных областях и внесения под автоматизированный контроль нового бардака.
Архитект не всевидящее око — он не может предусмотреть всего.
По первому абзацу целиком и полностью согласен.
Что есть большие данные? Я раньше слышал определение — они не влазят в ни в один из доступных на массовом рынке серверов. И там далеко не только в файловой системе возникают проблемы.
Не было бы нормальных людей, шарящих в СУБД, мы бы за хранимые процедуры даже не стали бы браться. Писали бы всё на аппсервере. Другое дело, что с большинство ораклом раньше не работали.
Есть у нас хороший ораклист. Целый один. Но скорость развития проекта просто не та, при которой он бы успевал что-то сделать.
И ещё живых ораклистов за вменяемые деньги найти — это огромная проблема.
И нет, нельзя написать запрос так, чтобы он был одновременно читабельным, поддерживаемым и при этом всегда делал что надо, в условиях, когда нужно регулярно менять что-то в схеме, добавлять/убирать возврат каких-то полей, когда поля скачут из not null в nullable итд.
Обычные запросы в таких условиях очень быстро превращается в убористую кашу с десятком джойнов и вложенных запросов, которая завешивает и оптимизатор, и ораклиста.
Тупые хранимые процедуры с последовательной логикой работают просто чудесно на этом фоне. И никаких вопросов с транзакционностью.
в MySQL и MariaDB есть хранимые процедуры.
Кривые, косые, но есть. Тоже не от хорошей жизни они там появились =)
Я имел ввиду, что SQLite нельзя назвать "взрослой" клиент-серверной СУБД, которая умеет работать с большим объёмом данных и большим числом одновременных клиентов.
На нынешнем проекте у меня оракл и хранимые процедуры, потому что нельзя просто так и взять и правильно написать запрос, который сделает то, что надо и как надо. Если писать то, что нам надо чистыми запросами, оптимизатор встаёт в позу и начинает выдавать совершенно наркоманские планы. И статистика тут ни при чём. А много простых запросов — это лишние раундтрипы между сервером приложений и БД, лишние заморочки с транзакционностью и код в аппсервере начинает выглядеть ужасно.
SQL побеждает, потому что немалое значение имеет также скорость реализации.
Отчасти потому взлетели далеко не лучшие языки программирования вроде PHP и JS — на них просто накидать поделку, которая будет хоть как-то работать.
SQL-запрос, делающий нужное, в среднем легко накидать. Непросто его поддерживать, изменять и сделать эффективным.
И в спарке побеждает SQL вовсе не потому, что нельзя оптимизировать запросы лучше автомата, просто так намного быстрее написать хоть какой-то работающий код. А руками оптимизировать, если автоматика с ума сходить начинает, можно и потом, когда деньги будут.
Так что да, автоматические планировщики и оптимизаторы лучше. Но не потому что они работают быстрее, чем написанный и отлаженный вручную код, а потому что они сильно ускоряют начальную разработку.
Потом пришли разработчики и потребовали хранимых процедур и писали по сути императивный код, чтобы БД периодически не выдавала "Ну у вас и запросы" и не зависала наглухо.
Потом пришёл веб, и юзеров стало так много, что один сервер БД стал загибаться и логика поехала в приложение, где разработчики по сути закатывали солнце вручную.
Потом пришли разработчики и потребовали ORM, потому что SQL — это слишком сложно и продолжили закатывать солнце вручную на толстых аппликейшн серверах, используя БД просто как тупую хранилку данных.
А потом дырявая абстракция cost based оптимизатора начала протекать и через ORM.
А потом...
SQL не очень хорош, и я бы его ставил в ряд с каким-нибудь JS по причинам появления багов, но лучше пока не сделали. Так и живём.
Конечно, посчитать все андроид-девайсы — будет самой популярной :-)
Я скорее к тому, что в SQLite нет как таковой необходимости иметь уровни изоляции — это по дизайну встраиваемая БД для локального применения в рамках одного процесса.
Там нет и хранимых процедур, и многопользовательского доступа по примерно тем же причинам. Это просто библиотека (не СУБД) с SQL-like синтаксисом. Очень полезная в хозяйстве, надо сказать. Отдельно хочется похвалить автора за его любовь к автотестам.
У меня к SQL есть пара претензий.
Сложность отладки и тестирования. Каждое условие в запросе — это по сути if, который создает минимум две ветки, которые нужно протестировать.
Т.е. даже на честную отладку самого обычного запроса нужно проверить минимум 2^(n+k) инвариантов, где n — это количество сравнений полей, а k — это количество входных параметров запроса.
Поведение с NULL. Мне конечно все говорят, что это норма, такова жизнь и вотэтовсё, но чёрт подери, это ещё сильнее ухудшает (1), делая мне 3^(n+k), и при этом всё начинает очень весело стрелять в рантайме, вываливая этот NULL, то туда, то сюда, когда кто-то внезапно сменит
inner joinнаleft join, просто потому что так стало надо.Знание SQL не освобождает от ответственности написания эффективных запросов. В каждом движке есть свои заморочки, как данные эффективно запрашивать и для того, чтобы работать действительно грамотно, надо точить запрос под каждый движок отдельно.
На рынке работодателю не слишком интересно знаешь ты SQL или нет, куда важнее, работал ли ты с конкретной СУБД. Неофиты в каком-то движке имеют привычку писать совершенно по-другому и поливать тоннами ругани СУБД, когда она ведёт себя неожиданным образом, и это будет продолжаться, пока человек не разберётся, как СУБД данные хранит и как работают планировщик/оптимизатор/исполнитель запроса. Увы, не существует единого стандарта SQL, который будет абсолютно одинаково эффективно работать на всех рантаймах. И никогда не будет существовать, потому что есть требования обратной совместимости. // никогда не прощу ораклу, что у них NULL и пустая строка — это одно и тоже.
В случае, когда я делаю закат солнца вручную (пишу джойны, аггрегации, подзапросы прямо в коде приложения, делаю руками выборку, вотэтовсё), я могу это легко контролировать — сделать декомпозицию на несколько простых, часто чистых, функций, каждую из которых обложить тестами и комбинировать уже готовые абстрагированные блоки, контролируя таким образом сложность, как алгоритмическую, так и тестирования.
// опустим сложный вопрос эффективности работы со слоем хранения.
В случае с SQL запросы быстро разрастаются сами собой из-за кажущейся простоты и необходимости быстро напилить фичу. Они выглядят компактно и создаётся иллюзия, что ты точно знаешь, как он работает и что вернёт. На самом деле это не так.
Наверное, стоит разделить слой хранения данных и слой DML.
В Oracle, строго говоря, данные хранятся не в плоской таблице, а в дереве, но это не делает его NoSQL СУБД. Слой хранения может быть разным — может быть на одном узле как в MySQL, может быть на распределенном block storage, как в Aurora, может быть размазан по многим узлам, как в CockroachDB или Spanner. Значение имеет всё же интерфейс взаимодействия.
И реляционная модель ни слова не говорит про хранение — это логическая модель данных, не физическая, которая просто утверждает, мы можем оперировать с данными как с множествами кортежей, и можем пользоваться булевой алгеброй для задания предиката, применение которого вернет множество нужных элементов.
а можно пример, пожалуйста? Интересно стало.
Просто всегда думал, что XML — это не тот язык, который могут писать живые люди.
Для документных СУБД это неверно, можно навесить любые индексы, если это требуется.
не совсем так. Каноничный пример иерархической БД — это файловая система.
В ней можно легко создать папку для пользователя и в неё положить все его просмотренные сайты.
Документные СУБД всё же отдельный класс с ограничением на размер документа. т.е. нельзя будет всю историю одного человека запихать в один документ.
Прошу меня извинить, но уровни изоляции — это то, что выбито гвоздями в SQL-92. Это стандарт.
Его в том или ином виде полностью поддерживают почти все движки. Да, немножко со своими странностями, но тем не менее. Если СУБД не поддерживает уровни изоляции и транзакции, то это какое-то недоразумение, а не полноценная СУБД. SQLite в расчет не берем — это встраиваемая записная книжка с SQL-синтаксисом.
Вот здесь я склонен немного не согласиться, потому что
или часто правильно написанный +0 при джойне в Firebird,
или грамотно подсунутый хинт индекса в MySQL,
или грамотно построенный индекс для MS SQL,
или грамотно переписанный запрос с использованием фишечек (оконные функции, CTE) в PostgreSQL,
или переписывание запроса на (о ужас :-) ) хранимую процедуру PL/SQL с простой линейной логикой (привет, Oracle),
способны исправить любую глупость оптимизатора.
И это всё тоже остаётся в рамках SQL (за исключениме хранимых процедур разве что).
Проблема в другом — эти решения применимы только для конкретного движка СУБД, т.е. имеем примерно такую же фигню как с NoSQL — для эффективной работы с каждым хранилищем данных приходится как-то по-особенному приседать — писать запросы, продумывать структуру таблиц, что развеивает миф о возможности существования всемогущего, одинакового для всех БД, языке.
вот только putty — это один несчастный бинарник, а это приличного размера ворох файлов, которому подавай на машине nodejs, и возможно ещё компилятор.
В общем я клоню к тому, что в бородатые года написал Спольски про .Net http://russian.joelonsoftware.com/Articles/PleaseSirMayIHaveaLinker.html