Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 13   вперед  Ctrl
 Re: Причины ненависти к языку SQL?  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3810
Щиче
Чем сложнее запрос, тем больше ORM требует внимания к себе

Чем сложнее запрос, тем он сам должен требовать внимания к себе.
Не стоит ждать дня, когда он перевалит на третью страницу, чтобы задуматься над тем, а как переделать систему, чтобы не было сложных запросов.
6 ноя 18, 08:12    [21724820]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Щиче
Member

Откуда: Чебоксары
Сообщений: 768
Дмитрий Мух
Щиче
Чем сложнее запрос, тем больше ORM требует внимания к себе

Чем сложнее запрос, тем он сам должен требовать внимания к себе.
Не стоит ждать дня, когда он перевалит на третью страницу, чтобы задуматься над тем, а как переделать систему, чтобы не было сложных запросов.


Хорошо. У вас такой запрос в силу сложной бизнес логики. Допустим, ценой глубоких раздумий вы его сократили до 2 страниц. Но больше уже не получается ибо задача. И никакие манипуляции со структурой не годятся, ибо тогда вы будете продумывать ещё стопитцот других задач сидящих на ней.
Декомпозиция - отличный вариант. Но, серия запросов куда как менее производительна нежели один большой. Использовать хранимки, где это можно сделать, используя один запрос извне, по нынешним взглядам низзя!
Вот и думайте, вы используете один запрос сложной структуры, расходуя минимум ресурсов, или вынимаете душу из СУБД.
6 ноя 18, 08:23    [21724826]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3810
Щиче
Дмитрий Мух
пропущено...

Чем сложнее запрос, тем он сам должен требовать внимания к себе.
Не стоит ждать дня, когда он перевалит на третью страницу, чтобы задуматься над тем, а как переделать систему, чтобы не было сложных запросов.


Хорошо. У вас такой запрос в силу сложной бизнес логики. Допустим, ценой глубоких раздумий вы его сократили до 2 страниц. Но больше уже не получается ибо задача. И никакие манипуляции со структурой не годятся, ибо тогда вы будете продумывать ещё стопитцот других задач сидящих на ней.
Декомпозиция - отличный вариант. Но, серия запросов куда как менее производительна нежели один большой. Использовать хранимки, где это можно сделать, используя один запрос извне, по нынешним взглядам низзя!
Вот и думайте, вы используете один запрос сложной структуры, расходуя минимум ресурсов, или вынимаете душу из СУБД.

Что конкретно за запрос? Кому он нужен?
Как с этими данными дальше работают? Расчитать их при записи есть возможность? Навернякак есть
6 ноя 18, 08:26    [21724827]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3810
Зачастую ведь оно как бывает: есть бизнес транзакция в результате выполнения которой данные разлетаются по N таблицам.
А потом, внезапно, собираются из этих же N таблиц + справочники в сложный запрос "в силу сложной бизнес логики".

Так вот если на последнее взглянуть пристальнее, то легко прийти к очевидному выводу
6 ноя 18, 08:31    [21724831]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Щиче
Member

Откуда: Чебоксары
Сообщений: 768
Дмитрий Мух
Что конкретно за запрос? Кому он нужен?
Как с этими данными дальше работают? Расчитать их при записи есть возможность? Навернякак есть


Наверняка нет :) Запрос собирающий данные из записей товарных остатков.
Вмешиваться в запись низзя. Рассчитать при записи низзя, потому что они сыпятся мощным потоком. Реагировать на каждую запись - обратить производительность в ноль. Триггеры, напомню, использовать западло, да и не всегда помогает.
По планировщику в обед или ночью выполняется тот самый сложный запрос, что и рассчитывает. Но даже ночью надо знать меру, потому что магазин работает, а в обед покупатели все равно есть!

В каждой большой системе что-то подобное наличествует.
6 ноя 18, 08:55    [21724849]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3810
Щиче
Дмитрий Мух
Что конкретно за запрос? Кому он нужен?
Как с этими данными дальше работают? Расчитать их при записи есть возможность? Навернякак есть


Запрос собирающий данные из записей товарных остатков.

Значит можно. Через регистр движения товаров. 15 лет назад для НК "ЮКОС" такое делали.
6 ноя 18, 08:58    [21724851]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Щиче
Member

Откуда: Чебоксары
Сообщений: 768
Дмитрий Мух
Зачастую ведь оно как бывает: есть бизнес транзакция в результате выполнения которой данные разлетаются по N таблицам.
А потом, внезапно, собираются из этих же N таблиц + справочники в сложный запрос "в силу сложной бизнес логики".

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


Да, что написание/поддержка сложного запроса обойдется куда дешевле, чем тот самый очевидный вывод. Трудоемкость просто много меньше :) Как для программиста, так и для СУБД.
6 ноя 18, 08:59    [21724852]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3810
Щиче
Дмитрий Мух
Зачастую ведь оно как бывает: есть бизнес транзакция в результате выполнения которой данные разлетаются по N таблицам.
А потом, внезапно, собираются из этих же N таблиц + справочники в сложный запрос "в силу сложной бизнес логики".

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


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

До поры до времени
6 ноя 18, 09:05    [21724855]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
hVostt

Суть в том, что сами разработчики ORM-ов должны знать СУБД отлично, очень многие разработчики пришли в ORM из разработки СУБД-first, потому что устали заниматься обезьяним трудом.

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

ORM полезен в меру. А то, с чем встречался я как админ, было откровенное тормознутое говно. Я могу объяснить это только тем, что те програмёры не знали СУБД и не желали знать. И ORM это провоцирует, создаёт иллюзию, что можно обойтись без.
6 ноя 18, 14:05    [21725234]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Addx
Member

Откуда:
Сообщений: 957
stenford
Addx
Помню статью на Хабре про крутой проект на микросервисах.
И понимаю, что на SQL это 10 строчек кода.
Просто нужно понимать реляционные базы чуть лучше, чем знать простые join'ы.
И не уповать, что ORM - это панацея для всех проблем.

молодой человек, вы там пример прочитали. Микросервисы это следующая стадия развития софта. Одной из предыдущих стадий был именно что переход на ОРМ, он уже давно завершен. А что-б вам стало еще страшнее, в микросервисах нет ни внешних ключей, ни транзакций (между микросервисами), и даже джойны между ними не сделать. И представляете, все работает


О, еще один адепт. Прямо у него эволюция идет.
Решил поразить всех откровениями, никто же тут не знает что такое ORM и микросервисы.
Вы хотя бы книжку почитайте какую-нибудь, что такое микросервисы и с чем их едят.
Не будете нести бред (давно такого не читал) насчет транзакций, ключей и джоинов (которые не связаны с микросервисной архитектурой от слова никак).
6 ноя 18, 14:17    [21725253]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Addx
Member

Откуда:
Сообщений: 957
Дмитрий Мух
Зачастую ведь оно как бывает: есть бизнес транзакция в результате выполнения которой данные разлетаются по N таблицам.
А потом, внезапно, собираются из этих же N таблиц + справочники в сложный запрос "в силу сложной бизнес логики".

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


А потом (внезапно) оказывается, что нет. И данные можно рассчитывать в момент записи, и реестров понастроить.
Вот только при каждом изменении их перестраивать надо, а это (внезапно) процесс небыстрый.
И данные нужны чуть сложнее, чем в разрезе одного реестра - операция/остаток.
Впрочем, тут очень сильно зависит от приложения и архитектуры.
Кроме того, всепеределать! не всегда возможно, а хп неплохой уровень абстракции.
Впрочем, я вовсе не принципиальный сторонник бизнес-логики в хп, во многих случаях легко обойтись без них.
6 ноя 18, 14:40    [21725295]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Дмитрий Мух
Озверин
пропущено...


Причем тут хранимки? Я ж не про CRUD логику. Я, допустим, про агреггированную выборку. Или про параметризированную выборку со сложными джоинами.

Спрашиваю про хранимки, потому что пытаюсь понять, о чём речь.

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

Но это уже вопрос проектирования, а не ORM vs SQL.

И то, что Вы назвали CRUD логикой у вас где, в хранимках?


Совершенно не сравнимая сложность между: "построить один запрос быстро и на коленке проверить результат" и "построить приложение так, чтобы агрегировало что нужно, денормализовало и так далее". Впрочем, кроме сложности, несравнимые затраты денежные и временные.

CRUD логика - это базис, заложенные в соврвеменные ORM системы. Причем тут хранимки? Я говорил о том, что если от софта требуется примитивный CRUD, то я прикручу springjpa и за 15 минут слабаю на коленке готовый прототип без всяких SQL запросов, но если же логика потребуется сложнее, то я сначала накидаю SQL запросы к системе нативные, если они дадут результат - буду думать, куда дальше развивать систему.
6 ноя 18, 16:32    [21725495]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
казинак
Member

Откуда:
Сообщений: 1273
ORM - это просто посредник между UI и DB
ОРМ просто генерирует SQL из операторов жабы, сисярпа и т.д.
ну а посредники - это паразиты...

Просто, некоторые хвосты и мухи настолько ограничены, что не в состоянии освоить sql...
а понимание, как работает оптимизатор - ваще не для них
6 ноя 18, 17:42    [21725633]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
Addx
Дмитрий Мух
Зачастую ведь оно как бывает: есть бизнес транзакция в результате выполнения которой данные разлетаются по N таблицам.
А потом, внезапно, собираются из этих же N таблиц + справочники в сложный запрос "в силу сложной бизнес логики".

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


А потом (внезапно) оказывается, что нет. И данные можно рассчитывать в момент записи, и реестров понастроить.
Вот только при каждом изменении их перестраивать надо, а это (внезапно) процесс небыстрый.
И данные нужны чуть сложнее, чем в разрезе одного реестра - операция/остаток.
Впрочем, тут очень сильно зависит от приложения и архитектуры.
Кроме того, всепеределать! не всегда возможно, а хп неплохой уровень абстракции.
Впрочем, я вовсе не принципиальный сторонник бизнес-логики в хп, во многих случаях легко обойтись без них.

Откуда внезапно-то? Думаете у нас это в далёком 2003-м году внезапно случилось?

Нет, запросы разрослись, их стало трудно поддерживать, выполнялись они достаточно долго, оптимизировать стало дальше некуда.
Мы на это дело посмотрели и не внезапно, а через серию обсуждений, приняли решение переделать.
Переделали, оттестировали (в том числе и изменения с перестраиванием), внедрили в эксплуатацию на паре серверов.

Когда убедились, что всё работает, то раскатали на остальные 90+.
Начали собирать положительную обратную связь о том, как теперь всё быстро работает.
6 ноя 18, 18:36    [21725702]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
Озверин
Дмитрий Мух
пропущено...

Спрашиваю про хранимки, потому что пытаюсь понять, о чём речь.

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

Но это уже вопрос проектирования, а не ORM vs SQL.

И то, что Вы назвали CRUD логикой у вас где, в хранимках?


Совершенно не сравнимая сложность между: "построить один запрос быстро и на коленке проверить результат" и "построить приложение так, чтобы агрегировало что нужно, денормализовало и так далее". Впрочем, кроме сложности, несравнимые затраты денежные и временные.

По моему опыту с ростом приложения и объемов данных затраты начинают быть сравнимыми.
Вернее писать и сопровождать сложные запросы становиться дороже и по времени и по деньгам.
6 ноя 18, 18:38    [21725705]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
Озверин
если же логика потребуется сложнее, то я сначала накидаю SQL запросы к системе нативные, если они дадут результат - буду думать, куда дальше развивать систему

К примеру логика потребуется сложнее, но запросы при этом простые, то в какую сторону пойдёте?
6 ноя 18, 18:40    [21725710]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Addx
Member

Откуда:
Сообщений: 957
skyANA

Откуда внезапно-то? Думаете у нас это в далёком 2003-м году внезапно случилось?

Нет, запросы разрослись, их стало трудно поддерживать, выполнялись они достаточно долго, оптимизировать стало дальше некуда.
Мы на это дело посмотрели и не внезапно, а через серию обсуждений, приняли решение переделать.
Переделали, оттестировали (в том числе и изменения с перестраиванием), внедрили в эксплуатацию на паре серверов.

Когда убедились, что всё работает, то раскатали на остальные 90+.
Начали собирать положительную обратную связь о том, как теперь всё быстро работает.


Внезапно = неожиданно для разработчика.
Который думал, что новая технология - это серебряная пуля.
Я рад, что у Вас все получилось. Но это ничего не меняет.
Есть очень разный софт и очень разные задачи.
Можно сделать так
- О появилась новая (ха-ха, некоторые тут про микросервисы в 2018 году узнали) технология, все переводим на нее. Ой, не выходит каменный цветок, плохая технология, плохая.
А можно как одни ребята, которые внедряли какой-то проект (было видео на ютубе, но конечно ссылку не найду)
- Рассморели разные архитектуры - микросервисы, монолит, разные типы хранилищ и поняли, что в этом проекте микросервисы не годятся.
Я бы человека, который сказал бы мне, что микросервисы хороши для любой задачи, на работу бы не взял.
6 ноя 18, 18:52    [21725732]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
skyANA
Addx
пропущено...


А потом (внезапно) оказывается, что нет. И данные можно рассчитывать в момент записи, и реестров понастроить.
Вот только при каждом изменении их перестраивать надо, а это (внезапно) процесс небыстрый.
И данные нужны чуть сложнее, чем в разрезе одного реестра - операция/остаток.
Впрочем, тут очень сильно зависит от приложения и архитектуры.
Кроме того, всепеределать! не всегда возможно, а хп неплохой уровень абстракции.
Впрочем, я вовсе не принципиальный сторонник бизнес-логики в хп, во многих случаях легко обойтись без них.

Откуда внезапно-то? Думаете у нас это в далёком 2003-м году внезапно случилось?

Нет, запросы разрослись, их стало трудно поддерживать, выполнялись они достаточно долго, оптимизировать стало дальше некуда.
Мы на это дело посмотрели и не внезапно, а через серию обсуждений, приняли решение переделать.
Переделали, оттестировали (в том числе и изменения с перестраиванием), внедрили в эксплуатацию на паре серверов.

Когда убедились, что всё работает, то раскатали на остальные 90+.
Начали собирать положительную обратную связь о том, как теперь всё быстро работает.
а можете в двух словах рассказать что была за задача, какие объемы данных, требования по производительности и т.д.?
6 ноя 18, 19:22    [21725774]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Lessyp
Member

Откуда:
Сообщений: 140
Addx
Я бы человека, который сказал бы мне, что микросервисы хороши для любой задачи, на работу бы не взял.

а откуда вы извлекли, что микросервисы в каждом проекте необходимы? Они для больших и сложных современных систем расчитаны, заточенных под маштабирование. Учетную систему траспортного цеха можно и на хранимках слабать
7 ноя 18, 05:30    [21726037]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
Addx
skyANA
Откуда внезапно-то? Думаете у нас это в далёком 2003-м году внезапно случилось?

Нет, запросы разрослись, их стало трудно поддерживать, выполнялись они достаточно долго, оптимизировать стало дальше некуда.
Мы на это дело посмотрели и не внезапно, а через серию обсуждений, приняли решение переделать.
Переделали, оттестировали (в том числе и изменения с перестраиванием), внедрили в эксплуатацию на паре серверов.

Когда убедились, что всё работает, то раскатали на остальные 90+.
Начали собирать положительную обратную связь о том, как теперь всё быстро работает.


Внезапно = неожиданно для разработчика.
Который думал, что новая технология - это серебряная пуля.
Я рад, что у Вас все получилось. Но это ничего не меняет.
Есть очень разный софт и очень разные задачи.
Можно сделать так
- О появилась новая (ха-ха, некоторые тут про микросервисы в 2018 году узнали) технология, все переводим на нее. Ой, не выходит каменный цветок, плохая технология, плохая.
А можно как одни ребята, которые внедряли какой-то проект (было видео на ютубе, но конечно ссылку не найду)
- Рассморели разные архитектуры - микросервисы, монолит, разные типы хранилищ и поняли, что в этом проекте микросервисы не годятся.
Я бы человека, который сказал бы мне, что микросервисы хороши для любой задачи, на работу бы не взял.

"И тут Остапа понесло"

Регистры - это банальная денормализация. Что в ней, простите, нового?
7 ноя 18, 09:55    [21726140]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
SergSuper
skyANA
пропущено...

Откуда внезапно-то? Думаете у нас это в далёком 2003-м году внезапно случилось?

Нет, запросы разрослись, их стало трудно поддерживать, выполнялись они достаточно долго, оптимизировать стало дальше некуда.
Мы на это дело посмотрели и не внезапно, а через серию обсуждений, приняли решение переделать.
Переделали, оттестировали (в том числе и изменения с перестраиванием), внедрили в эксплуатацию на паре серверов.

Когда убедились, что всё работает, то раскатали на остальные 90+.
Начали собирать положительную обратную связь о том, как теперь всё быстро работает.
а можете в двух словах рассказать что была за задача, какие объемы данных, требования по производительности и т.д.?

АИС ТПС НК "ЮКОС"
7 ноя 18, 09:57    [21726145]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
skyANA
Озверин
если же логика потребуется сложнее, то я сначала накидаю SQL запросы к системе нативные, если они дадут результат - буду думать, куда дальше развивать систему

К примеру логика потребуется сложнее, но запросы при этом простые, то в какую сторону пойдёте?


это что такое?:)
Это не описание проблемы\задачи.

Ну вот пример: есть у меня отчетная система. Ничего сложного, пришла она ко мне изначально с нативными запросами. Что мне ее - переписывать на сущности+репозитории? Нет, я просто дописал небольшой агрегатор данных для отчетов и продолжил в том же духе. Легаси ж никто не отменял.

Или еще пример:имеется некий проект. Допустим, у него 3 сущности:
* пользователи
* кастомные поля
* значения кастомных полей для пользователей

Я так понимаю, вы любите EAV? Ну вот по сути кастомные поля и их значения - это ЕАВ. Думаю, не стоит долго расписывать, что если мне надо по сути 1-2 поля, я не буду под этого городить кучу кода, тем более, что jpa и eav без бутылки не свяжешь.
7 ноя 18, 11:14    [21726306]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3810
Озверин
Ну вот пример: есть у меня отчетная система. Ничего сложного, пришла она ко мне изначально с нативными запросами. Что мне ее - переписывать на сущности+репозитории? Нет, я просто дописал небольшой агрегатор данных для отчетов и продолжил в том же духе. Легаси ж никто не отменял.

И что? :)
7 ноя 18, 11:57    [21726417]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3810
Озверин
Я так понимаю, вы любите EAV?

Нет.
7 ноя 18, 11:58    [21726419]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 3810
Озверин
Ну вот по сути кастомные поля и их значения - это ЕАВ.

Почему ЕАВ? Положите их в MongoDB, или PostgreSQL JSONB и не будет никакого ЕАВ :)
7 ноя 18, 11:59    [21726430]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить