Беседовал с одним немолодым дядькой - он какой-то научный сотрудник со степенью. Он рассказал, что они в свое время в институте проводили эксперименты с алкоголем. Все знают, что после первой-второй наступает хорошее веселое состояние, при этом ты еще в кондиции. Так вот они хотели вывести зависимость - как нужно догоняться в зависимости от индекса массы тела, возраста и т.п., чтобы поддерживать это состояние достаточно долго. И он сказал, что эксперименты зашли в тупик и они постоянно напивались потому, что кто-то вечно не выдерживал и восклицал - между первой и второй перерывчик небольшой!
Что-то тут нечисто с цифрами и расчетами. Чтобы просто перекачать 68000 куб.м воды в час, к примеру, с глубины 500м - нужен насос на 3,8 МВт. И это без учета трения и т.п. Как эта штука будет работать на 50КВт существовать - непонятно.
Сарказм и безапелляционность - это хорошо, это признак молодости, это значит, что все впереди. А по делу - моему авто 22года и пробег пятый круг. Так все в хорошем состоянии, но многие расходники требуют замены. Их много и они дешевы, только в штатах.
Не нужен титановый корпус и дрыгатель из адамантия. Делайте хотя бы авто из 90-х. Где те двигатели-милионники? Они тогда стоили разумных денег, а не как крыло от самолета. Гарантии на кузов были от коррозии ого-го! Волею судеб являюсь владельцем старого американского вэна. Тяга открывания замка у меня стальная. Следующее поколение - тяга стальная, наконечник пластик, который от жары начинает рассыпаться через 10 лет. Следующее поколение - тяга пластиковая хитрой формы, которая и пяти лет не выдерживает. А теперь скажите мне, что это в угоду экологии. Да от новых машин пластика больше, чем от старых. Я бы купил ту машину еще раз, да не выпускают.
Вообще тема миграции довольно обширна. Для более-менее успешного выполнения еще на этапе проектирования структуры БД необходимо предусмотреть как жизненный цикл данных, так и возможность миграции. Для миграции, например, нужно чтобы приложение обращалось к логическому слою БД. Т.е. приложение->(view, ХП, instead of триггера и т.д.)->физические таблицы, служебные представления, удаленные подключения к другим БД и т.д. Метаданные в БД обновить можно быстро(не всегда, увы), как с увеличением версии, так и с уменьшением. А обновление физической структуры можно сделать асинхронным. К сожалению, на этапе проектирования мало кто задумывается об этом. Причина, имхо, в том, что разработчиком-архитектором выступает, как правило, архитектор приклада(джавер, питонист, пхпшник etc). Он знает БД на уровне "select * from table t"(я тут утрирую, конечно). А потом начинается "веселье".
В oracle OEBS ты еще порнографии не видел.
Беседовал с одним немолодым дядькой - он какой-то научный сотрудник со степенью. Он рассказал, что они в свое время в институте проводили эксперименты с алкоголем. Все знают, что после первой-второй наступает хорошее веселое состояние, при этом ты еще в кондиции. Так вот они хотели вывести зависимость - как нужно догоняться в зависимости от индекса массы тела, возраста и т.п., чтобы поддерживать это состояние достаточно долго. И он сказал, что эксперименты зашли в тупик и они постоянно напивались потому, что кто-то вечно не выдерживал и восклицал - между первой и второй перерывчик небольшой!
Вакцина от чумы ну и другие массовые прививки
Третья картинка прямо напомнила Минина и Пожарского.
Все хорошо, но инструкцию надо было перевести, я считаю. Возможно, пригодится...
Вы забыли про потенциальную энергию условного куба воды при перемещении вверх/вниз.E=mgh
Что-то тут нечисто с цифрами и расчетами. Чтобы просто перекачать 68000 куб.м воды в час, к примеру, с глубины 500м - нужен насос на 3,8 МВт. И это без учета трения и т.п. Как эта штука будет работать на 50КВт существовать - непонятно.
Сарказм и безапелляционность - это хорошо, это признак молодости, это значит, что все впереди. А по делу - моему авто 22года и пробег пятый круг. Так все в хорошем состоянии, но многие расходники требуют замены. Их много и они дешевы, только в штатах.
Не нужен титановый корпус и дрыгатель из адамантия. Делайте хотя бы авто из 90-х. Где те двигатели-милионники? Они тогда стоили разумных денег, а не как крыло от самолета. Гарантии на кузов были от коррозии ого-го! Волею судеб являюсь владельцем старого американского вэна. Тяга открывания замка у меня стальная. Следующее поколение - тяга стальная, наконечник пластик, который от жары начинает рассыпаться через 10 лет. Следующее поколение - тяга пластиковая хитрой формы, которая и пяти лет не выдерживает. А теперь скажите мне, что это в угоду экологии. Да от новых машин пластика больше, чем от старых. Я бы купил ту машину еще раз, да не выпускают.
Водород хранить - большая проблема.
>Яндекс договорился с 84,9% зарубежными акционерами-держателями конвертируемых облигаций по поводу выкупа ценных бумаг
Интересно, для того, кто писал заголовок, - русский язык родной или нет?
Салтыков-Щедрин с вами не согласен. Ну, то есть, воды-то много утекло, конечно
"Эх, дружок! Это не ты выбираешь присягу. А присяга выбирает тебя!"(с)
Ой, ну все, все, убедили! Не поеду в эту вашу Америцу!
ЗЫ. Пойду на балалайке поиграю да выпью водки...
Я тоже не поддерживаю. Но, как выяснилось, мировая экономика управляется не совсем экономическими методами.
У нас был препод в универе - он чертежи предпочитал смотреть вверх ногами. Может, тут то же самое?
Чего только люди не наизобретают - лишь бы не использовать flydb/liquibase etc.
Вообще тема миграции довольно обширна. Для более-менее успешного выполнения еще на этапе проектирования структуры БД необходимо предусмотреть как жизненный цикл данных, так и возможность миграции. Для миграции, например, нужно чтобы приложение обращалось к логическому слою БД. Т.е. приложение->(view, ХП, instead of триггера и т.д.)->физические таблицы, служебные представления, удаленные подключения к другим БД и т.д. Метаданные в БД обновить можно быстро(не всегда, увы), как с увеличением версии, так и с уменьшением. А обновление физической структуры можно сделать асинхронным. К сожалению, на этапе проектирования мало кто задумывается об этом. Причина, имхо, в том, что разработчиком-архитектором выступает, как правило, архитектор приклада(джавер, питонист, пхпшник etc). Он знает БД на уровне "select * from table t"(я тут утрирую, конечно). А потом начинается "веселье".
Добавить колонку ерунда. Вот физически удалить колонку из большой таблицы - это могут быть часы.
Безусловно мы жили лучше, чем в 1913году. Но когда приходят и заявляют, что все было идеально и только враги нас развалили - это неправда.