«двигаясь в роботизированной режиме»
что это значит? в машине есть как минимум водитель и пассажир на переднем сиденье.
Почему в первой части про автопарковку, а во второй про city safety?
карта неделимое целое у которой одна сторона содержит число другая цвет, если будет карта 2, green значит она будет противоречить этому условию как ты её не положи, хоть на ребро
ваш пример можно утрировать до «а кто-то на белое скажет черное», я думаю такие найдутся.
это оптимизация — 4 карты это мало, нет смысла играть в слепую можно открыть все и сделать заключение работает правило или нет, заодно и с другими значениями ознакомиться, может там сразу пустая карта, строка или как ниже писали динозавр
эм, а вы такой инкрементальный бекап сами настраивали? и если вдруг да, то восстановится потом пробовали?
это какой-то очень специфичный кейс когда запись не может изменяться, мне опять только логи на ум приходят.
большие бекапы работают, только если ваши данные (например вместе с серверами) физически уничтожены и это последний выход, когда можно потратить день-два тупо что-бы это всё развернуть.
> Во-первых бэкап нужно делать автоматически перед миграцией на новую версию
ну да, желательно полный, и пофиг что он будет сутки делаться и пока он будет делать там ещё данных набежит.
> и восстановление из бэкапа приведёт к потере минимума данных
вот честно я не знаю примера реальной продакшен базы кроме логов которые можно похерить не то что за часы, а даже за минуты
вообще странный у вас какой-то выбор, сделать VIEW или вытащить все данные, а что SQL запросы уже отменили?
обычные view это просто sql запрос смысл зашивать его в базу, если с БД у вас работают только машины? ещё и отдельные способы миграции для них придумывать
> База данных по определению лучше справится с данными.
не по определению, а в большинстве случаев. и да бывают задачи где лучше вытащить все данные (скорее определенную порцию, но не суть) и обработать их в приложении.
ну и изначально разговор был про триггеры и хранимки
я к этому и спрашивал, что процедура и триггер не атомарные объекты и для них нужны отдельные способы миграции (например хранить полные тексты, тогда изменения не должны потеряться).
но имхо бизнес логика размазанная на 2 уровня (приложение и базу) это зло
> и не боитесь переносить логику во внешние ключи, триггеры и процедуры.
а если я не боюсь, но и не переношу?
ммм, как у вас организованы миграции для триггеров и для процедур?
что это значит? в машине есть как минимум водитель и пассажир на переднем сиденье.
Почему в первой части про автопарковку, а во второй про city safety?
и да код стал ГОРАЗДО понятнее
это оптимизация — 4 карты это мало, нет смысла играть в слепую можно открыть все и сделать заключение работает правило или нет, заодно и с другими значениями ознакомиться, может там сразу пустая карта, строка или как ниже писали динозавр
event cannot be green
или вы с этим не согласны?
public $container;
public __construct(ContainerInterface $container) {
$this->container = $container;
}
единственное когда в аннотации написано не всё. то да лишнего он не добавит. Просто в силу природы динамичности php без подсказок тут нельзя
а так большинство моих issue они позакрывали, я где-то с 5 версии уже не сижу активно на их баг-трекере, так что меня в принципе всё устраивает
habrastorage.org/files/60e/fbf/722/60efbf722ce048d8a0b6d38a2fcddec4.jpg
можно флеш моб устраивать
а вообще напишите
return new static();
это будет понято правильно + больше соответствует поведению self/static вне трейтов
это какой-то очень специфичный кейс когда запись не может изменяться, мне опять только логи на ум приходят.
большие бекапы работают, только если ваши данные (например вместе с серверами) физически уничтожены и это последний выход, когда можно потратить день-два тупо что-бы это всё развернуть.
ну да, желательно полный, и пофиг что он будет сутки делаться и пока он будет делать там ещё данных набежит.
> и восстановление из бэкапа приведёт к потере минимума данных
вот честно я не знаю примера реальной продакшен базы кроме логов которые можно похерить не то что за часы, а даже за минуты
обычные view это просто sql запрос смысл зашивать его в базу, если с БД у вас работают только машины? ещё и отдельные способы миграции для них придумывать
> База данных по определению лучше справится с данными.
не по определению, а в большинстве случаев. и да бывают задачи где лучше вытащить все данные (скорее определенную порцию, но не суть) и обработать их в приложении.
ну и изначально разговор был про триггеры и хранимки
но имхо бизнес логика размазанная на 2 уровня (приложение и базу) это зло
а если я не боюсь, но и не переношу?
ммм, как у вас организованы миграции для триггеров и для процедур?
а вообще слишком агрессивно
Наса тоже не от хорошей жизни продвигают частный космос — украсть у государства это почетно, а у себя глупо