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

Откуда: Minsk!!!
Сообщений: 3795
H5N1
Ivan Durak
Все идет к тому, что спарк станет РСУБД, да и ты тот же игнайт уже рсубд назвал. И хайв.
И будут они нормальными рсубд, с ansi sql, mvcc, транзакциями и redolog.
И вопрос с РСУБД решится сам собой, вхождение текущих недосубд бигдата рещений в большую семью рсубд.
Конечно конкретный оракл может и помрет. Но туда ему и дорога. А рсубд будут живы

сомневаюсь я что FK, жестко синхронизированные индексы, autoincrement поля можно будет подружить с массивно параллельностью. без FK и индексов на роль рсубд их не натянуть, имхо. а с ними я слабо представляю перформенс в параллель.

MPP системы уже 100 лет как имеют и индексы и FK и автоинкремент.
От терадаты до гринплама.
https://www.ktexperts.com/teradata-secondary-indexes-in-teradata/
И перформанс в паралель отличный
3 окт 18, 15:26    [21694205]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 604
Ivan Durak
MPP системы уже 100 лет как имеют и индексы и FK и автоинкремент.
От терадаты до гринплама.
https://www.ktexperts.com/teradata-secondary-indexes-in-teradata/
И перформанс в паралель отличный

терадате 100 лет в обед и ничего она на фоне оракла так и не показала за эти годы. как я понимаю с терадаты такой же тренд мигрировать на хадупы.
3 окт 18, 15:46    [21694237]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Addx
Member

Откуда:
Сообщений: 957
Вы не любите кошек? Вы просто не умеете их готовить! (с)

Люди зачастую с трудом понимают смежные области и ищут серебряные пули.
Помню статью на Хабре про крутой проект на микросервисах.
И понимаю, что на SQL это 10 строчек кода.
Просто нужно понимать реляционные базы чуть лучше, чем знать простые join'ы.
И не уповать, что ORM - это панацея для всех проблем.
3 окт 18, 15:54    [21694250]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
казинак
Member

Откуда:
Сообщений: 1273
Alexander Ryndin
H5N1
да известно чего. рсубд до масштабов сбера не отмасштабировать. запихнуть весь сбер в одну субд не выходит. практически каждый филиал там до сих пор отдельные субд
Ну ты ведь не знаешь про Сбер НИЧЕГО. Какого хрена ты несешь эту чушь тут?

да он походу вообще ничего не знает
как попугай повторяет тут про параллель
и не понимает что параллель сделать, как два пальца...
хоть в жаве, хоть в оракле, хоть в пхп
вопрос только в доступном кол-ве ядер и памяти
и в наличии/отсутствии разделяемых ресурсов
3 окт 18, 17:18    [21694370]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
stenford
Member

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

молодой человек, вы там пример прочитали. Микросервисы это следующая стадия развития софта. Одной из предыдущих стадий был именно что переход на ОРМ, он уже давно завершен. А что-б вам стало еще страшнее, в микросервисах нет ни внешних ключей, ни транзакций (между микросервисами), и даже джойны между ними не сделать. И представляете, все работает
4 окт 18, 03:50    [21694734]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 53031
vitkhv
mayton
Я практически ничего не понял из фразы где там 1С-ники что-то решают и решают эффективно.
Хотел-бы посмотреть. Реально хотел. Где тут 1С-ники. Ану покажите мне так вот чтоб я прямо восхитился!

А что хотел та, ну акромя общих фраз?

Давайте я объясню. Я - человек любопытный. Есть у меня такая черта. Инженерный интерес.
В 1С я не специалист. Я его не знаю. И вдруг (!) внезапно в форуме один господин говорит
Пацаны из 1С в части SQL ужо давно тебя уделают, пока ты думаешь что ты крут в SQL со своими PIVOT\UNPIVOT, CTE и прочей магией, пацаны из 1С на чистом и незамутненном SQL решают задачи практически любого уровня сложности.

Разумеется я весь превратился в заинтересованность и жду каких-то пруфов.
И в моем месседже нет никакой враждебности по отношению к 1С.
4 окт 18, 08:51    [21694796]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 53031
Eugene New
отсюда и все проблемы с "где открывали карту, туда и идите"

Читал описание интересной вещи - человек давно закрыл карточку, проверял ее закрытие, работники видели что закрытие прошло, а ему потом снова приходило уведомление о долге. И так несколько раз, пока он не накатал заяву в Центробанк.

Симонов Денис,
так тут говорят разные вещи. От вообще не использовать до "полностью заменить" РСУБД. Я не знаю, чего ждать от Сбербанка после того, как слышал как его региональный руководитель на конференции утверждал на полном серьезе, что к 2030 году человечество ждет бессмертие и его после этого не увезли в дурку.

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

В топике никто не признался что работает в Сбербанке. Соотв у нас нет никакой объективной
информации о том что происходит внутри. Есть жалобы на ошибочные банковские операции.
И мне кажется что пока картины происходящего нет - нам не стоит сейчас ругать или хвалить
Oracle или Middleware или терминалы или прочие звенья этой запутанной системы. У нас - нет
ничего полезного по теме чтобы можно было обсудить. Более того. Если инцедент был
- то существует расследование. И я не верю что дураки там работают. Убежден что есть
архитектурная проблема которая не фиксится в 1 коммит. Надо много чего менять.

И в высшей степени глупо и безответственно заявлять что "виноват Оракл а вот если бы поставили
туда мою любимую СУБД Х то сразу бы не было проблем и все летало-бы и свистело".
4 окт 18, 09:12    [21694808]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
обед
Member

Откуда:
Сообщений: 3
mayton
Eugene New
пропущено...

Читал описание интересной вещи - человек давно закрыл карточку, проверял ее закрытие, работники видели что закрытие прошло, а ему потом снова приходило уведомление о долге. И так несколько раз, пока он не накатал заяву в Центробанк.

Симонов Денис,
так тут говорят разные вещи. От вообще не использовать до "полностью заменить" РСУБД. Я не знаю, чего ждать от Сбербанка после того, как слышал как его региональный руководитель на конференции утверждал на полном серьезе, что к 2030 году человечество ждет бессмертие и его после этого не увезли в дурку.

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

В топике никто не признался что работает в Сбербанке. Соотв у нас нет никакой объективной
информации о том что происходит внутри. Есть жалобы на ошибочные банковские операции.
И мне кажется что пока картины происходящего нет - нам не стоит сейчас ругать или хвалить
Oracle или Middleware или терминалы или прочие звенья этой запутанной системы. У нас - нет
ничего полезного по теме чтобы можно было обсудить. Более того. Если инцедент был
- то существует расследование. И я не верю что дураки там работают. Убежден что есть
архитектурная проблема которая не фиксится в 1 коммит. Надо много чего менять.

И в высшей степени глупо и безответственно заявлять что "виноват Оракл а вот если бы поставили
туда мою любимую СУБД Х то сразу бы не было проблем и все летало-бы и свистело".


работающие в сбербанке подписывают nda, вообщето.
так что и комментировать такие моменты не могут.
но дело точно было не в бобине.

автор
in memory grids типа apache ignite. там заявлены acid транзакции и redo log, консистентность. при этом ignite уже скрестили со спарком и внедрить пытаются не волосатые хипстеры, а уже сбер. и снова цель заместить реляционный оракл.


сбер отказался от grid gain, как от основной среды для мега абс. "не шмогла" обеспечить производительность и надежность на сравнимых с ораклом железе. 100 с лишком серваков гридгейна не потянули объемы сбера. АСИД не взлетел. Дешевле не оказалось.

Это не фоточки из инстаграмма хранить. каждая операция - должна быть обработана.
Короче все эти игры с инмемори только для аналитики и то относительно небольших объемов когда в память одной машины можно все уложить. по нынешнему железу это 2-3 терабайта максимум.

а у ведущих игроков петабайты информации. гридгейн тут вообще ничего не сможет. Хранить в даталейк? ну пытаются... выхлоп ноль вроде.
Ну вот даже слил ты в даталейк миллионы несортированного датамусора, а качество данных и т.п.? Кассандра, Монго, спарк? Данные то они хранить могут, а вот обработать-и что то осмысленное вытащить это боль. Вытащить из кассандры сделки определенного типа всех клиентов определенного сегмента - Бггг. Оно может железо там дешевле достанется. Но разработка выходит платиновая. Дешевле купить за пару лямов баксов оракловый сервер, чем оплачивать 10 явистам год програмирования в касандре то что на оракле 2 человека пишут за месяц.
Поэтому пока хоть рсубд и кактус но приходится его жрать. и пока работающих альтернатив для данных порядка более 10 тб не видел.
12 окт 18, 15:58    [21702709]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
H5N1
Member

Откуда: Yo.! из "Сравнения субд"
Сообщений: 604
обед
сбер отказался от grid gain, как от основной среды для мега абс. "не шмогла" обеспечить производительность и надежность на сравнимых с ораклом железе. 100 с лишком серваков гридгейна не потянули объемы сбера. АСИД не взлетел. Дешевле не оказалось.

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

обед
Ну вот даже слил ты в даталейк миллионы несортированного датамусора, а качество данных и т.п.? Кассандра, Монго, спарк? Данные то они хранить могут, а вот обработать-и что то осмысленное вытащить это боль. Вытащить из кассандры сделки определенного типа всех клиентов определенного сегмента - Бггг. Оно может железо там дешевле достанется. Но разработка выходит платиновая. Дешевле купить за пару лямов баксов оракловый сервер, чем оплачивать 10 явистам год програмирования в касандре то что на оракле 2 человека пишут за месяц.

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

обед
Поэтому пока хоть рсубд и кактус но приходится его жрать. и пока работающих альтернатив для данных порядка более 10 тб не видел.

если бы рсубд работали, не было бы и вопросов. а так что выходит - как только чуть больше данных в аналитики, все денормализуем, пихаем в непонятные звезды, лишь бы реляционости и джоинов было бы поменьше. нужна аналитика чуть серьезней, все решения тащат данные прочь из рсубд. куда-нить в SAS data miner, R server или ML обертки на phyton.
с олтп то же самое. рсубд не тянут. чуть побольше транзакций - на онлайн транзакции табу, пишем в очередь, а там уже что-то в бэкграунде батчами запроцессит. разница с аналитикой лишь в том, что пока и у альтернатив сильно лучшего решения нет. но эти альтернативы то развиваются. ну так и хадупы не в один год потеснили рсубд в фин секторе.
12 окт 18, 19:50    [21702902]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
mayton
Member

Откуда: loopback
Сообщений: 53031
обед
работающие в сбербанке подписывают nda, вообщето.
так что и комментировать такие моменты не могут.
но дело точно было не в бобине.

Я сам подписывал NDA. Но история получила резонанс. И уменя сложилось впечатление что речь идет
чуть ли не о крауд-сорсинге или звучит "крик о помощи" со стороны специалистов СБ которые
понимают сложность и комплексность проблемы и не отказываются от консультаций.

Я за новостями не следил детально и не знаю что там есть и я могу путать два разных события
в ленте новостей СБ поэтому заранее Sorry!
12 окт 18, 22:31    [21703032]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
hVostt
Member

Откуда:
Сообщений: 19352
Eugene New
Сам я люблю язык структурированных запросов. Но если посмотреть на то, сколько всяких технологий придумали для его замену, на то, что пропагандируют в разных книжках, создается ощущение какой то темной иррациональной ненависти к SQL.


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

Писать запросы для каждой из тысячи таблиц?
Это как надо упороться или как надо любить SQL?

Потом. Контроль типов. При разработке ПО статическая типизация рулит, и тем сильнее рулит, чем крупнее информационная система, чем больше разработчиков участвует в разработке.

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

И при этом язык запросов таки нужен, для анализа, для BI, для тюнинга, да много для чего.

Одно вовсе не исключает другое.

Важное во всех этих странных спорах все забывают:

не нужно делать руками то, что может сделать машина.

Нравится упарываться обезьяним трудом? Та ради бога.
27 окт 18, 00:41    [21716672]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Щиче
Member

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

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


Если он молодой, то вы безграмотный :) Все ваши утверждения сплошной треп.
28 окт 18, 08:31    [21717114]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Щиче
Member

Откуда: Чебоксары
Сообщений: 768
Eugene New
Сам я люблю язык структурированных запросов. Но если посмотреть на то, сколько всяких технологий придумали для его замену, на то, что пропагандируют в разных книжках, создается ощущение какой то темной иррациональной ненависти к SQL.

Есть ли какие то рациональные причины?

Я вижу три возможных:
1. Реляционные БД может быть плохо сочетаются с рапараллеливанием на много компьютеров

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

Eugene New
2. ООП плохо связывается с SQL

У дураков и перфекционистов. Mapper вроде Spring JDBC или MyBatis справляются с проблемой многие годы. Дело не в ООП как таковом, а в стремлении идиотов использовать единственный инструмент для всех задач сразу. Профессиональный программист выбирает инструмент под задачу, а не пытается топором копать яму.
Eugene New
3. Возможно считается, что среднестатистический программист настолько туп и не обладает способностями к абстрактному мышлению, что не в состоянии понять реляционную теорию, основанную на понятии множеств.

Ирония состоит в том, что ORM отлично справляется только с небольшим подмножеством задач работы с СУБД. Любой шаг за это подмножество и его мнимое упрощение оборачивается потерей времени на все эти lazy/eager, потерей производительности на выдергивание посторонних данных, неадекватное построение запросов.
ОРМ развивается только в сторону все большего неадеквата. Вместо того, чтобы сразу достать из БД то, что требуется, поднимается сущность с кучей посторонней лабуды, затем эта сущность каким-нибудь MapStruct перешивается в DTO, а уж из неё мы наконец вычленяем то, что будет полезно по делу. Обычно процентов 10%-40% от того, что СУБД нам отдала. Скучно, бессмысленно и затратно.

Причины нелюбви к SQL чисто психологические. Кто-то у нас "прогрессор", который думает только о "новизне" очередной фигни, кто-то у нас перфекционист ("чистота" кода превыше всего), кто-то у нас озабочен никогда не встающими проблемами типа "поменять СУБД", а большинство просто дураки повышающие свое ЧСВ за счет применения "продвинутых" технологий.
28 окт 18, 09:00    [21717117]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
А мне как раз проще писать запросы нативные запросы к базе, чем учить очередную поделку на очередном языке.
31 окт 18, 08:53    [21719801]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Дмитрий Мух
Member

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

Логика в хранимках? Или Вы просто не используете Mapping, Unit Of Work и т.п.?
31 окт 18, 09:03    [21719811]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Дмитрий Мух
Озверин
А мне как раз проще писать запросы нативные запросы к базе, чем учить очередную поделку на очередном языке.

Логика в хранимках? Или Вы просто не используете Mapping, Unit Of Work и т.п.?


Причем тут хранимки? Я ж не про CRUD логику. Я, допустим, про агреггированную выборку. Или про параметризированную выборку со сложными джоинами.
31 окт 18, 11:42    [21720035]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
hVostt
Member

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


Проблема в том, что эту выборку надо захардкодить.
Как её тестировать?
Что делать, когда сложные джойны даже с оптимизациями не потянут по скорости на больших объёмах?
А как сцепить данные с разных систем в реальном времени?

Одна выборка ок.
А когда их овер-дофига?
Каждую писать руками, сопровождать?

Модель данных не зарефакторить от слова совсем и от слова никогда, так как все запросики лягут, столько труда на выброс...

В общем, это очередной холивор,.. типа :)
На самом деле для меня нет, просто суровая реальность говорит о том, что хранимщики просто не хотят лишаться работы, чтобы не учиться чему-то новому.

Так как за них эту же работу в >80% времени может сделать машина.
Рабский ручной труд нужен только для обеспечения рабочих место стране.
31 окт 18, 21:33    [21720882]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Щиче
Member

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


Чем сложнее запрос, тем больше ORM требует внимания к себе и тем хуже он его составляет. Если учесть, что CRUD давно уже автоматизирован на уровне JDBC (Spring Data JDBC, например), то ORM остается кэширование и некоторые другие неоднозначно полезные вещи.

https://habr.com/post/423697/
Механизм ленивой загрузки может внезапно выполнить ресурсоемкие запросы, или и вовсе упасть с исключением. Кэширование может встать на вашем пути когда вы решите сравнить две версии entity, а вкупе с отслеживанием изменений помешает понять — в какой же момент реально выполнятся все операции с базой данных?


Можно точно также писать запросы в аннотации не делая реализацию. Spring Data сама сделает класс реализации. Если вам надо что-то специфичное, вроде connect by Oracle, то проблемы нет. Пишете запрос, а всю подстилку за вас сделают. ORM, извините, дойдет до элементарных вещей в SQL когда-нибудь в следующем тысячелетии. И сделает это так объектно, что придется неделями курить мануалы вместо часа максимум в SQL.

И сущность можно сделать, для неё сгенерят все методы типа findAll и т.д.
31 окт 18, 22:23    [21720920]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
tunknown
Member

Откуда:
Сообщений: 819
hVostt
Проблема в том, что эту выборку надо захардкодить.
Как её тестировать?
Действительно, тестировать что-то при наличии ORM очень трудно.

hVostt
Что делать, когда сложные джойны даже с оптимизациями не потянут по скорости на больших объёмах?
Понять ограниченность опыта своей команды и обратиться к специалисту по традиционным базам данным. Хотя, да. Сейчас 10Gb сети дешевеют, затащим всё на клиента и там ORM всё сделает.

hVostt
А как сцепить данные с разных систем в реальном времени?
Единственное, что хоть как-то оправдывает существование ORM. Однако, необходимость таких архитектурных подходов сильно пропиарена и преувеличена. Можно сделать то же самое средствами СУБД, и часто это изменение архитектуры будет более выигрышным.

hVostt
Одна выборка ок.
А когда их овер-дофига?
Каждую писать руками, сопровождать?
Что на клиенте, что на сервере придётся и программировать и сопровождать. На клиенте сопровождать затратнее.

hVostt
Модель данных не зарефакторить от слова совсем и от слова никогда, так как все запросики лягут, столько труда на выброс...
Зарефакторить что-либо при наличии ORM действительно невозможно. Хотя, это не нужно, т.к. 100Gb сети не за горами. Если не умеете архитектурно разделять данные и код, то и "запросики лягут".

hVostt
На самом деле для меня нет, просто суровая реальность говорит о том, что хранимщики просто не хотят лишаться работы, чтобы не учиться чему-то новому.
Просто императивщики не хотят учиться и изучить СУБД.
1 ноя 18, 09:30    [21721093]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 3070
H5N1
ну не взлетел у сбера, взлетит у западного банка. дело то не в конкретной попытки или реализации. дело в архитектуре, которая уже показала все что надо. а код отладят. может это и не игнайт будет, а что
суть не в конкретной попытки, а в том что с технологией играют серьезные игроки. то же самое было с хадупами.
ктати у сбера не 100, а 2000 нод в кластере.

гридгейн это поделие сбера. Посмотрите у него страничку инвесторы и на Витюху Орловского в совете директоров. Сомневаюсь, что серьёзный западный банк больше Сбера будет внедрять на полную это каптивное поделие, которое не взлетело даже у его создателя.
1 ноя 18, 11:40    [21721255]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Бумбараш
H5N1
ну не взлетел у сбера, взлетит у западного банка. дело то не в конкретной попытки или реализации. дело в архитектуре, которая уже показала все что надо. а код отладят. может это и не игнайт будет, а что
суть не в конкретной попытки, а в том что с технологией играют серьезные игроки. то же самое было с хадупами.
ктати у сбера не 100, а 2000 нод в кластере.

гридгейн это поделие сбера. Посмотрите у него страничку инвесторы и на Витюху Орловского в совете директоров.
не совсем
фирма уже существовала много лет на момент покупки сбером
http://www.jetinfo.ru/stati/intervyu-s-osnovatelem-i-tekhnicheskim-direktorom-gridgain
1 ноя 18, 12:07    [21721308]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 3070
ну ок, переформулируем - гридгейн сейчас живет на деньги Сбера. Кто слышал про неё до покупки сбером? Даже в статье сбер упоминается 11 раз и история крупных контрактов в России идет от Сбера. Типа мы делаем в Сбере, на это люди смотрят и тоже думают.
1 ноя 18, 13:20    [21721449]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
Бумбараш
ну ок, переформулируем - гридгейн сейчас живет на деньги Сбера. Кто слышал про неё до покупки сбером? Даже в статье сбер упоминается 11 раз и история крупных контрактов в России идет от Сбера. Типа мы делаем в Сбере, на это люди смотрят и тоже думают.

гридгейн это имортозамещенный Apache Ignite который уже давно работает, без всяких сбербанков.
1 ноя 18, 13:26    [21721457]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
hVostt
Member

Откуда:
Сообщений: 19352
tunknown
hVostt
Проблема в том, что эту выборку надо захардкодить.
Как её тестировать?
Действительно, тестировать что-то при наличии ORM очень трудно.


Да? Несколько крупных успешных проектов, где ORM полностью покрыто тестами, без существенных трудозатрат? Что делали не так? Может просто руки не из ж? ))


tunknown
hVostt
Что делать, когда сложные джойны даже с оптимизациями не потянут по скорости на больших объёмах?
Понять ограниченность опыта своей команды и обратиться к специалисту по традиционным базам данным. Хотя, да. Сейчас 10Gb сети дешевеют, затащим всё на клиента и там ORM всё сделает.


Никакой опыт не может считаться вышкой. Только во влажных мечтах джунов. Что значит "всё на клиента"? Двухзвенка, м? Вы думаете ORM-ы не генерят запросы к БД? Или чего вы хотите сказать? Пока что я вижу, что просто выпячиваете грудь, но без аргументов, это дико смешно ))

tunknown
hVostt
А как сцепить данные с разных систем в реальном времени?
Единственное, что хоть как-то оправдывает существование ORM. Однако, необходимость таких архитектурных подходов сильно пропиарена и преувеличена. Можно сделать то же самое средствами СУБД, и часто это изменение архитектуры будет более выигрышным.


Существование ORM оправдывает сотни тысяч успешно выполненных проектов, выполненных быстро, без ушедших в историю дба, хорошо выполняющих свои задачи. Суть в том, что религиозные взгляды некоторым не позволяют видеть дальше собственного носа. Хотя и обратный случай клиники тоже есть.

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

tunknown
Что на клиенте, что на сервере придётся и программировать и сопровождать. На клиенте сопровождать затратнее.


Вы опять про двух-звенку? Ну-ну. Опыт, смотрю, так и прёт у вас изо всех щелей

tunknown
Зарефакторить что-либо при наличии ORM действительно невозможно. Хотя, это не нужно, т.к. 100Gb сети не за горами. Если не умеете архитектурно разделять данные и код, то и "запросики лягут".


Серьёзно? Мы успешно рефакторили, и не раз. Коллеги рефакторили, без проблем. Меняли вендора БД. Писали сразу под несколько вендоров (MS SQL, Postgres, Oracle). Никакие запросики не легли. Архитектурно, данные и код надо разделять так: в БД лежат данные, в приложении код, запросы это тоже код (надеюсь, хоть это для вас не будет открытием).

tunknown
Просто императивщики не хотят учиться и изучить СУБД.


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

Но что важно, это может быть оскорбительным.. Но не обессудьте. Некоторым нравится обезьяний труд, так как ничего другого они не умеют, понимать, изучать, осваивать не хотят. А хотят сидеть на насиженном месте, так как обезьяний труд он и есть обезьяний. Для обезьян.
6 ноя 18, 04:19    [21724782]     Ответить | Цитировать Сообщить модератору
 Re: Причины ненависти к языку SQL?  [new]
Дмитрий Мух
Member

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

Логика в хранимках? Или Вы просто не используете Mapping, Unit Of Work и т.п.?


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

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

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

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

И то, что Вы назвали CRUD логикой у вас где, в хранимках?
6 ноя 18, 08:07    [21724817]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить