Есть сущности из нескольких табличек, типа документ с метаданными и табличной частью бьётся на таблички 1:N. С автоид сложно создать его атомарно одним запросом с клиента: сначала надо вставить метаданные в сторонй 1, получить их ид, а потом вставлять строки стороны N с этим id. Ну и необходимость синхронщины вылазит.
По порядку получится только если есть или можно создать единое централизованное место генерации — оно же единая точка отказа. Из коробки, вроде, в популярных базах с поддержкой мастер-мастер репликации только костыли разной степени лепить можно.
Недостатки этих способов я знаю, но для использования systemd с ними придётся мириться так или иначе. Предпочтительно залить кадрами, деньгами и времени а-ля отдельная если не команда, то специалист, для качества и предсказумости начальной разработки и поддержки. На практике, скорее, маны в зубы и пилить в личное время без "код-ревью" или как там процесс называется.
И здесь выясняется, что если нет гипер требований по изоляции — мы можем поверх того же железа натянуть кубер и управлять контейнерами с БОЛЕЕ ВЫСОКОЙ утилищацией аппаратных ресурсов…
Вот только кубер здесь необязательное звено. Нередко только уменьшающее утилизацию и аппаратных и человеческих ресурсов для сценариев типа "поднять 100500 сайтиков на одном хосте".
Для меня это всё обычные ошибки. Можно пояснять в теле, что не так или рекомендации какие-то давать. А когда неверный урл, то не то что обычная (пользователь ввёл что-то не то), а критическая или типа того — код неправильно написан.
Знакомый рассматривает вариант после того, как установил свой дизель-генератор в своём доме как основной источник электричества. По предварительным расчётам вроде выходит, что дешевле и удобнее время от времени завозить соляру и от неё заряжать условный лиф, чем заправлять его бензином постоянно и на сторонних платных "зарядках" заряжать.
Вроде про КПД речь шла, а не про расход заряда? Если на горку что-то поднимать, то работы больше нужно совершать исходя из физики, в которой вечный двигатель невозможен. А КПД тут только если двигатель/источник энергии в горку работает неоптимально, на сколько-то джоулей полезной работы тратит больше квт-ч час чем на ту же работу на ровном месте.
Есть сущности из нескольких табличек, типа документ с метаданными и табличной частью бьётся на таблички 1:N. С автоид сложно создать его атомарно одним запросом с клиента: сначала надо вставить метаданные в сторонй 1, получить их ид, а потом вставлять строки стороны N с этим id. Ну и необходимость синхронщины вылазит.
Я закончил школу 29 лет назад… И всё что вы описали я написал одной фразой "если двигатель/источник энергии в горку работает неоптимально".
Внутри большой системы обычно несколько баз, и не только sql.
Плюс большие системы редко живут в одиночку — интеграции, синхронизации, репликации...
Это у какого большинства?
Ну вот как я понимаю, из-за советов типа Клиент всегда должен знать полное состояние системы пост и воспринимается в контексте REST
По порядку получится только если есть или можно создать единое централизованное место генерации — оно же единая точка отказа. Из коробки, вроде, в популярных базах с поддержкой мастер-мастер репликации только костыли разной степени лепить можно.
По авторитетным источникам я жил при коммунизме. ) Как мне не знать? ))
Недостатки этих способов я знаю, но для использования systemd с ними придётся мириться так или иначе. Предпочтительно залить кадрами, деньгами и времени а-ля отдельная если не команда, то специалист, для качества и предсказумости начальной разработки и поддержки. На практике, скорее, маны в зубы и пилить в личное время без "код-ревью" или как там процесс называется.
Докер с композом проще гораздо. ) Пока не хайлоад
Однозначно, но лезть в систему лень, чтобы удалить, если можно, и ответить "нет")
Вот только кубер здесь необязательное звено. Нередко только уменьшающее утилизацию и аппаратных и человеческих ресурсов для сценариев типа "поднять 100500 сайтиков на одном хосте".
sudo add-apt-repository ppa:ansible/ansible и ко принимается за правильный ответ? )
docker-compose (вариант docker swarm mode) очень удобны для простого разворачивания а-ля
git pull && docker-compose up. systemd же навскидку вижу несколько вариантов:Как-то все варианты простыми не выглядят.
Может возвращать только нужный стейт, может выполнять только нужные операции, по минимуму переданных данных.
За что? Удобно же. Например, если нам нужен обязательный ответ на то согласен юзер на спам )) или нет
Для меня это всё обычные ошибки. Можно пояснять в теле, что не так или рекомендации какие-то давать. А когда неверный урл, то не то что обычная (пользователь ввёл что-то не то), а критическая или типа того — код неправильно написан.
Дизель вроде выгоднее для такого режима
С 16-го этажа...
Знакомый рассматривает вариант после того, как установил свой дизель-генератор в своём доме как основной источник электричества. По предварительным расчётам вроде выходит, что дешевле и удобнее время от времени завозить соляру и от неё заряжать условный лиф, чем заправлять его бензином постоянно и на сторонних платных "зарядках" заряжать.
Вроде про КПД речь шла, а не про расход заряда? Если на горку что-то поднимать, то работы больше нужно совершать исходя из физики, в которой вечный двигатель невозможен. А КПД тут только если двигатель/источник энергии в горку работает неоптимально, на сколько-то джоулей полезной работы тратит больше квт-ч час чем на ту же работу на ровном месте.
Очень много про передачу представлений состояний) Почти ничего про операции, отличные от HTTP методов.