Проверять конечно надо. Но я думаю, что результат совершенно предсказуем при наличии векторных операций или каком-либо кэше.
Вы абсолютно правы, что ваш алгоритм лучше для минимизации времени каждой выборки. Собственно, я подумал, а можно ли уменьшить максимальное время выборки и думал в сторону размазывания сдвига по операциям записи. Получился тот же алгоритм, что у вас.
Но. Можно сделать ещё лучше. Так сказать объединить алгоритмы. Если у нас известна кратность копирования (например копируется по 128 бит, а юнит у нас инт в 32 бита), то можно писать через 4 записи. Так же дважды, как предлагали.
Я, конечно, знал, что я асоциальное существо и нон-конформист, но похоже, что у меня рекорд )
28 рейтинга минус рис и кошка-жена
Чувствую себя хорошо, пилю стартап, живу на сбережения и проценты по депозитам.
Собственно, результат только подтверждает мысль, что результат теста показывает только результат теста и ничего более. О куче нюансов он не знает и знать не может.
Неа. БД не в курсе про ваши сценарии использования данных. У неё свои представления о прекрасном. Она не знает, когда надо дропнуть кэш, она не угадает, какие данные надо предварительно закешировать, она не в курсе, что вот этот тяжёлый запрос нужен раз в полгода.
Не, не зря. В спецификации той же 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. Иногда нужно добавить поле, но там уже столько напихано, что с этим надо что-то делать. Надо изобретать. А сначала не ясно, что делать.
Бизнес-задачи - это такие же задачи. Просто в терминах предметной области. И их надо рефакторить. Если основная сложность системы - именно бизнес-логика, то без рефакторинга этой логики система станет невменяемо сложной.
Нет
Мммм, пахнуло Мари Кондо. Для диайвайщика это очень плохой совет.
Минусы ставят ввиду абсолютной бессмысленности статьи. Ну и плюс реклама телеграм-канала. Вместе оно понятно, зачем вообще автор здесь.
Проверять конечно надо. Но я думаю, что результат совершенно предсказуем при наличии векторных операций или каком-либо кэше.
Вы абсолютно правы, что ваш алгоритм лучше для минимизации времени каждой выборки. Собственно, я подумал, а можно ли уменьшить максимальное время выборки и думал в сторону размазывания сдвига по операциям записи. Получился тот же алгоритм, что у вас.
Но. Можно сделать ещё лучше. Так сказать объединить алгоритмы. Если у нас известна кратность копирования (например копируется по 128 бит, а юнит у нас инт в 32 бита), то можно писать через 4 записи. Так же дважды, как предлагали.
У вас запись O(1), но дважды.
Можно также брать массив N+M и через каждые M записей сдвигать в ноль. При 2N массиве это будет быстрее, чем дважды писать каждую запись.
"Кажется, у нас новый председатель" (с)
Я, конечно, знал, что я асоциальное существо и нон-конформист, но похоже, что у меня рекорд )
28 рейтинга минус рис и кошка-жена
Чувствую себя хорошо, пилю стартап, живу на сбережения и проценты по депозитам.
Собственно, результат только подтверждает мысль, что результат теста показывает только результат теста и ничего более. О куче нюансов он не знает и знать не может.
Вы не правы в том, что умственный труд - это отдых. Знаете, когда я вагоны грузил, я не так уставал, как при умственном труде.
Конечно, в среднем по больнице, жить стало проще. Основной контраргумент автору - базовые потребности закрываются намного дешевле, ибо прогресс.
С одной стороны прогресс сильно разгрузил простую работу, а с другой научился выжимать всё из интеллектуального труда.
Мы страдаем. Лучше бы я остался вагоны разгружать (хотя кому я вру?)
А, понял, вопросов больше не задаю
Ну вот тут спорно
Неа. БД не в курсе про ваши сценарии использования данных. У неё свои представления о прекрасном. Она не знает, когда надо дропнуть кэш, она не угадает, какие данные надо предварительно закешировать, она не в курсе, что вот этот тяжёлый запрос нужен раз в полгода.
Автомат по ремонту и апгрейду оружия уже предлагали? Можно сделать в корпусе холодильника
Не, не зря. В спецификации той же 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. Иногда нужно добавить поле, но там уже столько напихано, что с этим надо что-то делать. Надо изобретать. А сначала не ясно, что делать.
Бизнес-задачи - это такие же задачи. Просто в терминах предметной области. И их надо рефакторить. Если основная сложность системы - именно бизнес-логика, то без рефакторинга этой логики система станет невменяемо сложной.