Так задача ORM - это маппинг сущностей в первую очередь. Если вы ожидаете от него покрытие всех возможностей генерации SQL, то зря. ORM вообще не про это. В моей ORM вообще можно было через LINQ генерить запросы, а если мало - пиши ручками SQL, орм просто замапит результат.
В типах связей ORM обычно разбирается. Тут нет ничего сложного - есть PK, есть FK на другую сущность. Обычно из этой информации следует единственно возможный вариант джойна.
ORM хорош для 95% запросов, где дальше джойна и простого WHERE ничего не надо. То, что остальные 5% запросов больно делать через ORM не значит, что ORM не нужен
То есть претензия к тому, что гибернейт выполняет запрос в БД, когда вам нужны данные из БД?
Или к тому, что слишком сильно упрощается доступ к БД и котята не понимают, что они лезут в базу, а не в прощающий всё List<T>? Так вроде ORM для этого и нужен.
У меня много вопросов к гибернейту. Например, почему eager/lazy указываются в модели, когда мне для решения вот этого N+1 надо пару раз eager, а потом мне не надо лишний джоин. Почему нельзя было ситуативный выбор сделать, как в EF? Или почему нельзя в полях одновременно получать сам объект и его ID. ID же лежит в колонке, вот он. Ан нет, либо крестик, либо трусы.
Там ещё заморочка была с композитными ключами, сейчас не помню...
Много вопросов, много. Но как-то цепляет, когда его обвиняют в самостоятельной генерации спами в БД.
hibernate ORM, который в фоне заваливает базу миллионом ненужных вам запросов
Непонятно, за что гибернейту досталось. Он же не AI, он сам запросы не выдумывает. Если у вас миллион запросов в фоне от гибернейта, значит где-то миллион запросов в фоне к гибернейту.
Так я о том как раз говорю, что на этапе предварительной архитектуры это просто не видно. Это становится понятно на середине пути. Ну просто старая фича с новой не дружит. А иногда всплывают сотрудники со знаниями, которые не учтены ни мной, ни бизнесом. А ещё я просто не помню, что я писал, к примеру 8 лет назад и почему. И это тоже всплывает во время работы.
Ещё хуже планировать, когда берёшься за чужой легаси-проект. Там вообще непредсказуемые нежданчики выползают. И никто не может объяснить, почему так сделано и зачем.
Оно можно, конечно, на архитектора стрелки перекидывать. Моя проблема была в том, что я и архитектор.
Рефакторить все подряд под бизнес задачами — плохая практика.
В ERP-системе возрастом свыше 10 лет основная когнитивная нагрузка - это как раз бизнес-требования кого-то там когда-то. "Кто-то там" уже лет 5 назад уволился, другие люди по-другому думают, жизнь поменялась, поменялись требования. Ну и с приходом нового функционала старые блоки тоже начинают работать несколько иначе. Это нужно учитывать.
Собственно, рефакторинг обычно - это рефакторинг бизнес-логики. Признаюсь честно, я иногда втихую выкидывал старые требования. Иногда это замечают и приходилось возвращать. Ещё рефакторинг UI. Иногда нужно добавить поле, но там уже столько напихано, что с этим надо что-то делать. Надо изобретать. А сначала не ясно, что делать.
Бизнес-задачи - это такие же задачи. Просто в терминах предметной области. И их надо рефакторить. Если основная сложность системы - именно бизнес-логика, то без рефакторинга этой логики система станет невменяемо сложной.
Вот скорее вопрос про поддерживаемость. На этапе предварительного анализа у меня нет чёткого понимания, как я это могу реализовать. Есть направления, куда можно копнуть. Бывает такое, что во время реализации всплывают какие-то "несрастушечки", ну вот не работает такая схема и всё. Очень часто во время реализации приходит понимание, как это сделать прямо вот очень хорошо и правильно. И проще получится и надёжнее. И самое главное, что пока половину не реализуешь - не додумаешься.
А ещё в моей привычке несколько раз рефакторить текущий блок. Плюс ещё рефакторхаммером достаётся соседним, связанным с текущей разработкой блокам. Всё это предсказать и учесть риски невозможно.
Я понимаю, про что ваша система. Она про то, чтобы котята не устраивали самодеятельность и потом не было мучительно больно всё это поддерживать. Но мне бы такая система стала поперёк горла, просто потому, что она изначально призвана ограничивать выбор вариантов решения.
В процессе реализации код и документ могут разойтись.
По моему опыту, что чем сложнее задача, тем больше в реализации всплывает "подводных камней" и тем ближе к единице вероятность расхождения с изначальным планом.
Этим и опасен предварительный теханализ. При работе над задачей, когда что-то пошло не так, появляется два варианта: делать близко к теханализу, хоть и не оптимально или делать как лучше, но забить на теханализ. Я так понимаю, что вы склоняете программеров к первому решению.
Для моей работы просто вредно подписываться под estimate plan. Но это может быть только для моей области характерно, когда бизнес сам не знает, чего он хочет. Поэтому я обычно пилю прототип, показываю и узнаю, чего на самом деле бизнес хотел.
А может и не стать. Собственно, это и причина поголовного вранья. Если понимаешь, что не возьмут без вранья, а выгонят или нет - это ещё неизвестно, да и опыта можно дорисовать на испытательном - выбор очевиден.
Только тем, у кого есть реальный опыт стало тяжелее устраиваться. Приходишь на собеседования и к тебе относятся заведомо как к лжецу.
Транзакций это один из способов безопасных операций с данными, если говорить по сути, то в ядре своем транзакций содержат идею того, что мы в них можем поместить какое угодно
Кто такой транзакций?
Не пишу в личку, потому что слишком много этого товарища в статье. Это не опечатка, это безмерная неграмотность.
Вообще впечатление такое, что человек писавший это вообще не понимает смысл слов. Поверхностный набор штампов. Никто ни к чему не придерётся, потому что тут даже не знаешь, за что браться.
Не все разработки в этом мире - онлайн магазины. Есть b2b, где каждый заказ индивидуален. Там в принципе не может быть корзины. Термины документооборота тоже могут быть разные. Если у вас quotation, то у нас это называется Purchase Order. Термин я взял у бизнеса, а тот у клиентов, которые пользуются SAP/R3. Ваш вариант не является единственно правильным.
Теперь про НДС. Если вы посмотрите на его расшифровку, то увидите, что он про добавленную стоимость. Это в выставленных документах всё просто - 20% от стоимости. В статье считается прибыль. И тут важно уже учитывать добавленную природу налога в виде налогового вычета.
Так можно и спросить. Вообще из всех комментариев по существу этот первый.
Всего используется около 150 таблиц, из них чуть больше 10 работают через linq. Именно эти таблицы и весят 95% объёма, а остальные 140 кэшируются. Инвалидация производится трекингом данных. На каждый ряд свой таймстемп, по нему делается выборка свежеизменённых строк. Есть метатаблица с данными по каждой таблице, её таймстемпом и версии. Там же информация для кодогенератора, как именно создавать класс под эту сущность.
На первом этапе клиент сверяет метаинформацию по всем репозиториям одним селектом из метатаблицы. Определяет, какие репозитории требуется синхронизировать, делает синхронизацию каждого, взводит эвенты. Знаю, это надо было делать аппликейшен-сервером, но программистов не хватало.
В итоге в памяти кэшируется 140 таблиц, объёмом примерно 250мб. Загрузка происходит в окне логина (позволяет логин/пароль вводить параллельно, чтобы время не терять) и длится 25-30 секунд.
У системы, которая находится в эксплуатации 13 лет, уже нет потенциала для взрывного роста. Да, сначала информация накапливалась быстрее (низкая база), стали видны проблемы с нагрузкой. Первый сервер вообще имел 256мб на борту и как-то справлялся.
Относительно недавно был курьёзный случай. Эксплуатация решила, что серверу хватит 16гб памяти, потому что для 1С 80гб стало маловато. И MySql начал тормозить. При том, что в ERP сидит 100-150 человек, а в 1С от силы 15.
Соответственно, в БД лежит накопленная информация за примерно полторы тысячи человеко-лет.
При таких же темпах заполнения лет через 10 просто надо будет выделить сервер с 64гб памяти. Ну и наверное 16 ядер. Не слишком пугающая проблема, согласитесь?
Пошло ещё с 70х годов, когда кроме stored procedures альтернатив написанию кода для банковских транзакций не существовало. На сегодняшний день ситуация такая, что практически по всем банкам расползлась одна и та же кодовая база.
Легаси в тысячи человеко-лет. Возможно, они бы и хотели переписать всё, но переписывание такого объёма - это гарантированный [роскомнадзор].
Банки кушают этот кактус, потому что у них выбора нет. Зачем приводить их в пример, не учитывая историю айти в банках?
Вы уверены, что это хороший пример? Или это просто карго-культ, раз большие и богатые банки так делают, значит это правильно?
Мысль интуитивно понятна, наврядли кто-то найдёт статью про это. Это тот кейс, про который я рассказывал: нельзя пропускать строки. Вся статья, которую бы я написал, сведётся к следующей строке:
SELECT * FROM table WHERE ID > last_id LIMIT :limit:
к моменту выполнения второго запроса данные могут стать неактуальными
Данные могут стать неактуальными в то время, когда результат запроса летит к пользователю. В то время, когда пользователь их читает. Собственно, для того, чтобы показывать данные, такой трюк не поменяет примерно ничего.
Да, есть ситуации, когда нужно пагинировать данные для сервиса, разбивая большую таблицу на батчи, но здесь непременное условие - не пропустить ни одной строки. По вашему алгоритму между запросами страниц может быть удалена строка из текущей страницы, после запроса которой курсор сместится на количество удалённых записей вперёд. Это касается любых алгоритмов, основанных на row_id.
некую универсальную процедуру для демаршалинга
Под демаршаллингом подразумевается маппинг данных из таблицы в поля класса?
Я думаю, что решение в том, чтобы рассматривать M*N-1 черепах, одновременно работающих в SIMD. Алгоритм на каждом шаге должен выбирать тот путь, который максимально сокращает количество занятых клеток, помещая черепах в одну. И так, пока все не окажутся в одной. Далее задача сводится к доползанию до финиша толпы черепашек.
Так задача ORM - это маппинг сущностей в первую очередь. Если вы ожидаете от него покрытие всех возможностей генерации SQL, то зря. ORM вообще не про это. В моей ORM вообще можно было через LINQ генерить запросы, а если мало - пиши ручками SQL, орм просто замапит результат.
В типах связей ORM обычно разбирается. Тут нет ничего сложного - есть PK, есть FK на другую сущность. Обычно из этой информации следует единственно возможный вариант джойна.
ORM хорош для 95% запросов, где дальше джойна и простого WHERE ничего не надо. То, что остальные 5% запросов больно делать через ORM не значит, что ORM не нужен
То есть претензия к тому, что гибернейт выполняет запрос в БД, когда вам нужны данные из БД?
Или к тому, что слишком сильно упрощается доступ к БД и котята не понимают, что они лезут в базу, а не в прощающий всё List<T>? Так вроде ORM для этого и нужен.
У меня много вопросов к гибернейту. Например, почему eager/lazy указываются в модели, когда мне для решения вот этого N+1 надо пару раз eager, а потом мне не надо лишний джоин. Почему нельзя было ситуативный выбор сделать, как в EF? Или почему нельзя в полях одновременно получать сам объект и его ID. ID же лежит в колонке, вот он. Ан нет, либо крестик, либо трусы.
Там ещё заморочка была с композитными ключами, сейчас не помню...
Много вопросов, много. Но как-то цепляет, когда его обвиняют в самостоятельной генерации спами в БД.
Непонятно, за что гибернейту досталось. Он же не AI, он сам запросы не выдумывает. Если у вас миллион запросов в фоне от гибернейта, значит где-то миллион запросов в фоне к гибернейту.
Так я о том как раз говорю, что на этапе предварительной архитектуры это просто не видно. Это становится понятно на середине пути. Ну просто старая фича с новой не дружит. А иногда всплывают сотрудники со знаниями, которые не учтены ни мной, ни бизнесом. А ещё я просто не помню, что я писал, к примеру 8 лет назад и почему. И это тоже всплывает во время работы.
Ещё хуже планировать, когда берёшься за чужой легаси-проект. Там вообще непредсказуемые нежданчики выползают. И никто не может объяснить, почему так сделано и зачем.
Оно можно, конечно, на архитектора стрелки перекидывать. Моя проблема была в том, что я и архитектор.
В ERP-системе возрастом свыше 10 лет основная когнитивная нагрузка - это как раз бизнес-требования кого-то там когда-то. "Кто-то там" уже лет 5 назад уволился, другие люди по-другому думают, жизнь поменялась, поменялись требования. Ну и с приходом нового функционала старые блоки тоже начинают работать несколько иначе. Это нужно учитывать.
Собственно, рефакторинг обычно - это рефакторинг бизнес-логики. Признаюсь честно, я иногда втихую выкидывал старые требования. Иногда это замечают и приходилось возвращать. Ещё рефакторинг UI. Иногда нужно добавить поле, но там уже столько напихано, что с этим надо что-то делать. Надо изобретать. А сначала не ясно, что делать.
Бизнес-задачи - это такие же задачи. Просто в терминах предметной области. И их надо рефакторить. Если основная сложность системы - именно бизнес-логика, то без рефакторинга этой логики система станет невменяемо сложной.
Вот скорее вопрос про поддерживаемость. На этапе предварительного анализа у меня нет чёткого понимания, как я это могу реализовать. Есть направления, куда можно копнуть. Бывает такое, что во время реализации всплывают какие-то "несрастушечки", ну вот не работает такая схема и всё. Очень часто во время реализации приходит понимание, как это сделать прямо вот очень хорошо и правильно. И проще получится и надёжнее. И самое главное, что пока половину не реализуешь - не додумаешься.
А ещё в моей привычке несколько раз рефакторить текущий блок. Плюс ещё рефакторхаммером достаётся соседним, связанным с текущей разработкой блокам. Всё это предсказать и учесть риски невозможно.
Я понимаю, про что ваша система. Она про то, чтобы котята не устраивали самодеятельность и потом не было мучительно больно всё это поддерживать. Но мне бы такая система стала поперёк горла, просто потому, что она изначально призвана ограничивать выбор вариантов решения.
По моему опыту, что чем сложнее задача, тем больше в реализации всплывает "подводных камней" и тем ближе к единице вероятность расхождения с изначальным планом.
Этим и опасен предварительный теханализ. При работе над задачей, когда что-то пошло не так, появляется два варианта: делать близко к теханализу, хоть и не оптимально или делать как лучше, но забить на теханализ. Я так понимаю, что вы склоняете программеров к первому решению.
Для моей работы просто вредно подписываться под estimate plan. Но это может быть только для моей области характерно, когда бизнес сам не знает, чего он хочет. Поэтому я обычно пилю прототип, показываю и узнаю, чего на самом деле бизнес хотел.
А может и не стать. Собственно, это и причина поголовного вранья. Если понимаешь, что не возьмут без вранья, а выгонят или нет - это ещё неизвестно, да и опыта можно дорисовать на испытательном - выбор очевиден.
Только тем, у кого есть реальный опыт стало тяжелее устраиваться. Приходишь на собеседования и к тебе относятся заведомо как к лжецу.
Транзакций
Кто такой транзакций?
Не пишу в личку, потому что слишком много этого товарища в статье. Это не опечатка, это безмерная неграмотность.
Вообще впечатление такое, что человек писавший это вообще не понимает смысл слов. Поверхностный набор штампов. Никто ни к чему не придерётся, потому что тут даже не знаешь, за что браться.
Не все разработки в этом мире - онлайн магазины. Есть b2b, где каждый заказ индивидуален. Там в принципе не может быть корзины. Термины документооборота тоже могут быть разные. Если у вас quotation, то у нас это называется Purchase Order. Термин я взял у бизнеса, а тот у клиентов, которые пользуются SAP/R3. Ваш вариант не является единственно правильным.
Теперь про НДС. Если вы посмотрите на его расшифровку, то увидите, что он про добавленную стоимость. Это в выставленных документах всё просто - 20% от стоимости. В статье считается прибыль. И тут важно уже учитывать добавленную природу налога в виде налогового вычета.
Так что берегите своих панд.
Так можно и спросить. Вообще из всех комментариев по существу этот первый.
Всего используется около 150 таблиц, из них чуть больше 10 работают через linq. Именно эти таблицы и весят 95% объёма, а остальные 140 кэшируются. Инвалидация производится трекингом данных. На каждый ряд свой таймстемп, по нему делается выборка свежеизменённых строк. Есть метатаблица с данными по каждой таблице, её таймстемпом и версии. Там же информация для кодогенератора, как именно создавать класс под эту сущность.
На первом этапе клиент сверяет метаинформацию по всем репозиториям одним селектом из метатаблицы. Определяет, какие репозитории требуется синхронизировать, делает синхронизацию каждого, взводит эвенты. Знаю, это надо было делать аппликейшен-сервером, но программистов не хватало.
В итоге в памяти кэшируется 140 таблиц, объёмом примерно 250мб. Загрузка происходит в окне логина (позволяет логин/пароль вводить параллельно, чтобы время не терять) и длится 25-30 секунд.
У системы, которая находится в эксплуатации 13 лет, уже нет потенциала для взрывного роста. Да, сначала информация накапливалась быстрее (низкая база), стали видны проблемы с нагрузкой. Первый сервер вообще имел 256мб на борту и как-то справлялся.
Относительно недавно был курьёзный случай. Эксплуатация решила, что серверу хватит 16гб памяти, потому что для 1С 80гб стало маловато. И MySql начал тормозить. При том, что в ERP сидит 100-150 человек, а в 1С от силы 15.
Соответственно, в БД лежит накопленная информация за примерно полторы тысячи человеко-лет.
При таких же темпах заполнения лет через 10 просто надо будет выделить сервер с 64гб памяти. Ну и наверное 16 ядер. Не слишком пугающая проблема, согласитесь?
Вы действительно хотите бенчмарк закешенных в клиенте данных против sql запроса по сети?
Давайте я угадаю? Это Oracle.
Пошло ещё с 70х годов, когда кроме stored procedures альтернатив написанию кода для банковских транзакций не существовало. На сегодняшний день ситуация такая, что практически по всем банкам расползлась одна и та же кодовая база.
Легаси в тысячи человеко-лет. Возможно, они бы и хотели переписать всё, но переписывание такого объёма - это гарантированный [роскомнадзор].
Банки кушают этот кактус, потому что у них выбора нет. Зачем приводить их в пример, не учитывая историю айти в банках?
Вы уверены, что это хороший пример? Или это просто карго-культ, раз большие и богатые банки так делают, значит это правильно?
Ну давайте, расскажите, как сложно разобраться с запросом, в котором есть WHERE, ORDER BY и LIMIT. У вас же код QueryBuilder перед глазами.
И заодно расскажите, почему перенос на клиента бизнес-логики заставит закупить мощное оборудование для базы данных. Ведь об этом статья.
Или Вы просто не читали статью?
При order by не существует решения вменяемой пагинации вообще-то. Я про него не забыл, я его не учитываю.
При требовании "не пропускать строки" пагинация бесполезна. Тут нужно сортировать ПОСЛЕ получения данных. Причём всех.
При показе пользователю метод last_id не нужен. Всё равно пользователь видит устаревшие данные, что там пропущено - это его проблемы.
Мысль интуитивно понятна, наврядли кто-то найдёт статью про это. Это тот кейс, про который я рассказывал: нельзя пропускать строки. Вся статья, которую бы я написал, сведётся к следующей строке:
SELECT * FROM table WHERE ID > last_id LIMIT :limit:
Данные могут стать неактуальными в то время, когда результат запроса летит к пользователю. В то время, когда пользователь их читает. Собственно, для того, чтобы показывать данные, такой трюк не поменяет примерно ничего.
Да, есть ситуации, когда нужно пагинировать данные для сервиса, разбивая большую таблицу на батчи, но здесь непременное условие - не пропустить ни одной строки. По вашему алгоритму между запросами страниц может быть удалена строка из текущей страницы, после запроса которой курсор сместится на количество удалённых записей вперёд. Это касается любых алгоритмов, основанных на row_id.
Под демаршаллингом подразумевается маппинг данных из таблицы в поля класса?
Я думаю, что решение в том, чтобы рассматривать M*N-1 черепах, одновременно работающих в SIMD. Алгоритм на каждом шаге должен выбирать тот путь, который максимально сокращает количество занятых клеток, помещая черепах в одну. И так, пока все не окажутся в одной. Далее задача сводится к доползанию до финиша толпы черепашек.