С бизнесом проще всего решить. Вводите гибкий график работы, благо в IT это просто.
А вот больницы и сады — тут я могу только посочувствовать, держитесь… В россии жто было десять лет назад. До сих пор от слова «веер» в дрожь бросает.
Хм. Похоже не совсем корректно высказался.
Рассмотрим пример запроса через NHibernate, например, на чтение одной записи по ID.
Select [… fields...] from TABLE WHERE id='некоторое число'
Соответственно данное значение будет подставляться при кодогенерации и мы получим
Select [… fields...] from TABLE WHERE id='1'
…
Select [… fields...] from TABLE WHERE id='5'
…
Select [… fields...] from TABLE WHERE id='15'
Именно генерация sql строк и приведет к вымыванию из кеша БД закешированных запросов.
Как я понимаю — для CRUD будет генерироваться SQL запрос. А кодогенерация при активной нагрузке будет активно вымывать КЕШ БД. За что в больших корпоративных системах могут просто расстрелять
Поддержку миграций написать для нормального фреймворка не проблема.
Полный аналог для RoR миграций был написан в компании работающей с CakePHP за неделю.
S->max
l^2-a^2 ->max
достигается при а=0
А вот больницы и сады — тут я могу только посочувствовать, держитесь… В россии жто было десять лет назад. До сих пор от слова «веер» в дрожь бросает.
Рассмотрим пример запроса через NHibernate, например, на чтение одной записи по ID.
Select [… fields...] from TABLE WHERE id='некоторое число'
Соответственно данное значение будет подставляться при кодогенерации и мы получим
Select [… fields...] from TABLE WHERE id='1'
…
Select [… fields...] from TABLE WHERE id='5'
…
Select [… fields...] from TABLE WHERE id='15'
Именно генерация sql строк и приведет к вымыванию из кеша БД закешированных запросов.
Полный аналог для RoR миграций был написан в компании работающей с CakePHP за неделю.