Неа. БД не в курсе про ваши сценарии использования данных. У неё свои представления о прекрасном. Она не знает, когда надо дропнуть кэш, она не угадает, какие данные надо предварительно закешировать, она не в курсе, что вот этот тяжёлый запрос нужен раз в полгода.
Не, не зря. В спецификации той же MySql написано, что корректная работа без PK не гарантируется. Подозреваю, что у всех остальных так же.
Логи записывать в БД - это ещё один повод вызвать полицию. Вот зачем? Есть же тот же самый NLog и ещё куча решений. Выборка логов нужна примерно раз в никогда лет. Ротация нужна по переполнению. БД это тупо не умеет. В файловых логах это мало того, что проще, так ещё и меньше диска занимает и можно выделить хранилище как раз для данных такого рода ценности.
Создавая таблицу без ключа, люди ставят под сомнение сам факт, что тут нужна реляционная система хранения данных. Ну действительно. Нет ключа - нет реляционности. Нет апдейта, нет делита, просто потому, что не за что зацепиться.
Так жук это тот же самый ORM. У него есть свой собственный язык запросов, который транслируется в SQL. И точно также он не покрывает все нюансы SQL и точно также не должен. Фрукт-фрукт.
Про MyBatis уже был спор с кем-то. Утверждали, что он не ORM. Ну да, он просто маппер.
Нафига вам спринг дата я не знаю. Она и мне, если честно не нужна, вместе с жавой. Шарп как-то вкуснее мне оказался. Но то, что есть большая проблема управления сложностью в больших проектах - это факт. Внедрение ORM хорошо помогает с ней справиться, отделяя слой работы с БД от бизнес-логики. Для меня ещё очень важно, что полностью исключаются ошибки маппинга.
Так задача 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 ядер. Не слишком пугающая проблема, согласитесь?
А, понял, вопросов больше не задаю
Ну вот тут спорно
Неа. БД не в курсе про ваши сценарии использования данных. У неё свои представления о прекрасном. Она не знает, когда надо дропнуть кэш, она не угадает, какие данные надо предварительно закешировать, она не в курсе, что вот этот тяжёлый запрос нужен раз в полгода.
Автомат по ремонту и апгрейду оружия уже предлагали? Можно сделать в корпусе холодильника
Не, не зря. В спецификации той же MySql написано, что корректная работа без PK не гарантируется. Подозреваю, что у всех остальных так же.
Логи записывать в БД - это ещё один повод вызвать полицию. Вот зачем? Есть же тот же самый NLog и ещё куча решений. Выборка логов нужна примерно раз в никогда лет. Ротация нужна по переполнению. БД это тупо не умеет. В файловых логах это мало того, что проще, так ещё и меньше диска занимает и можно выделить хранилище как раз для данных такого рода ценности.
Создавая таблицу без ключа, люди ставят под сомнение сам факт, что тут нужна реляционная система хранения данных. Ну действительно. Нет ключа - нет реляционности. Нет апдейта, нет делита, просто потому, что не за что зацепиться.
Так жук это тот же самый ORM. У него есть свой собственный язык запросов, который транслируется в SQL. И точно также он не покрывает все нюансы SQL и точно также не должен. Фрукт-фрукт.
Про MyBatis уже был спор с кем-то. Утверждали, что он не ORM. Ну да, он просто маппер.
Нафига вам спринг дата я не знаю. Она и мне, если честно не нужна, вместе с жавой. Шарп как-то вкуснее мне оказался. Но то, что есть большая проблема управления сложностью в больших проектах - это факт. Внедрение ORM хорошо помогает с ней справиться, отделяя слой работы с БД от бизнес-логики. Для меня ещё очень важно, что полностью исключаются ошибки маппинга.
Я вызываю полицию!
Так задача 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 ядер. Не слишком пугающая проблема, согласитесь?