EF Core. scaffold-dbcontext. DBFirst
Или прямо каждый второй - Гугл и у них миллионы записей в таблицах и сотни тысяч транзакций каждый день?
Ага. Гугол. Сотни тысяч каждый день... А сотни тысяч каждый час месье не желает? Для магазина "машины носочки" Code First отличное решение. Для страховки/банка/сети магазинов - убийственная тупость. Даже с поверхностными знаниями SQL и конкретной RDBMS можно превзойти результаты code first на порядки.
Из личного опыта: ускорение чтения более чем в 600 раз. Вместо 10-15 минут до 0.5 - 1.5 секунд. Просто убрали сложный ключ (заменили интом) и сэкономили пару десятков джойнов (добавили триггер, копирующий PK созданной записи в одну табличку).
А проблема, из-за которой я Code First ненавижу, аж кушать не могу, в том, что частенько проект начинается как "машины носочки" а через два года "класс! а теперь выкатываем это в продакшен для 10.000 филиалов! Что значит работать не будет? Что значит проще переписать заново чем доработать?" Я уже не знаю с каким количеством проектов я так мучался.
не обязательно быть Гуглом, чтобы насобирать за год 100500 миллионов строк мусора.
там уже не до розовых соплей, там берётся за дело 59-летний коллега и изучает Execution plan.
Ну т.е. не меня и какого-нибудь другого джуниора-миддла запрягают? А то на некоторых собесах так спрашивают, будто джуны им в одно рыло Гугл поднимают. Т.е. берём и делаем базу на EF Code First, а когда припрёт, зовём пенсионера, чтобы процедурок-триггеров нам в базу накидал? Reicht?
Ага. Гугол. Сотни тысяч каждый день... А сотни тысяч каждый час месье не желает? Для магазина "машины носочки" Code First отличное решение. Для страховки/банка/сети магазинов - убийственная тупость. Даже с поверхностными знаниями SQL и конкретной RDBMS можно превзойти результаты code first на порядки.
Ребята-ребята! Code First - это для программиста по-быстрому БД накидать, и заодно чтобы скрипт создания БД не писать на SQL. Ваш DBA не знает C# скорее всего, так что ему ни Code First, ни Database First не сдался - это вообще не для него. Если вы делаете второй Гугол или Дойчебанк там, то явно не вешаете все задачи на одного программиста, а имеете целую команду DBA и прочих специалистов, так что программист не лезет в создание и управление базами данных, а DBA - в код приложений, так? Тогда спора нет - нафиг этот Code First не сдался.
What is Code-First?Entity Framework introduced the Code-First approach with Entity Framework 4.1. Code-First is mainly useful in Domain Driven Design.
What is Code-First? (entityframeworktutorial.net)
Кстати, ASP.NET MVC уже устарел (все версии) - теперь рулит Razor Pages (синяя плашка по ссылке Tutorial: Get Started with Entity Framework 6 Code First using MVC 5 | Microsoft Docs).
а через два года "класс! а теперь выкатываем это в продакшен для 10.000 филиалов! Что значит работать не будет? Что значит проще переписать заново чем доработать?" Я уже не знаю с каким количеством проектов я так мучался.
Нормальный подход. Или вам нравится вечно со старым дерьмом работать? Нужно же думать заранее, чем вы через два года заниматься будете. ))
Один раз ради интереса попробовал и больше не смог.
Ну удобнее c ER дизайнером работать. Все база видна, нет зависимости от используемой версии EF, и генериш что надо.
Только в подходе "сначала код" ты должен разбираться лишь в сишарпе (ну и немного в конвенциях EF), а в подходе "сначала база" вы должны быть виртуозом графического дизайнера БД. Так недалеко и до Visual programming language - Wikipedia опуститься. Просто вам непривычно, потому что вы с графического дизайнера начинали.
Или прямо каждый второй
-----
Данные имеют свойство накапливаться.
Причем - довольно быстро.
Той базе, которую Я делал для системы импорта, проблемы производительности появились уже на второй год эксплуатации.
Решение проблемы известно - нужно добавлять индекс по паре полей...
сотни тысяч транзакций каждый день?
-----
Импорт 20-30 документов в день...
Документы в базе не хранятся - хранится только (подготавливаемые однажды) "значения по умолчанию" для каждого клиента и типа обработки. Клиентов - десятка два, обработок - потенциально 9999, используется много меньше.
Итого - 20.000 записей начинают генерировать проблемы производительности.
Нормальный подход. Или вам нравится вечно со старым дерьмом работать? Нужно же думать заранее, чем вы через два года заниматься будете. ))
А попробуйте угадать - сколько раз разрешили переписать заново? Из .... ну пусть для удобства будет 10 проектов.
Все база видна
-----
А это - плохо.
Как прикладник ты базу должен видеть только в том виде в каком ее тебе даст ДБА.
С дугой стороны - когда контора мучает хомяка по паре недель на страничку обучение персонала написанию 80-90% тестируемого кода путем глядения только в схему базы дает существенный прирост общей производительности...
чтобы процедурок-триггеров нам в базу накидал?
-----
А оно решит проблему?
Выше же уже написано - Что значит проще переписать?
Был такой маленький кусочек - планировщик смен.
Ничего страшного - пара-другая табличек - когда, от скольки до скольки работаем, выкинуть выходные, отработать выходной как исключение и т.п...
Такой маленький самопальный планировщик с кучей неправильных записей, с совершенно неправильными расчетами и кучей глупостей типа вот мы всю маленькую таблицу поднимем и потом выберем что нам надо, а тут поменяем и потом вернем...
Так Я его не смог заменить - им пользовалось 2 Гб спагетти-кода... где-то, как-то что-то вынималлось, как-то обсчитывалось, каждый раз это делалось по-другому т.к. в конкретном месте нужен был "не такой" результат и получить его можно было только обработав имеющиеся ошибки определенным способом...
Чтобы его заменить - надо переработать все 2 Гб спагетти...
потому что вы с
-----
Для умных: мне без разницы что использовать код- или - база- первым.
Но так как Я знаю об базах немного больше чем знает знает пользователь код-первым, то мне видно что именно эта технология не позволяет мне сделать с базой. Того что она не позволяет делать из того что Я знаю и могу использовать следует однозначный вывод - база-первая.
Если не все еще не понятно - напиши представление... хммм... обычного адреса... т.е. как обычно - фамилия имя отчество, страна, город, улица, дом, квартира, почтовый индекс... пыхх... чего там еще... аааа... у нас в Ирландии не всегда есть город и улица, но есть графство - используются имена собственные для домов... ну еще нюансы в других странах... и уложи это в базу. Потом просто уложи туда... у нас более 100 стран... хммм... ну скажем по 30 млн записей на каждую страну. И заставь это все работать быстро... Разумеется используя Коде-Фирст... Когда поймешь в чем проблема - посмеемся вместе...
разбираться лишь в сишарпе
Не считая соглашений о генерации таблиц из кода 
виртуозом графического дизайнера БД
Да любой школьник нарисует там таблички с колонками.
с графического дизайнера начинали
точнее с листа бумажки
Не нашел просто ни одного преимущества, особенно в долгосрочной перспективе.
Хотел вот недавно старый проект обновить, а фиг вам - нет совместимости пишет.
Да и смотреть на энто или на код две разные вещи.
И ДБА вживую никогда не видел
-----
Так и слава богу - не допустил господь до греха...
Тем не менее - видеть базу, как прикладник, ты должен только в том виде в каком ее даст ДБА.
А как она реально выглядит - тебе занать не надо... и даже вредно.
Просто посмотри на описанное выше и подумай - ну зачем тебе детали организации хранения адреса, если адрес ты видишь как указано?
Или прямо каждый второй
-----
Данные имеют свойство накапливаться.
Причем - довольно быстро.
Той базе, которую Я делал для системы импорта, проблемы производительности появились уже на второй год эксплуатации.
Решение проблемы известно - нужно добавлять индекс по паре полей...
Чистить периодически?
Нормальный подход. Или вам нравится вечно со старым дерьмом работать? Нужно же думать заранее, чем вы через два года заниматься будете. ))А попробуйте угадать - сколько раз разрешили переписать заново? Из .... ну пусть для удобства будет 10 проектов.
Переписывать софт, хотя бы кусками - это нормально и должно быть заложено в долгоподдерживаемом софте. Рефакторинг же к этому относится? Если менеджеры не дают этого делать, значит они плохие менеджеры, думающие только о своих показателях и премиях, и не хотящие понимать элементарных вещей.
С какого-то времени поддержка старого софта без переписывания становится дороже переписывания. Ну, так во всех областях, не только в софте. Софт тоже протухает, ржавеет и распадается на атомы.
Ну удобнее c ER дизайнером работать. Все база видна, нет зависимости от используемой версии EF, и генериш что надо.
Насчёт "вся база видна" - тоже спорно. А если у меня монитор маленький или таблиц за сотню? Что толку созерцать сотню квадратиков с несколькими сотнями связей между ними на одном мониторе - ничего не понятно же.
Вот три примера подобного визуального подхода
Все эти визуальные схемы - только для самых простых проектов, фактически учебных примеров.
А попробуйте угадать - сколько раз разрешили переписать заново? Из .... ну пусть для удобства будет 10 проектов.
Всякие крупные магазины и вообще большие компании, начиная от Гуглов, заканчивая средними банками, ретейлерами и прочими, переписывают свои сервисы каждые несколько лет. Дайте догадаюсь, почему? Приходит новый тимлид или мода меняется, и теперь всё не на Реакте, а на каком-нибудь Ангуляре - и вся минимум морда магазина или сервиса переделывается.
А бывает, что менеджерам просто надо показать свою нужность и занятость, поэтому переписывают просто чтобы переписать. Скругляют углы интерфейса, потом снова спрямляют - и так до бесконечности.