Взрывной рост зарплат испортил айти. Без него было бы проще. Но имеем то, что имеем. Опять же, можно позволить себе ипотеку даже без богатых родителей.
В итоге сейчас есть две касты наемного персонала. Первые типичные наемники и меняют работу за любую интересную прибавку. Вторые готовы почти на все, ради своего интереса в работе. И не надо подводить все советы под обе эти касты, кесарю кесарево.
Про первых я ничего не скажу. А вот по поводу вторых, не работает у них нормально подход — пообещал-повысили. Человек должен сразу мочь и хотеть делать больше. К примеру у меня была одна история из жизни. Пришел я ко второму своему клевому начальнику, и сказал что год-прошел-инфляция-мое-понимание-бизнес-процессов-выросло-да-и-вообще-я-ого-го. А он мне на 3% всего прибавку дал. Я конечно обиделся, но тут подвернулся клевый проект, и я в нем погряз, забыв про обиды-деньги. В общем мне через два месяца дали премию в размере зряплаты. И потом стали так каждый квартал делать. То есть если бы я просто не попросил без всякий непонятных обещайний стать-лучше/взять-больше, то мне бы и не дали скорее всего. У айтишников очень плохо с чтением мыслей. Надо уметь говорить честно, когда что-то не нравится. И не надо при рассказывать небылицы и обещать всякую ересь. Можешь делай сразу!
Да и трясти офером перед начальством это тоже гнилая затея. Сколько раз такой шантаж будет работать? Почему офер от другой компании должен быть объективен? Может у меня там друг нарисовал на бумажке удобные цифры? Но вот ходить на собеседования полезно, понимаешь рынок и себя при этом. Обретаешь уверенность/наглость просить больше. Ну а если не дадут, то значит тебя и не ценят в этой компании. А если не ценят, то значит твоя работа особо никому не нужна. Может быть причина в том, что не нужен твой опыт, для такой работы. Есть правило: не повысили за год — ты возможно не нужен (работай над собой или уходи), повысили в рамках инфляции — ты нужен (может быть это потолок уже, или ты недостаточно хорош), повысили больше чем на уровень инфляции — ты очень нужен (надо продолжать жечь в том же духе).
Резюме — будь полезен, работай над собой и не шантажируй начальство. Умей честно говорить о проблемах и немного ждать. Если дело швах, то уходи.
К слову сказать, это уже контрактная модель производства. Но работающая на базе принятия в штат. И не повышение зарплаты, есть сигнал, что твой опыт тут больше ненужен. Многие это понимают, и благодаря опыту и связям сразу работают контрактниками по временным договорам. Может быть действительно, не стоит изображать девочку, и принять что программисты пишущие новый софт, это контрактники на временных договорах?
p/s ну а если после ухода, в старой компании появляется вакансия +xx% к окладу, то это намек, что нужен другой человек. А не закостенелый страрожила рабочего места.
На первой работе вырос в зарплате в 5 раз, правда пришел стажером, ушел ведущим. На второй в 2 раза, там лояльность сильно оплачивалась из премиального фонда. Потом переехал в Питер, и увидел, что тут совсем все не так. И для повышения надо менять работу. То есть таким способом бизнес создает универсальные винтики. Человек знает всего понемногу и быстро учится новому. И эта экспертиза важнее знания постоянно меняющегося бизнеса. И вот это меня угнетает, я не хочу менять работу. Но семья требует денег.
Во первых уместно, надо уметь сказать что иногда подходы к масштабированию не нужны. Во вторых, вы умеете без переписывания кода любое продакшен решение развернуть на двух томкетах с мемкешем сессий? Все равно нужна фаза анализа и подготовки кода.
Иногда дешевле, иногда дороже, все зависит от ситуации. А кстати репликацию настраивать не надо? И собирать отвалившиеся не надо, все само работает? Вы правда верите что без приглядывания это всегда будет работать? И вы тчоно уверены, что тот кто нос воротит от эскуэль процедур, нормально пишет java код? Язык имеет настолько большое значение? Юнит тесты прекрасно пишутся, миграция тоже возможна при помоши уже почти стандартных подходов (например в рамках java: flyway, liquibase).
И пожалуйста не путайте героическое преодолевание трудностей, с решениями созданными для высокой нагрузки. Я не против двух-томкетов, ноуэскуля, или другой фигни. Но где в вашем опусе мысль, что надо проанализировать ситуацию, прежде чем принимать решения. Тем более если вы претендуете на сеньора, то вы должны не просто предлагать что-то, но объяснять почему вы это предлагает, и чем это грозит.
> В: Допустим, у вас есть приложение (самое обычное — JSP, Spring, Hibernate например) развернутое на томкате (Apache Tomcat) и вы однажды замечаете что сервер с томкатом загружен на 80% в среднем. Что делать?
В первую очередь понять, почему мы загружены на 80%. Побенчмаркать цифры на реальном продакшене. А после этого предлагать решения. И кстати не факт, что два томкета будут быстрее. Вдруг проблема в БД. Или даже приложение написано так, что не может быть развернуто на двух томкетах. В общем в первую очередь понять почему, что можно с этим сделать, и сколько это будет стоить (в том числе последствия).
> В: Но как же пользователь будет заходить на ваши несколько серверов?
Про это надо было сразу сказать, когда описывалась «архитектура с двумя томкетами». Картинку там нарисовать от руки. Странный вопрос.
> В: Но ведь может получиться что пользователь залогиниться на одном томкате, а следующий запрос load-balancer пошлёт на другой, где пользователь не залогинен!
А собственно почему сразу про липкие сессии? Разве не надо рассказать, что при этом будет для начала? Что сессия живет по умолчанию только на одном томкете. Хотя опять же про это можно сразу рассказать в «архитектура с двумя томкетами». И самое главное, почему вы не говорите про то, что можно не хранить в сессии ничего. А поднимать все сессионные данные из внешнего хранилища (мемкеш или бд какая).
> В: А если этот конкретный сервер упадёт?
Ну упадет сервер, да и ладно. Но если вы храните в сессии толстые объекты, то не факт что кеш вас спасет. Сериализация не для всех работает из коробки. Вот вы всегда проверяете что объект может быть сериализован, когда пишете приложение? А если это объект из сторонней скомпилированной библиотеки?
> В: Какие ещё преимущества у кэша для сессий?
А где самый главный вопрос про недостатки? По мне, так преимуществ от кеша сессий почти нет, лишь лишняя сущность для понимания работы системы. И вы точно уверенны, что стратегия бета-тестирования имеет прямое отношение к преимуществам кеша сессий?
> В: Хорошо, теперь у нас узким местом становится база. Что мы будем делать при возрастании нагрузки на неё?
Почему все время архитектурные решения? Вы боитесь читать код? Вот почему бы не проанализировать построение запросов? Да, кеш хибернейта сделать чуть лучше, но ведь есть еще и фетчи связанных данных (на случай если все лениво инициализированно). Может быть слой хранения мигрировать c hibernate на jdbc? В общем, в первую очередь надо понять какую проблему мы имеем, как ее можно решить, и сколько это будет стоить.
> В: А какие есть другие пути? Какие решения на уровне самой базы данных?
А как же хранимые процедуры, прекомпиленные вью, временные таблицы, ну или наконец банальные индексы? Почему мы сразу в бой? Ведь расфигачивание БД по разным машинкам это всегда дорого.
p/s надо не боятся читать и понимать код, а также иметь представление к чему приведет его выполнение. А все эти шардирования-кеши-ноэскуэли-архитектуры, придуманы маркетоидами, и перед их использование надо хорошо подумать. Раз семь, минимум!
Я имел ввиду, что ничего не меняется с точки зрения компаний и рынка. Нельзя некоторых людей исправить, надо лишь дождаться пока они вымрут. Вот про это я хотел намекнуть.
p/s То что меняется восприятие продавца себя это априори. Как я уже намекал выше, я имел опыт с некоторыми компаниями. В том числе имел опыт манипуляции эмоциями, через угрозы жизни.
Ничего не меняется, я тоже так собеседуюсь, ибо терпеть не могу менять работу по случайности какой. Но все равно есть компании, которым не понимают зачем я задаю им свои вопросы.
Пара компаний меня больше месяца мариновали так, я все понимал, и только ради опыта продолжал с ними общение (чтобы отсекать потом таких сразу).
Ну организовать раздолбайство это тоже не просто, чтобы оно жило и особо не вредило :)
Мне кажется плохо разделять время и усилия. Хождение на встречи это усилие, особенно для интровертов/социопатов. Еще плохо делить, потому что время и усилия взаимосвязанны. Одно без другого не бывает. Вот их соотношение может меняться, но стоит ли оценивать это? Не стоит ли оценку этого соотношения вынести в отдельную активность?
Спасибо за видео, вроде все логично, и до всего можно додуматься самому, но тут собрано в одном месте, и это хорошо — stratoplan.ru/ngt/nuzhda.html
Я тут подумал, собеседование в компанию это ведь тоже манипуляция:
* Просят заполнить резюме по своей форме — трата времени и энергии
* Просят сделать тестовое задание — трата времени и энергии
* Просят несколько раз приехать в офис — трата времени и энергии
* Обещают премии квартальные/годовые/проектные если будешь хорошо работать — обещание денег без конкретики
* Ожидание собеседующих или заполнение опросника — трата времени и энергии
* Обещание повышения зарплаты/должности после испытательного — обещание денег без конкретики
* Рассказ о лидере рынка и крупных заказчиках — манипуляция эмоциями
* Очень умные вопросы из книжек и троллинг от собеседующих — манипуляция эмоциями
* Компания сообщает ответ не сразу — манипуляция эмоциями
* Компания не отвечает неподходящим кандидатам или отвечает через месяц-два — манипуляция эмоциями (создание фона элитарности)
* На собеседовании спрашивается уровень дохода на прошлом месте — манипуляция эмоциями (если кандидат подходит, то можно предложить всего на 5-10% больше)
* С вами хочет поговорить наш генеральный директор — манипуляция эмоциями
* Наш самы главный вождь занят переговорами с очень крупной компанией, он с вами поговорит только через неделю — манипуляция эмоциями
И вот вопрос возникает: в чем разница между временем и энергией? Стоит ли их делить? В чем от этого профит?
Прискорбно, что тезисы на отдельной странице, не все будут читать много букв. Потому попсовые слова в названиях докладов будут решать. А в целом спасибо за инициативу, я вот на работе уже несколько человек уговорил пойти :)
Мне кажется в консерватории есть проблема. Исходный код это очень личная штука, и тащить туда всякую гадость, да еще транзитивно, это рак мозга.
Каждый раз, когда добавляется новая зависимость, надо думать, что она принесет в проект. К слову сказать, не все транзитивные зависимости нужны в проекте.
К сожалению, люди разрабатывающие библиотеки и выкладывающие их в репозитории, сами имеют грешок с каками в зависимостях. Я уж молчу про обычные проекты, которые их используют. Задолбался на каждом новом проекте вычищать бардак.
В итоге побойтесь бога, не добавляете бездумно всякую каку и фигачьте побольше эксклудов. Серебряной пули нет.
4. Делаю кошерный работающий скрипт и использую БД postgresql где есть транзакции в DDL — wiki.postgresql.org/wiki/Transactional_DDL_in_PostgreSQL:_A_Competitive_Analysis
5. Согласен идея с путями не очень, я бы предпочел внутренние идентификаторы ченджсетов. А чексуммы это отдельный ад, нафиг их.
Дополнения:
1. Вы до сих пор верите в волшебные свойства библиотек? У вас всегда работает правильно конвертация xml в sql скрипт? Вам не надо на горячую писать упдейты, а потом вписывать их в ченджсеты? Опять я вам завидую :)
4. Я так и не дошел реального использования флайдб. Вроде бы у них роллбеков не было, и это немного печалило. Хотя есть надежда что там код и реализация, не такое гавно как в ликвидбейзе.
Итак:
1. Порядок в именовании файлов с ченджсетами это очень хорошо, как в прочем любой порядок. Возможно в имени ченджсета стоит отражать тип БД для которого он писан.
2. Ролбеки для ченджсетов это полезно и клево, но не стоит забывать, что надо вручную тестировать выполнения ченджсета и его откат, это обязательно!
3. В целом маленькие ченджсеты это опять про порядок в их структуре. Но есть нюансы, о них ниже.
4. Вам действительно не жаль своего времени для каждой сущности писать ченджсет? Я вам не завидую!
5. Я предпочитаю помещать ченджсеты в класспатх, и брать их относительно корня класспатх. Тога мы перестаем зависеть от операционных систем и других странностей.
6. Менять прошлое не всегда хорошая идея. В большинстве случаев надо делать отдельный ченджсет. Но тут не все так просто.
7. Согласен хранить данные в ченджсетах не очень разумная идея. Они приводят к увеличению объема ченджсетов, ну и не стоит забывать что миграции ведь для них тоже придется писать.
8. Пункт тоже логичен. Никому верить нельзя.
9. Я бы дополнил пункт, и сказал что XML ченджсеты зло, возможно хуже чем DSL. И SQL тут самое то. Удобно, быстро, прозрачно.
10. Опыт конечно хорошо, но вы бы видели исходный код liquibase. Например логер туда впилить весело :)
И в дополнении:
1. Может быть xml описание зло? Вас действительно не напрягает это писать и поддерживать? Просто я сторонник обычного нативного sql.
2. Иногда полезно делать ченджсет со всей структурой БД, куча маленьких на новой БД применяется не быстро порой. И опять я намекаю на sql ченджсеты тут.
3. Чем больше размер sql ченджсета, тем дольше считается контрольная сумма. Это еще одна из причин почему хранить данные в ченджсетах зло. Помню мегабайт текста обрабатывался за секунд 20.
4. Есть аналоги, и надо думать и пробовать что лучше. Например flyway — flywaydb.org/ (там есть таблица сравнения на подумать).
Часто учат других чтобы самому понять тему. Но тут главное не скатится в самоуслаждения себя что приведенная точка зрения это истина. Потому не стоит искать причины, надо искать конкретную одну причину для конкретного человека.
Я вот думаю что истинная причина прокрастинации в том, что мы пытаемся следовать своеобразной моде. В итоге то что мы хотим делать, на самом деле хотят другие. Открытость и прозрачность современного общества способствуют этому. И мы упорно продолжаем жрать кактус и заставляем себя делать всякую хрень.
«И что человечество попросило тебя на этот раз? Вселенную! Хм, Надеюсь когда нибудь они созреют, и захотят не какую нибудь ерунду! » Вольный пересказ одного рассказа Харлана Эллисона.
В итоге сейчас есть две касты наемного персонала. Первые типичные наемники и меняют работу за любую интересную прибавку. Вторые готовы почти на все, ради своего интереса в работе. И не надо подводить все советы под обе эти касты, кесарю кесарево.
Про первых я ничего не скажу. А вот по поводу вторых, не работает у них нормально подход — пообещал-повысили. Человек должен сразу мочь и хотеть делать больше. К примеру у меня была одна история из жизни. Пришел я ко второму своему клевому начальнику, и сказал что год-прошел-инфляция-мое-понимание-бизнес-процессов-выросло-да-и-вообще-я-ого-го. А он мне на 3% всего прибавку дал. Я конечно обиделся, но тут подвернулся клевый проект, и я в нем погряз, забыв про обиды-деньги. В общем мне через два месяца дали премию в размере зряплаты. И потом стали так каждый квартал делать. То есть если бы я просто не попросил без всякий непонятных обещайний стать-лучше/взять-больше, то мне бы и не дали скорее всего. У айтишников очень плохо с чтением мыслей. Надо уметь говорить честно, когда что-то не нравится. И не надо при рассказывать небылицы и обещать всякую ересь. Можешь делай сразу!
Да и трясти офером перед начальством это тоже гнилая затея. Сколько раз такой шантаж будет работать? Почему офер от другой компании должен быть объективен? Может у меня там друг нарисовал на бумажке удобные цифры? Но вот ходить на собеседования полезно, понимаешь рынок и себя при этом. Обретаешь уверенность/наглость просить больше. Ну а если не дадут, то значит тебя и не ценят в этой компании. А если не ценят, то значит твоя работа особо никому не нужна. Может быть причина в том, что не нужен твой опыт, для такой работы. Есть правило: не повысили за год — ты возможно не нужен (работай над собой или уходи), повысили в рамках инфляции — ты нужен (может быть это потолок уже, или ты недостаточно хорош), повысили больше чем на уровень инфляции — ты очень нужен (надо продолжать жечь в том же духе).
Резюме — будь полезен, работай над собой и не шантажируй начальство. Умей честно говорить о проблемах и немного ждать. Если дело швах, то уходи.
p/s ну а если после ухода, в старой компании появляется вакансия +xx% к окладу, то это намек, что нужен другой человек. А не закостенелый страрожила рабочего места.
Иногда дешевле, иногда дороже, все зависит от ситуации. А кстати репликацию настраивать не надо? И собирать отвалившиеся не надо, все само работает? Вы правда верите что без приглядывания это всегда будет работать? И вы тчоно уверены, что тот кто нос воротит от эскуэль процедур, нормально пишет java код? Язык имеет настолько большое значение? Юнит тесты прекрасно пишутся, миграция тоже возможна при помоши уже почти стандартных подходов (например в рамках java: flyway, liquibase).
И пожалуйста не путайте героическое преодолевание трудностей, с решениями созданными для высокой нагрузки. Я не против двух-томкетов, ноуэскуля, или другой фигни. Но где в вашем опусе мысль, что надо проанализировать ситуацию, прежде чем принимать решения. Тем более если вы претендуете на сеньора, то вы должны не просто предлагать что-то, но объяснять почему вы это предлагает, и чем это грозит.
В первую очередь понять, почему мы загружены на 80%. Побенчмаркать цифры на реальном продакшене. А после этого предлагать решения. И кстати не факт, что два томкета будут быстрее. Вдруг проблема в БД. Или даже приложение написано так, что не может быть развернуто на двух томкетах. В общем в первую очередь понять почему, что можно с этим сделать, и сколько это будет стоить (в том числе последствия).
> В: Но как же пользователь будет заходить на ваши несколько серверов?
Про это надо было сразу сказать, когда описывалась «архитектура с двумя томкетами». Картинку там нарисовать от руки. Странный вопрос.
> В: Но ведь может получиться что пользователь залогиниться на одном томкате, а следующий запрос load-balancer пошлёт на другой, где пользователь не залогинен!
А собственно почему сразу про липкие сессии? Разве не надо рассказать, что при этом будет для начала? Что сессия живет по умолчанию только на одном томкете. Хотя опять же про это можно сразу рассказать в «архитектура с двумя томкетами». И самое главное, почему вы не говорите про то, что можно не хранить в сессии ничего. А поднимать все сессионные данные из внешнего хранилища (мемкеш или бд какая).
> В: А если этот конкретный сервер упадёт?
Ну упадет сервер, да и ладно. Но если вы храните в сессии толстые объекты, то не факт что кеш вас спасет. Сериализация не для всех работает из коробки. Вот вы всегда проверяете что объект может быть сериализован, когда пишете приложение? А если это объект из сторонней скомпилированной библиотеки?
> В: Какие ещё преимущества у кэша для сессий?
А где самый главный вопрос про недостатки? По мне, так преимуществ от кеша сессий почти нет, лишь лишняя сущность для понимания работы системы. И вы точно уверенны, что стратегия бета-тестирования имеет прямое отношение к преимуществам кеша сессий?
> В: Хорошо, теперь у нас узким местом становится база. Что мы будем делать при возрастании нагрузки на неё?
Почему все время архитектурные решения? Вы боитесь читать код? Вот почему бы не проанализировать построение запросов? Да, кеш хибернейта сделать чуть лучше, но ведь есть еще и фетчи связанных данных (на случай если все лениво инициализированно). Может быть слой хранения мигрировать c hibernate на jdbc? В общем, в первую очередь надо понять какую проблему мы имеем, как ее можно решить, и сколько это будет стоить.
> В: А какие есть другие пути? Какие решения на уровне самой базы данных?
А как же хранимые процедуры, прекомпиленные вью, временные таблицы, ну или наконец банальные индексы? Почему мы сразу в бой? Ведь расфигачивание БД по разным машинкам это всегда дорого.
p/s надо не боятся читать и понимать код, а также иметь представление к чему приведет его выполнение. А все эти шардирования-кеши-ноэскуэли-архитектуры, придуманы маркетоидами, и перед их использование надо хорошо подумать. Раз семь, минимум!
p/s То что меняется восприятие продавца себя это априори. Как я уже намекал выше, я имел опыт с некоторыми компаниями. В том числе имел опыт манипуляции эмоциями, через угрозы жизни.
Пара компаний меня больше месяца мариновали так, я все понимал, и только ради опыта продолжал с ними общение (чтобы отсекать потом таких сразу).
Мне кажется плохо разделять время и усилия. Хождение на встречи это усилие, особенно для интровертов/социопатов. Еще плохо делить, потому что время и усилия взаимосвязанны. Одно без другого не бывает. Вот их соотношение может меняться, но стоит ли оценивать это? Не стоит ли оценку этого соотношения вынести в отдельную активность?
Я тут подумал, собеседование в компанию это ведь тоже манипуляция:
* Просят заполнить резюме по своей форме — трата времени и энергии
* Просят сделать тестовое задание — трата времени и энергии
* Просят несколько раз приехать в офис — трата времени и энергии
* Обещают премии квартальные/годовые/проектные если будешь хорошо работать — обещание денег без конкретики
* Ожидание собеседующих или заполнение опросника — трата времени и энергии
* Обещание повышения зарплаты/должности после испытательного — обещание денег без конкретики
* Рассказ о лидере рынка и крупных заказчиках — манипуляция эмоциями
* Очень умные вопросы из книжек и троллинг от собеседующих — манипуляция эмоциями
* Компания сообщает ответ не сразу — манипуляция эмоциями
* Компания не отвечает неподходящим кандидатам или отвечает через месяц-два — манипуляция эмоциями (создание фона элитарности)
* На собеседовании спрашивается уровень дохода на прошлом месте — манипуляция эмоциями (если кандидат подходит, то можно предложить всего на 5-10% больше)
* С вами хочет поговорить наш генеральный директор — манипуляция эмоциями
* Наш самы главный вождь занят переговорами с очень крупной компанией, он с вами поговорит только через неделю — манипуляция эмоциями
И вот вопрос возникает: в чем разница между временем и энергией? Стоит ли их делить? В чем от этого профит?
p/s
А продаете вы субботу презабавно, вот только у детей и жены отпрошусь :)
Каждый раз, когда добавляется новая зависимость, надо думать, что она принесет в проект. К слову сказать, не все транзитивные зависимости нужны в проекте.
К сожалению, люди разрабатывающие библиотеки и выкладывающие их в репозитории, сами имеют грешок с каками в зависимостях. Я уж молчу про обычные проекты, которые их используют. Задолбался на каждом новом проекте вычищать бардак.
В итоге побойтесь бога, не добавляете бездумно всякую каку и фигачьте побольше эксклудов. Серебряной пули нет.
5. Согласен идея с путями не очень, я бы предпочел внутренние идентификаторы ченджсетов. А чексуммы это отдельный ад, нафиг их.
Дополнения:
1. Вы до сих пор верите в волшебные свойства библиотек? У вас всегда работает правильно конвертация xml в sql скрипт? Вам не надо на горячую писать упдейты, а потом вписывать их в ченджсеты? Опять я вам завидую :)
4. Я так и не дошел реального использования флайдб. Вроде бы у них роллбеков не было, и это немного печалило. Хотя есть надежда что там код и реализация, не такое гавно как в ликвидбейзе.
Итак:
1. Порядок в именовании файлов с ченджсетами это очень хорошо, как в прочем любой порядок. Возможно в имени ченджсета стоит отражать тип БД для которого он писан.
2. Ролбеки для ченджсетов это полезно и клево, но не стоит забывать, что надо вручную тестировать выполнения ченджсета и его откат, это обязательно!
3. В целом маленькие ченджсеты это опять про порядок в их структуре. Но есть нюансы, о них ниже.
4. Вам действительно не жаль своего времени для каждой сущности писать ченджсет? Я вам не завидую!
5. Я предпочитаю помещать ченджсеты в класспатх, и брать их относительно корня класспатх. Тога мы перестаем зависеть от операционных систем и других странностей.
6. Менять прошлое не всегда хорошая идея. В большинстве случаев надо делать отдельный ченджсет. Но тут не все так просто.
7. Согласен хранить данные в ченджсетах не очень разумная идея. Они приводят к увеличению объема ченджсетов, ну и не стоит забывать что миграции ведь для них тоже придется писать.
8. Пункт тоже логичен. Никому верить нельзя.
9. Я бы дополнил пункт, и сказал что XML ченджсеты зло, возможно хуже чем DSL. И SQL тут самое то. Удобно, быстро, прозрачно.
10. Опыт конечно хорошо, но вы бы видели исходный код liquibase. Например логер туда впилить весело :)
И в дополнении:
1. Может быть xml описание зло? Вас действительно не напрягает это писать и поддерживать? Просто я сторонник обычного нативного sql.
2. Иногда полезно делать ченджсет со всей структурой БД, куча маленьких на новой БД применяется не быстро порой. И опять я намекаю на sql ченджсеты тут.
3. Чем больше размер sql ченджсета, тем дольше считается контрольная сумма. Это еще одна из причин почему хранить данные в ченджсетах зло. Помню мегабайт текста обрабатывался за секунд 20.
4. Есть аналоги, и надо думать и пробовать что лучше. Например flyway — flywaydb.org/ (там есть таблица сравнения на подумать).
Я вот думаю что истинная причина прокрастинации в том, что мы пытаемся следовать своеобразной моде. В итоге то что мы хотим делать, на самом деле хотят другие. Открытость и прозрачность современного общества способствуют этому. И мы упорно продолжаем жрать кактус и заставляем себя делать всякую хрень.
«И что человечество попросило тебя на этот раз? Вселенную! Хм, Надеюсь когда нибудь они созреют, и захотят не какую нибудь ерунду! » Вольный пересказ одного рассказа Харлана Эллисона.