Алексей КВсему своё место.

Как ты молниеносно сам себе противоречишь, при чём в грубой форме

Алексей КА раз EF-миграции во всех случаях применить нельзя, нафиг они такие нужны .

И тут же «всему своё место»

EDUARD SAPOTSKIЕсли тебе что-то не понятно (а тебе нихрена не понятно), то не стоит называть это сразу бредятиной, есть риск опозориться, что ты и сделал в очередной раз.

А как назвать ту ахинею, которую ты тут несёшь? Какой ещё «нужный набор полей юзеру»? Ты чё там куришь??? Какому юзеру? Юзеру БД или юзеру ПО?

Алексей ККонтроль и без того достигается:
1. Кодогенерацией контекста по БД.
2. Необходимые для запуска SQL-скрипты и порядок их запуска определяются специальной "запускалкой" скриптов в зависимости от текущей версии БД.

На сколько больше уйдёт времени при конвертации гигабайтов через EF по сравнению с SQL? В некоторых случаях будет доходить до +бесконечность .

За всё надо платить. Поэтому мы уделяем достаточно времени проработке модели и архитектуры. Чтобы потом не пришлось всё круто менять. Это никому в итоге не нужно. Конечно мы работаем с изменчивыми требованиями, но они в основном являются наращиванием функционала, а не повороты на 90-180 градусов. Так что нет, при наличии баз в десятки и сотни ГБ, мы с необходимостью переколбашивать гигобайты данных не сталкивались. Это ни к чему. Но если потребуется, конечно всегда остаётся SQL, полностью на 100% от него никто не отказывается, но стараемся избегать ручных манипуляций, и пока успешно удаётся. Ещё какие аргументы будут против?

Алексей ККонтроль и без того достигается:
1. Кодогенерацией контекста по БД.
2. Необходимые для запуска SQL-скрипты и порядок их запуска определяются специальной "запускалкой" скриптов в зависимости от текущей версии БД.

На сколько больше уйдёт времени при конвертации гигабайтов через EF по сравнению с SQL? В некоторых случаях будет доходить до +бесконечность .

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

EDUARD SAPOTSKIНа пальцах. Есть структура данных, например:
Person(PersonID, FirstName, LastName, Sex, Birthdate, PassportNumber...)
Есть роли пользователей приложения :
Role1, Role2, Role3
Первая роль имеет доспуп ко всем полям. Вторая, ко всем кроме паспортных данных. Третья роль имеет доступ к паспортным данным и FirstName & LastName.
Как такую задачу будешь решать юзая CF и как будешь "мигрировать" если требования к разрешениям изменятся?
Пример привер децкий. В реальных задачах может быть несколько сотен полей и десятки ролей. Поля могут пересекаться очень часто. И? Порази глубиной мысли!

Да чёрт его знает. Я не то, что с такой задачей не сталкивался... Вообще ни о чём таком не слышал, и очень трудно вообразить где это может понадобиться. Чтобы ограничения висели на поля БД. Да, определённо существуют самые разные ограничения, но это отношения к БД вообще не имеет. Нельзя юзеру доступа иметь к паспортным данным, значит для него они тупо не будут вытаскиваться из хранилища, это вопросы именно бизнес-логики, а не способов хранения данных. Поэтому я вообще без понятия, каким боком это относится к CF или к чему-то ещё.

А у нас кнопки плоские в дизайне, а не выпуклые... Это всё потому, что мы используем CF. Если бы использовали чистый SQL, пришлось бы делать выпуклые кнопки. Вот так

ViPRosСначала Модель.

+100500


Модель --> Код --> БД

Концептуально самый эффективный подход.