Petro123Как вариант - ErWin

И что твой ERWin? В течение недели в схеме модели данных от 10 до 50 изменений, всё это должно работать нон-стоп. Это реальная корпоративная система с охватом по все России, люди работают из разных часовых поясов, некоторые по ночам херачат, планы сдают. Покажи, куда ты свою игрушку ERWIN воткнёшь?

Petro123hVosttДБА это пережиток )
))
Мы о корпоративе Ынтырпрайзе или о чём девочки?

Если ссылаться на древние книги 80-годов о том, как должен выглядеть Enterprise, то может и нет.

Petro123,

Помню в 2007 году мы на ERWIN делали полностью схему базы данных: физическая модель, логическая модель, нормализовано всё по феншую прям, Domain, User Defined Property напичкано. Потом натравливали генератор Code Smith, чтобы сгенерировать модели данных, адаптеры на BLToolKit и представления для всех таблиц: CRUD на HTML+JavaScript+ASP.NET 2.0 (без использования web forms, только XML). И получали полностью годное приложение. Потом допиливали ручками.

Щас такая радость уже нафиг никому не нужна. Нужно всё делать на лету, чтобы сел аналитик со своими методичками и через пару часов уже QA тыкает новые формы, проверяя логику, отчёты, виджеты, с привлечением фокус-группы заказчика.

Petro123hVostt,
Слухи о смерти DB First сильно преувеличны).
Удачи.

Пока не вижу аргументов в защиту DB First.
Если ты основываешься на слухах и что там на каком-то форуме Java говорят, то эт печально.
Вроде как получается, что тебе просто хочется думать вот так, но понятия не имеешь почему

Dima T,

При чём тут Code First?
И с Dapper у нас БД тоже создаётся в рантайме на основе мета-модели из событий.
Никакого DB first нет, просто EF не предназначен для динамики.
Хорошая попытка, но нет :)

Dima TDapper лекговесная читалка, чуть медленнее SqlCommand.ExecuteReader(), но намного удобнее. Он даже под insert/update толком не заточен, а ты говоришь про динамическое изменение структуры БД. Это и есть "БД First", ты строишь свой софт под возможности БД.

БД first, это ты идёшь и ручками свою базу изменяешь. Потом топаешь в код и напильником дорабатываешь код, чтобы он понимал твою базу. Мы ручками в БД не лазим и ничего не изменяем. Никто не выполняет ни одной DDL операции вручную. Что касается Dapper, то да, согласен. Но это ничего не отменяет.

Petro123Угу.
Давай ты мне не будешь верить, а я тебе что "DBA у заказчиков нет" ).

Ну хочешь, верь. Мне одной веры мало :)

Petro123Ещё один новый термин на сегодня.
Я знаю одну супер Мета-модель. EAV называется.
Она тоже любую модель переводит в 3 таблички))).

Ты удивишься, но копнув чуть глубже, любая современная реляционная СУБД это по сути EAV.
И что теперь?

Petro123Т.е. сводим базу бухгалтерию и базу банковскую в одну Модель.
События у вас для истории транзакций?

Нет, не сводим. У нас полноценный DDD и Bounded Context.
События это любые изменения. Транзакции у нас выполнены по технологии распределённых транзакций с собственной реализацией, это необходимо, так как у нас микро-сервисная архитектура.

Petro123Или смены сущности User на сущность Платёжка?

Это невозможно. Есть агрегат User, есть агрегат Платёжка. Нельзя «сменить тип». Можно попробовать сконвертировать один агрегат в другой, и мы получим совершенно другой объект.

Petro123Какое отношение события имеют к Модели?

Прямое. Все события — это операции над агрегатами. Есть бизнес-агрегаты, есть системные агрегаты. Одна из системных агрегатов это модель SQL базы данных, поэтому миграция это просто такое событие.

Petro123Если БЛ в ОРМ хибернайт, то в маппинге добавляем.

Есть на поддержке проекты на NHibernate, всё тож самое.

Petro123нет.
При EAV СУБД - импотент. Он понятия не имеет что лежит в табличках.
Т.е. нет НЕпротиворечивости модели.





Откуда БД знает, что где лежит?

Petro123изменения чего? Данных в модели? Тогда забудь это слово вообще. Что оно путается тут?
Ты ещё логирование вспомни.

А чёб не вспомнить. Это по сути лог, да. Только лог функциональный, от него всё пляшет.


Petro123Вот это впервые слышу. Надо будет вникнуть.

Не стоит. :)
Лучш настраивай маппинги в хибере и ковыряй базу ручками