Інструменти даних сервера Sql & Entity Framework - чи є тут синергія?

Виходячи з проекту за допомогою Linq2Sql, я підозрюю, що наступний (більший) міг би підштовхнути мене до обіймів Entity Framework. Я трохи прочитав цю тему, але те, що мені не вдалося знайти, є цілісною історією про те, як інструменти даних SQL Server і Entity Framework повинні / могли / можуть використовуватися разом.

• Чи були вони задумані зовсім окремо, а використання їх разом погладжує неправильний шлях?
• Вони якось цілком ортогональні, і я пропускаю суть?

Деякі причини, чому я думаю, що я хочу, щоб обидва:

• SSDT чудово підходить для того, щоб створити "складений" (перевірений) і легко перетворюваний sql та схему
• Але історія SSDT "міграція / оновлення" не є переконливою (для мене): "Оновити що-небудь" працює нормально для схеми, але немає ніякого способу (AFAIK), щоб вона могла коли-небудь працювати для даних.
• З іншого боку, я не пробував міграцію EF, щоб знати, чи не представляє вона подібних проблем, але біти вгору / вниз виглядають досить зручно.

Дозвольте мені поставити іншу точку зору. Обслуговування баз даних Entity Framework вкрай марно в будь-якому підприємстві або великому проекті баз даних.

Проблеми:

• Автоматичне оновлення схеми. Це абсолютно не те, що я хочу, оскільки це повністю порушує основи обслуговування бази даних. Проблеми полягають у тому, що: (а) хтось із новою версією оновлює базу даних замість проблеми, і (б) оновлення заплановано, коли dba зазвичай робить резервну копію ПЕРШИМ. Отже, автоматичні оновлення марні.

• Створення Db працює лише в основному вироджених крайніх випадках. Навіть не намагайтеся використовувати розширені функції бази даних - незалежно від того, яку саме. Приклад сервера Sql: включені поля в індексах, фільтри на індекси, розділення, стиснення, правила перевірки полів.

• Міграція - передбачає знову вироджені крайові випадки: без перетворення даних або багатоступеневого оновлення легко. Приклад: У таблиці X є історичне поле "user", яке записує, що користувач щось робить. У новому налаштуванні є таблиця користувача, тому потрібно створити таблицю користувача, потім створити користувачів, потім створити довідкове поле користувача в таблиці x, потім оновити це з користувачем це з таблиці користувачів, а потім видалити поле користувача.

Єдиний розумний спосіб розібратися з цими сценаріями - це сценарії генерації та міграції та належна версія.

Тепер SSDT - це чудовий інструмент для версії конкретної версії бази даних, набагато кращої, ніж Entity Framework, оскільки вона насправді - працює. Як і в: він записує всі функції. На жодній із баз даних у мене я майже не міг би використати код спочатку - тому що ми завжди маємо відфільтровані індекси хоча б;) EF навіть не отримає мені 10% того, що мені потрібно.

Наш підхід:

• Створіть базу даних у базі даних, а потім синхронізуйте її до модуля SSDT, який отримує реєстрацію. Синхронізація схем дозволяє розробникам швидко оновлювати свою версію. Завжди є авторитетна головна база даних з поточною версією десь (на спеціальному сервері), тому у нас є довідкова версія, проти якої можна працювати.

• Створюйте дельта-скрипти для необхідності для випусків, які також розроблені та мають приємний механізм для їх розгортання до бази даних.

Існує не один спосіб використання EF з базою даних SQL Server.

1. Код по-перше ... Ви пишете класи, а EF генерує пов'язані таблиці
2. По-перше, база даних ... Ви проектуєте таблиці, а EF генерує класи.

EF не обов’язково виконає всю роботу за вас. EF ви отримаєте там приблизно від 80 до 95 відсотків. Інші 5-20 відсотків ваших зусиль із розробки вашої бази даних будуть доповнені оптимізаціями, такими як Перегляд та Збережені процедури.

Так ні, вони не є ортогональними. Але вам доведеться вирішити, якою буде ваша загальна стратегія дизайну, а потім покластися на такі інструменти, як SSDT, щоб допомогти вам оптимізувати ті частини, де EF дає менше, ніж ідеальних результатів.