Comments 81
Бизнес-код становится высокоуровнее, короче, надёжнее и проще.
Главное - не заглядывать в получающиеся SQL-запросы. А на претензии "почему всё так медленно" рассказывать, что базе нужен процессор помощнее, памяти побольше, СХД с NVMe и вообще - в облако её. Зато код бизнес-логики выглядит офигенно.
Ну давайте, расскажите, как сложно разобраться с запросом, в котором есть WHERE, ORDER BY и LIMIT. У вас же код QueryBuilder перед глазами.
И заодно расскажите, почему перенос на клиента бизнес-логики заставит закупить мощное оборудование для базы данных. Ведь об этом статья.
Или Вы просто не читали статью?
Вот только объем приложений и дистрибутивов растет чуть ли не в геометрической прогрессии.
А какие именно у вас претензии к SQL-запросам, сгенерированными кодом автора?
У меня никаких претензий. В начале, пока нагрузка небольшая, всё это не обросло тремя слоями костылей - выглядит действительно прикольно. Но чем дальше, тем оно под капотом становится всё более развесистым - и тогда приходят к кому? Правильно, к эксплуатации.
У системы, которая находится в эксплуатации 13 лет, уже нет потенциала для взрывного роста. Да, сначала информация накапливалась быстрее (низкая база), стали видны проблемы с нагрузкой. Первый сервер вообще имел 256мб на борту и как-то справлялся.
Относительно недавно был курьёзный случай. Эксплуатация решила, что серверу хватит 16гб памяти, потому что для 1С 80гб стало маловато. И MySql начал тормозить. При том, что в ERP сидит 100-150 человек, а в 1С от силы 15.
Соответственно, в БД лежит накопленная информация за примерно полторы тысячи человеко-лет.
При таких же темпах заполнения лет через 10 просто надо будет выделить сервер с 64гб памяти. Ну и наверное 16 ядер. Не слишком пугающая проблема, согласитесь?
А вот можно с данной стороны пойти. Загнать всю логику в stored procedure. Считается некошерно, архитекторы морщат носы, но работает быстрее всего
Работает до тех пор, пока не появится несколько десятков тысяч бизенс-процессов, каждый со своей логикой, и каждый из них работает не с одной, а тремя, пятью и более таблицами (а общее количество таблиц исчисляется тысячами)
Вот я недавно в одном банке работал, 100 терабайт, тысячи таблиц, и все на stored proc.
Давайте я угадаю? Это Oracle.
Пошло ещё с 70х годов, когда кроме stored procedures альтернатив написанию кода для банковских транзакций не существовало. На сегодняшний день ситуация такая, что практически по всем банкам расползлась одна и та же кодовая база.
Легаси в тысячи человеко-лет. Возможно, они бы и хотели переписать всё, но переписывание такого объёма - это гарантированный [роскомнадзор].
Банки кушают этот кактус, потому что у них выбора нет. Зачем приводить их в пример, не учитывая историю айти в банках?
Вы уверены, что это хороший пример? Или это просто карго-культ, раз большие и богатые банки так делают, значит это правильно?
А вот и не угадали! MSSQL. Системе лет 15,-20 но начинать писали, говорят, на Дельфи)
Но stored procedures красивы. Во всяком случае, куда стройнее, чем обертки и CRM. Если исходные данные в базе и результат в базе, что сделать это лучше, чем SQL? (Если не брать обработку изображений, искусственный интеллект итд).
Но я развивался от баз. Я впитал SQL с молоком матери) А вот автор статьи, судя по всему, наоборот, постарался максимально от базы отгородиться
Это вы просто привыкли. В реальности практически все языки, на которых можно писать хранимые процедуры - достаточно старые, и не самые удобные на сегодня, как инструменты для написания кода. И всяких странных ограничений из прошлого они тащат с собой прилично.
Если исходные данные в базе и результат в базе
В том-то и дело, что так бывает, но далеко не всегда. А как только у вас исходные данные - какой-нибудь поток из кафки, и несколько разных баз, и еще приложения с их API, и т.п. И что значит, не брать обработку изображений, если это большой кусок интересных и нужных задач (особенно если ИИ и итд включить)?
И попробуйте вот такое написать на T-SQL? Вам сразу приходится тащить другой язык, скажем c# или java или питон, а как только вы его притащили - писать на нем сильно проще, чем на том, что умеет типовая СУБД.
Поддерживаю, хранимки на MS SQL на порядки удобнее Oracle-всяких.
Но они не только красивы, в одном проекте я переписал код с C# вынес в хранимку. Там был сложный обсчёт по нескольким таблицам, плюс spatial запросыии вывод результатов.
Короче, получил буст в 92%.
А у меня ровно наоборот. Попытка реализовать всю логику на скуле с треском провалилась. Ну не тянет он по производительности сложную логику.
Хотя в некоторых случаях да, и UDF/UDTF бывает нужно сделать и процедуры. Правда, опять же не на скуле все это пишется.
Я решал похожую задачу. Решил на SQL но лучше конечно было бы не на нем, а языке с pattern matching.
Увы, но в моем случае pattern matching тоже не вариант по производительности. А все упирается именно в нее т.к. данных много. И наилучшим решением был описанный play off алгоритм с упором на то, что основное количество обращений к БД делается без чтения записи, только проверка ее наличия в индексе (что существенно быстрее).
Вот как вообще pattern matching может быть "не вариант по производительности"?
Да очень просто.
96млн строк с одной стороны, 8тыс строк с другой стороны. Сравниваем каждую с каждой. Прогоняем через профайлер, смотрим время и ресурсы процессора.
Тем более, что когда совпадением строк А и Б считается что-то типа "строка А должна содержать все уникальные элементы строки Б, порядок вхождения и дубликаты не учитываются".
Т.е. какого-то паттерна там нет. Есть два множества уникальных элементов и нужно проверить что пересечение множеств А и Б совпадает с множеством Б.
Да, это реализуется на SQL. Но работает неприемлемо (я бы даже сказал безобразно) долго.
Какое отношение pattern matching имеет к производительности сравнения строк?
И нет, элемент синтаксиса языка не может быть "реализован" в SQL.
Мы живем в реальном мире и решаем реальные задачи. С реальными требованиями как сравнивать строки (что считать совпадением) и граничными условиями за какое время задача должна завершится и выдать конечный результат.
Дальше уже идет выбор наиболее подходящего алгоритма. Если вы сможете реализовать сравнение по указанному алгоритму с использованием patter matching - ради бога. Будет интересно посмотреть на реализацию.
То, что по ссылке - ну такое себе. Что в данном случае считать образом с которым сравнивать? И что именно сравнивать?
Что понадобится - то и будет сравниваться. Это ж, блин, просто другая форма условного оператора и оператора выбора.
Вы будете заранее, до написания программы, планировать где поставите условный оператор и какое в нём будет условие? А как насчёт вхождений буквы "F"? Вот и с паттерн-матчингом так же: никто вам заранее не скажет где именно он там будет использоваться. С ним просто иногда удобнее.
Насколько я помню, на MySQL даже LEFT/RIGHT JOIN по ключу, не очень быстро работал. При такой оптимизации движков, лучшим выбором будет делать на нём что-то простое. Из серии, SQLite уже мало, бизнес логики почти нет, а данные хранить надо.
Оракл, как обычно, покупает что-то, чтобы это потом сгнило.
Это центральный сервер? АБС? И как оно по производительности? Или это тот самый случай, о котором написал выше @ky0?
Ну (как у нас) огромное количество запросов в АБС идет через вебсервисы и очереди - прикручивать к этому всему хранимки такое себе развлечение...
главный недостаток такого подхода всё-таки не в "некошерности", а как раз в области производительности, как ни странно. Точнее — масштабируемости. Всё действительно очень быстро, пока влезает на одну машину. При увеличении объёмов / нагрузки вы будете добавлять процессор / память на сервер субд, до тех пор пока не обнаружите, что ой, а больше 256 ядер больше чем на 4GHz как-то не получается воткнуть в железку. А с горизонтальным масштабированием у РСУБД до сих пор всё сложно... ну, как. некоторые решения есть, но у них куча своих ограничений — не получится просто включить галочку в конфиге и всё смасштабируется, придётся приложение адаптировать.
Ну, делят же на шарды по какому то признаку.
Кроме того, если с базой работают много мелкосервисов, то очевидно они ни в коем случае не должны ничего кешировать сами, а посему опять лучше писать логику на процедурах)))
о очевидно они ни в коем случае не должны ничего кешировать сами
Почему? Наоборот, хотим - кешируем. Кто нам может запретить?
А констистентность?
А что с ней не так? Если это микросервисы, то условно работа с объектом, например счет идет только через него
Поэтому все прекрасно, так как источником знания выступает именно сервис, а не база
Остается задача растянуть кеш в кластер, что не очень сложно достигается для условного редис. И все ... готово горизонтально масштабируемое решение
Под кешем я имел в виду только локальный кеш процесса в памяти. Кешировать MSSQL записи другим процессом, при том, что база сама имеет кеш, так себе идея
Мы как-то делали и такую опцию, чтобы избежать потерь на синхронизацию. Редис выступал в качестве кеша "второго" уровня + информировал остальные ноды приложения, что кеш староват и память надо бы обновить
Про кеш базы - ну такое, понятно чтто чего-то там лежит, и даже можно много положить, но Редис быстрее
источником знания выступает именно сервис, а не база
Ух, сколько интересных открытий и внезапных багов на проде вас еще ждет...
Попробуйте проектировать софт в парадигме что источник правды это БД и только БД. SQL БД. Причем если у вас есть реплики имеющие право отставать от мастера то это надо учитывать. И уже поверх этой парадигмы вешать сервисы, кеши и все что угодно.
Тогда ваша жизнь станет скучнее, а внезапных открытий и багов меньше.
Я смотрю, вы практик, а не теоретик в стране розовых пони
Ух, сколько интересных открытий и внезапных багов на проде вас еще ждет...
А что не так с парадигмой "сервис - источник правды"? Дело в том, что за правдой ходят к нему, а не в БД, поэтому так и есть. А уж "под капотом" реализация может быть оптимизирована под конкретные требования
К сожалению, даже в мире классических банком правды стало очень много и ее с избытком хватает на всех :) Условно баланс по карточному счету может жить во фронте, бэке и опер. дне. И в какой-то момент это могут быть три разных числа и три разные системы, из которых фронт вообще независмый процессинг
Поэтому это просто прекрасно, что кто-то себе может позволить жить в парадигме "источник правды это БД и только БД". Но мир уже давно шагнул вперед, как минимум в enterprise проектах
Транзакционность, согласованность и даже откаты. Не зря спрашивают про ACID на собеседованиях. Это важно.
Как это сделать при условии сервис источник правды совершенно непонятно. Вот надо поменять пару-тройку связанных сущностей, потом подождать чего-то внешнего и только потом закомитить. Как это сделать в архитектуре как у вас совершенно непонятно. Это иногда возможно, но всегда по разному и всегда не очевидно. В sql базе я просто делаю транзакцию и все работает с гарантией.
Если у вас на фронте живет стейт чего-то серьезнее чем расположение окошек, то вы уже проиграли. Я бы пошел в район CTO с планом все переписать нормально и уволился если запретят.
Я не то что про энтерпрайз знаю, я даже про бигтех знаю и делаю. SQL БД хватает в 98.9 процентах случаев. В оставшемся одном проценте случаев нужны всякие newSQL. Еще 0.1 процент случаев это исключения из исключений. Там бывает вообще что угодно. И это очень сложные 0.1 процент.
Балансировка, шардирование, кеширование. Это три кита на которых держится весь хайлоад. Все, кроме совсем исключительных случаев, решается именно ими. А внизу крутится обычная Постгря или не менее обычный Mysql. Понятно что шардированный с ro репликами и все такое.
Аналитика считается по отдельной асинхронной ro реплике вашей sql базы. Она в момент расчета тяжелых штук может или отставать от мастера произвольно или вообще замораживаться. Кроме аналитики в эту реплику никто не ходит. Все уже придумано.
Как сделать как раз понятно, распределённые саги. Просто это на пару порядков сложнее чем ACID в единой базе.
Как это сделать при условии сервис источник правды совершенно непонятно. Вот надо поменять пару-тройку связанных сущностей, потом подождать чего-то внешнего и только потом закомитить. Как это сделать в архитектуре как у вас совершенно непонятно. Это иногда возможно, но всегда по разному и всегда не очевидно. В sql базе я просто делаю транзакцию и все работает с гарантией.
Ну смотрите, к примеру вам надо в рамках одной транзакции "дернуть" веб-сервис, а потом записать в базу. Все, приехали. транзакционность SQL-базы встала и вышла. Точнее она осталась для своей части, но на всю транзакцию уже нет :)
А так уже много где есть и ничего вы с этим не сделаете.
Если у вас на фронте живет стейт чего-то серьезнее чем расположение окошек, то вы уже проиграли
Тут я не понял, причем здесь вообще фронт?
Я не то что про энтерпрайз знаю, я даже про бигтех знаю и делаю. SQL БД хватает в 98.9 процентах случаев
Ну тогда вы наверное знаете, что 100+ систем для большого енерпрайза - это в порядке вещей. И это все должно взаимодействовать между собой. Поэтому транзакционность для одной системы мало кому интересна
SQL БД хватает в 98.9 процентах случаев. В оставшемся одном проценте случаев нужны всякие newSQL. Еще 0.1 процент случаев это исключения из исключений. Там бывает вообще что угодно. И это очень сложные 0.1 процент.
Я не совсем понимаю, что вы хотите доказать? Ну честно. Вам нравится строить решение с бизнес-логикой в базе на хранимках - я не против. Это работало 20 лет назад и может работать и сейчас в отдельно взятых случах. Потому что базы даже стали чуток лучше.
В мире, когда вам надо строить архитектуру предприятия с прицелом на omnichannel и дижитализацию - это не работает. Если опуститься ниже, на уровень архитектуры приложения - хранимки давно не дают привычного инструментария для разработчиков, что делает код сложно сопровождаемым. Итого с базой проще работать через ORM, так как сложные запросы в транзакционной части почти не возникают, а аналитику проще вынести вообще отдельно на свой стек
Я совершенно не возражаю, что базу можно научить быть быстрой, но это никак не влияет на решение, где будет "источник правды".
Ну смотрите, к примеру вам надо в рамках одной транзакции "дернуть" веб-сервис, а потом записать в базу. Все, приехали. транзакционность SQL-базы встала и вышла. Точнее она осталась для своей части, но на всю транзакцию уже нет :)
У меня таких случаев небольшое количество и над ними можно отдельно подумать как правильно, что хотим и что можем гарантировать и реализовать код в этих местах аккуратно.
У вас такими случаями будет все. Думать на каждым апдейтом пары сущностей не вариант. В итоге будет работать как-то.
Я не совсем понимаю, что вы хотите доказать? Ну честно. Вам нравится строить решение с бизнес-логикой в базе на хранимках - я не против. Это работало 20 лет назад и может работать и сейчас в отдельно взятых случах. Потому что базы даже стали чуток лучше.
Хранимки успешно умерли. БД вовремя не осилили нормальные языки и нормальные пайплайны разработки, а производительность стала достаточно хорошей чтобы пожертвовать скоростью работы. Теперь вся логика на бекенде.
ORM из больших проектов выпиливается как правило. Потом поймете почему. jooq и подобное это оптимально для больших, сложных, нагруженных проектов.
Я совершенно не возражаю, что базу можно научить быть быстрой, но это никак не влияет на решение, где будет "источник правды".
Скорость тут вообще не при чем. Речь о гарантиях.
Если у вас куча "микросервисов" смотрят в одну базу, а логика находится в этой самой базе и написана на хранимках - поздравляю, у вас собрались в одном месте все болячки микросервисов, монолита и хранимых процедур.
Да, я ждал этого. Я слышал, что в мире розовых пони один сервис - одна база.
Расскажите плиз как это работает в реальной жизни. Ну вот таблица клиентов банка, она должна быть у каждого сервиса? А платежей по карте?
В реальной жизни я не уверен что следует настолько агрессивно разделять микросервисы.
Ну, можно и так. Вот к примеру, сейчас в работе приложение. Multi tenancy на 1000 организаций. С одной стороны пользовательская нагрузка, с другой - долбятся девайсы каждые 5 секунд рассказать, что у них все "хорошо" и синхронизировать изменения
Я вот как раз думаю описать решение, чтобы поток сообщений от устройств отделить от основного приложения через кафку (там еще есть свои плюсы), чтобы не создавать пиков, а для синхронизации изменения от приложения в устройства реплицировать их на интеграционный слой.
В итоге пользовательская часть будет работать прекрасно, нагрузка от девайсов будет управляемая и не создаст дополнительных пиков. Цена вопроса:
чуток места для данных под синхронизацию, что копейки, так как изменения синхрятся быстро и потом можно удалять
чуток ресурсов под "репликацию", что тож не много, так как изменения в сторону устройств происходят не каждые 5 секунд
Зато нагрузка от устройств, а это условно 10000 "дятлов" каждые 5 секунд терминируется на отдельном инеграционном слое
---------------
Свезти все это в одну точку, т.е. базу - значит создать узкое место, чтобы потом либо иметь там риски, либо героически решать проблемы. Понятно, всегда приятно совершить подвиг, но куда проще не совершать "глупость" до того :)
Ха... К каждому клиенту, помимо платежей, еще столько всякой разнородной информации прицеплено... Документы (несколько штук), адреса (несколько разных типов), держатели карт (через счета клиента), доверенности и доверенные лица ("субъекты")... Риски клиента (и его субъектов), запреты на клиенте... Совпадения с субъектами списков росфина (террористы/экстремисты, список ООН, список решений суда...), совпадения с санкционными списками, данные по последней актуализации клиента - это то, с чем работаю сам. Не считая счетов-проводок, кредитов-депозитов, тарифов-лимитов, выписок разных...
Причем все это используется в самых разных местах - где-то одно, где-то другое...
Использование идеологии 'логика на стороне базы' давно гибкость, если нет дополнительных клей.
Да, у вас может быть микросервис который работает с таблицей клиентов по записи, как OLTP.
Но мы можете и делать bulk update, например, set status=666 where TaxMode=999. И никаких неконстистентностей
Считается некошерно, архитекторы морщат носы, но работает быстрее всего
На самом деле нет :)
Надо понимать, что раньше так и писали. Куча софта с тех лет до сих пор "прекрасно" работает в финансах, страховании, телекоме, ... Но, проблема в том, что движок базы - не самое лучшее место, в котором должны сойтись требования по многопоточности, скорострельности и т.д. Для задач "погонять внутри данные" - да. Для кейса, когда над нами клиентское приложение, куда иногда иможет прибежать толпа - не очень.
Также это все сразу рассыпается, когда из архитекторы с одной большой системой, мы приходим к ситуации, когда "полезные" сервисы раскиданы по куче систем, и это не потому, что главный архитектор чудак на букву "М", а просто потому, что так устроена жизнь и многое "полезное" живет вообще в системах партнеров
Ну и просто забавно видеть такую картину, а над ним тоненький слой аппликухи, которая старательно занимается перекладыванием JSON/XML в парамеры. Хотя нет, более забавное, когда люди их хранимки почту отправляют, общаясь по SMTP :)
И сколько реально больших приложений на памяти здешних обитателей? Когда у вас данные в 256 GB оперативки не влезут?
... а когда они не влезут в 256GB оперативки, просто поставьте 1TB оперативки и не имейте мозги.
Лет 20 назад за такое предложение могли бы и на кол в сервеной посадить, так как сервера уже куплены и часто upgrade стоит как покупка нового :)
Рекомендую к прочтению статью bid data is dead.
Товарищ который в Google за big data и map reduce отвечал написал.
Основная идея: ваши сервера с горизонтальным масштабированием масштабируется линейно, а закон Мара говорит об экспоненциальной функции увеличения производительности.
Вы не можете с линейной функции обогнать экспоненциальную.
Да и компаний типа Google , FB можно по пальцам посчитать. У всех остальных нет больших данных
Это скорее теплое с мягким :)
Во первых - не процом единым. Вы же понимаете, что скорость проца уже условно на порядок быстрее кеша, тот быстрее оперативки и все это вообще ничего не значит, когда приходят кеш и диски :)
Во-вторых,я про практику. Это в облаках расти вертикально несложно, а в своем ЦОДе уже все не так легко
Ну и главное - понятно, что у базоидов база на первом, втором и 35м месте. Так и у проктолога 100% населения с гемороем :) Но мы то знаем правду :)
А дело не только в памяти, которая в эпоху локальных ЦОДов не так уж и легко добивалась
Вы ж проигнорировали
просто потому, что так устроена жизнь и многое "полезное" живет вообще в системах партнеров
Вот и все. Мир, где БД - источник знаний просто рухнул по определению :)
------------
Что касается самой базы - практика показала, что в больших конторах таки она слабое место. Т.е. ты приходишь на проект в большой enterprise и там именно в варианте "БД - основа мироздания", с ней больше всего проблем
Либо она "вешается", когда тут рядом кто-то регулярные процессы запускает. Либо вылазит то пул коннектов, то еще что-то. Либо код написан так - а по другому уже никак, что менять страшно, а работает плохо.
В итоге само ИТ понимает, что базу "надо отрезать", но им требуется внешняя помощь.
---------------
Плюс в самой базе, так или иначе возникает "мешанина", которую лечить можно симптоматически, не более того
У меня 100тб
Вели проект на базе одной известной ORM. Типа, "с объектами разобраться проще, чем тянуть всё на SQL". Данных стало оооочень много много, пришлось лезть на нижний уровень: учитывать структуру табличек, индексы, явно управлять транзакциями... А потом мы перенесли проект на "классический SQL". Переделали довольно быстро, ибо с и бизнес-логикой были хорошо знакомы, и (так как в конце пришлось долго и глубоко барахтаться на "нижнем" уровне) понимали, что может СУБД. И стало быстро работать, и (как ни странно) стало легче сопровождать и развивать.
Я не говорю, что вот так "плохо", а вот так - "хорошо", я говорю - "было дело".
пришлось лезть на нижний уровень: учитывать структуру табличек, индексы, явно управлять транзакциями
А до этого как было? Сущность в коде создал и пусть оно само там как-нибудь в БД наколдует?
Вот вот, правильно организованная бизнес логика в БД существенно облегчает не только разработку, но и сопровождение проектов где не требуется Web интерфейсов, которые сейчас тянут зачем-то в локальные приложения. Я подозреваю что те кто этим занимается либо вынуждены работать с легаси кодом, написанным до них, либо просто банально не знают хорошо SQL и что можно и как на нем делать чтобы не было мучительно больно в сопровождении. Да и само сопровождение практически не требуется. Давным давно в начале 2000-х у меня была ниписана мини- ERP система с логикой в БД , которая прожила примерно 10 лет и последние 5 не имела проблем, когда все бизнес-процессы отлажены в БД. Система имела на то время (начало 2000-х) CRM, ЗАКАЗЫ, КОМПЛЕКТАЦИЮ заказов с приоритетами и отгрузками, формирование отгрузочных документов , учет отгрузок, складской учет с вычисляемым регистром остатков, интерфейс с 1С Бухгалтерией, аналитику , систему хранения документов в БД ( в виде аналога файловой системы с хранением файлов в blob полях). И еще это не требовало мощного железа, сервер был по тем временам довольно средний, все крутилось под Delphi7\ MS SQL Server.
Как показала многолетняя практика на определённом уровне сложности запросов - ORM выбрасывается и проект переделывается на прямые sql запросы.
Как писал классик: абстракции имеют свойство протекать.
А по поводу ORM у меня основной критерий: каков overhead?
К сожалению, вы не сочли нужным проводить бенчмарки, а жаль, было бы интересно.
Вы действительно хотите бенчмарк закешенных в клиенте данных против sql запроса по сети?
А на клиенте они по волшебной палочке закешировались? И как с инвалидацией Кеша быть?
Так можно и спросить. Вообще из всех комментариев по существу этот первый.
Всего используется около 150 таблиц, из них чуть больше 10 работают через linq. Именно эти таблицы и весят 95% объёма, а остальные 140 кэшируются. Инвалидация производится трекингом данных. На каждый ряд свой таймстемп, по нему делается выборка свежеизменённых строк. Есть метатаблица с данными по каждой таблице, её таймстемпом и версии. Там же информация для кодогенератора, как именно создавать класс под эту сущность.
На первом этапе клиент сверяет метаинформацию по всем репозиториям одним селектом из метатаблицы. Определяет, какие репозитории требуется синхронизировать, делает синхронизацию каждого, взводит эвенты. Знаю, это надо было делать аппликейшен-сервером, но программистов не хватало.
В итоге в памяти кэшируется 140 таблиц, объёмом примерно 250мб. Загрузка происходит в окне логина (позволяет логин/пароль вводить параллельно, чтобы время не терять) и длится 25-30 секунд.
Разумеется не хочу.
Насколько я понимаю, кешируется структура БД. Меня интересует сколько памяти тратится при обычной выборке, как быстро она выполняется и т.п. Уверяю вас, что практически каждый ORM на этом этапе различается. Кстати, а как вам вариант с кодогенерацией на этапе компиляции, чтобы не тратиться на кеширование структуры?
У любого решения есть сильные и слабые стороны. Какой-то ORM быстрый, какой-то расходует меньше всего памяти, какой-то плох по всем статьям и т.п. В бенчмарках, как правило, за базовую берётся чистый ADO.NET. Исходя из них и подбирается то, что нужно в конкретном проекте.
/offtop
Дочитал до "НДС - это свойство заказа".
НДС (и подобные налоги) применяется к инвойсу.
Инвойс создается из заказа.
Заказ - из предложения (quotation).
Quotation из корзины.
Каждый раз, когда программист пытается экономить время на всем этом "неважном" - при первом "у нас появилась скидка/промокод" умирает панда.
Не все разработки в этом мире - онлайн магазины. Есть b2b, где каждый заказ индивидуален. Там в принципе не может быть корзины. Термины документооборота тоже могут быть разные. Если у вас quotation, то у нас это называется Purchase Order. Термин я взял у бизнеса, а тот у клиентов, которые пользуются SAP/R3. Ваш вариант не является единственно правильным.
Теперь про НДС. Если вы посмотрите на его расшифровку, то увидите, что он про добавленную стоимость. Это в выставленных документах всё просто - 20% от стоимости. В статье считается прибыль. И тут важно уже учитывать добавленную природу налога в виде налогового вычета.
Так что берегите своих панд.
Там в принципе не может быть корзины
корзина - это идентификатор продукта x количество + какой бы то ни было пэйлоад сверху. называйте как угодно, от сути не убежите
у нас это называется Purchase Order
называйте как угодно, от сути не убежите
Есть b2b, где каждый заказ индивидуален
и что еще хуже, скорее всего и каждое предложение (quotation) индивидуально, и проходит через сэйлзов, и именно поэтому важно отделять его от заказа, инвойса и корзины. называйте как угодно, от сути не убежите
И тут важно уже учитывать добавленную природу налога в виде налогового вычета.
именно поэтому важно его атомарно записывать, и отделить от заказа, чтобы иметь возможность построить любой отчет для любого клиента с любой стороны прилавка
любой из приведенных 4 этапов можно назвать хоть Сюзанной и раздробить еще на 48 дополнительных, но убрать один = выстрелить в панду
Давно не читал столько умных комментариев от заинтересованных профессионалов...и всё таки грустно видеть, как столько времени, энергии и ума тратится на создание кодовых баз, которые потом просто закрывают через несколько лет, или ещё хуже - тратят ещё больше сил, ума и энергии на перенос на новую платформу.
Кто-то вспомнил делфи: пару лет назад модернизировали систему Мерсеру: хранимки и тысячи строк делфовых форм с direct sql. Допиливали новые формы на c#, а хранимки меняли как есть, очумелыми ручками вложенные курсоры правили. И, что самое интересное, было ощущение, что наши формы тоже кто-то скоро перепилит с WinForms на веб, а процедуры так и останутся.
Как бы я ни любил .NET, долю рынка он теряет. К тому же, наше государство хочет Википедию закрыть, что уж тут про вражеский фреймворк говорить.
IT сфера очень молодая. Ей и 100 лет нет. Никто не знает как правильно. Постоянные переделки это нормально, ищем оптимальные варианты.
Тем не менее, есть теория того, как правильнее (тоже очень молодая). Озвучивали ACID, 2PC, транзитивную персистентность. От себя добавлю всякие sql2011 и 2016, поддержку OODBMS с операторами типа DEREF.
Теорию эту видел на магистратуре 7 лет назад, на практике - никогда. Поэтому интересно узнать у знатоков: у Вас есть огромный опыт разработки, глубокое понимание домена. Неужели выгоднее пилить свой ORM, тратить время на производительность, инвалидацию кэша и прочие приблуды?
Система либо требует сложной логики расчёта (как в статье), либо высокой производительности при пиковых нагрузках а ля CRUD - я не могу себе представить сразу оба требования (разве только в геймдеве). Для второго всё понятно: микросервисы и облака.
Хотелось бы узнать, использует ли кто-то в реальности современную альтернативу database-first approach без монструозных хранимок за счёт сложных конструкций sql engine?
Базы данных не существует