Monochromatique,

гораздо интереснее вопрос, как пользоваться EF-миграциями при разработке в команде

ЕвгенийВhVosttMonochromatique,

гораздо интереснее вопрос, как пользоваться EF-миграциями при разработке в команде
А в чем проблема?

пока не попробуешь, не узнаешь

ЕвгенийВhVosttпока не попробуешь, не узнаешь
Пробовал, никаких проблем.
Если не считать того факта, что структуру БД ваяют тупые и убогие императивщики, а должны божественные базаданщики!

Если в команде 2 девелопара делают по миграции из одной и той же версии (развернутой у них локально), то потом такие миграции не встанут. Точнее встанет только одна, кто первый тот и папа. Второму придётся делать дополнительные манипуляции.

ЕвгенийВhVosttЕсли в команде 2 девелопара делают по миграции из одной и той же версии (развернутой у них локально), то потом такие миграции не встанут. Точнее встанет только одна, кто первый тот и папа. Второму придётся делать дополнительные манипуляции.
ХЗ.
Участвовал в одном провальном проекте, так там эти миграции именовались как то от номера спринта (или как его там) + текущая дата до секунды. Никаких проблем с вставанием миграций не возникало...

Ээммм... секунды тут не при чём, миграция основывается на конкретной предыдущей миграции. Я не в курсе какие у вас там были миграции, но Entity Framework хрен даст тебе сунуть свою миграцию, если кто-то постарался и успел сунуть свою. Не имеет значения ни номер спринта, ни дата до секунды, -- и это очень правильно.

Сама миграция стряпается на основе изменений, которые ты сделал и текущего состояния СУБД. Если же текущее состояние неизвестно (кто знает какие изменения нахреначили другие участники команды за один и тот же этап??), то невозможно сделать правильную миграцию.

ЕвгенийВhVostt,
А понятно. БД одна общая на всех?
У нас были отдельные локальные БД у каждого и каждый раз когда нужно было накатить, в БД все грохалось и начинало накатываться сначала, последовательно по номерам миграций.

Это тоже не имеет значения. Такой подход как ты говоришь будет работать только, если каждый разработчик делает изменения, никак не связанные с изменениями других людей.

Например, я переименовываю поле, а ты добавляешь это поле в индекс. Если твоя миграция пойдёт первой, то всё будет ок, а если наоборот, твоя сломается. И это самый простой случай. Часто миграции не только DDL, но ещё и с изменениями самих данных, тут вообще можно так накосячить, что не сразу об этом узнаешь. Именно поэтому не связанные друг с другом миграции -- зло, и не допустимо. ЧТобы пропихнуть свою миграцию, ты должен вытащить все имеющиеся, и получив актуальное состояние, сунуть свою. И так у каждого разработчика. Не важно общая БД или у каждого локальная, разницы никакой. Для EF имеются такие практики, как последовательная заливка своих миграций, с прогоном по общей базе в TeamCity, с тестами и прочим.

ЕвгенийВБазаданщик сделает хранимую процедуру.

В лес таких базаданщиков. Если он не собирается написать хранимку сразу под все популярные СУБД и потом успешно поддерживать их.

ЕвгенийВСколько коммерчески успешных ПП реализованы под несколько СУБД?

3 шт. на моём личном счету (крупные enterprise проекты, в которых я принимал непосредственное участие), продаются и приносят прибыль. Никаких проблем, при отказе от хранимок профит для разработки ощущается натурально. Да, я хочу сказать, что без хранимок и без привязки к конкретной вендорной СУБД можно создавать крупные и коммерчески успешные проекты.

skyANAБожественный дб-шник в один прекрасный день берёт и сокращет количество запросов к БД в десятки раз :)

авторПри этом функциональность системы не меняется.


Эммм.. как это? Типа система делала для одного действия 10 запросов, но приходит кто-то и 10 превращается в 1... какая в этом заслуга дбшника, если это система делает запросы?

skyANAНу если подходить с позиции, что СИСТЕМА делает запросы, а не императивщики так реализовали функционал...

Аа.. типа дбашник говорит как тупым императивщикам вместо 10 запросов получить тоже самое, но одним?


skyANAСистема сама решает, какой функционал нужен, сама пишет код... Система делает всё сама :)

Ну чего ты передёргиваешь

skyANAНет, тупо код рефакторит, а нагрузочные тесты показывают, что производительность возросла.

Мы же про такого дбшника как ЕвгенийВ, он жеж и на C# код пишет.

Ну не единым кодом же.. я грешным делам подумал про волшебника дбашника которому не надо в код лезть, то ли дело под взмахами волшебной палки SQL, всё начинается несказанно шевелится

ЕвгенийВhVosttНу не единым кодом же.. я грешным делам подумал про волшебника дбашника которому не надо в код лезть, то ли дело под взмахами волшебной палки SQL, всё начинается несказанно шевелится
Можно в код и не лезть. На тот случай есть профайлеры, планы исполнения, индексы и статистики, нужные служебные вьюшки и сохраненные процедуры и пакетами. Если руки откуда надо растут, то их ничего не связывает.

Есть 2 суперпозиции:

1. Стараться сразу писать хорошо (чтобы потом бесконечно не рефакторить и не поддерживать легаси)
2. Не заниматься оптимизацией без реальной необходимости

Это как бухгалтеру, успешно решавшему свои задачи в 1С на стареньком целероне, заменили комп с 40-ядерным процессором и 4 топовых видюхи в SLi -- и.. для бухглатера ничего не поменялось.

skyANAИ к чему ты это сказал, капитан Очевидность? :)

Подвёл итоге тксказать ))

ЕвгенийВВот прямо передо мной сидит бухгалтер, которая периодически кроет иwʁʎх хорошими словами 1С, потому как нужно распечатать бумагу и идти в кассу выдавать бабки, а эта прекрасная программа тупо висит.

колокейшен? ))
отправьте бухгалтера в отпуск уже!

MonochromatiquehVostt,

Видел уже?

Читал столет назад в оригинале ))

ViPRosвсе это на уровне каменного века, никаких семантических изысков

Семантика оказалась вообще-то переоценена. Семантический веб вона лишь прибавил работы и не дал взамен ничего, как стерва-жена с силикатными буферами

Иммануил Кантпо-моему эта статья весь пипец командных миграций не покрывает. она его просто обозначает

командные миграции по своей сути проблемны и ни какая технология этого исправить не может. база данных это не гит.

ViPRosразве гит дает возможность реальной совместной работы?

с одной веткой работает десяток человек -- никто не жалуется. сказать, что проблем совсем нет нельзя, но они решаются грамотным менеджментом, git-flow, несложными гайдами и регламентами.

что касается миграций, всегда важен порядок их применения, соответственно этот порядок надо специально согласовывать. работает принцип — кто первый, тот и папа.