Під час використання ORM, на що слід звернути увагу на дизайн вашої бази даних

На які деякі проекти баз даних слід звернути увагу, коли ви знаєте, що до бази даних буде доступний, використовуючи Вікіпедію об'єктного реляційного Mapper (ORM) ? Також дивіться Entity Framework NHibernate або LLBLGenPro.

Як приклад, я зазначу обмеження параметра 2100 для виклику RPC SqlServer. Це проблема при використанні LLBLgen та приєднанні таблиць, коли використовувались складові первинні ключі, див. Статтю MSDN про складені ключі .

Пройдіть стандартні методи нормалізації, переважно до 3-ї нормальної форми. Деякі ORM можуть вибирати відносини, визначені на рівні бази даних, тому вам не доведеться вручну.

Я б дійсно пішов іншим шляхом і запитав, що я повинен знати про ORM. Переконайтеся, що ви знаєте: - Як я можу профілювати запити? - Як я можу змінити ORM та написати власний запит? - Чи можна використовувати замість цього збережені програми?

База даних повинна бути агностичною для ORM, оскільки, швидше за все, це заставить додаток.

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

2. Будьте в курсі того, що ваш ORM не може зробити. Джанго деякий час не підтримував групу через ORM, що було болем (все ще є, застарілі системи весело!). Тож ознайомлення з обмеженнями ORM є обов'язковим для DBA, навіть якщо вони не є тим, хто пише код для ORM

3. Періодично збирайте повільні журнали, збирайте їх через mysqlslowlog та дивіться на топ-10 або близько того. В основному він покаже вам запити, які зайняли найбільш загальний час у цілому. Запит, який займав у середньому лише 1 сек, але за останній місяць запускав 50 тис. Крб, залишатиметься в цьому сукупному звіті, як біль у великому пальці;)

Я б не сказав ходити так екстремально, як повністю скинути ORM. Якщо ваші розробники, що використовують ORM, не є DBA, вони, ймовірно, записують SQL, який є настільки ж поганим або гіршим, ніж ORM. Тож врешті-решт на DBA випаде дивитися, що далі.

Є декілька речей, які я помічаю відразу про застарілу базу даних, яка відрізняється від бази даних, створеної такими ORM, як Sequel та ActiveRecord для Ruby.

1. Використання первинного ключа у всіх названих таблицях 'id'. Так, це можна відмінити, але idце за замовчуванням.
2. Використання множинних назв для таблиць.
3. Використання підкреслених знаків ("змійка") для розділення слів, що створюють описову назву таблиць і полів.
4. Використання _idдоданих до іноземних ключів: макет зазвичай подобається referenced_table_id.

Я роками пишу свій SQL вручну, тому що я не довіряв ORM, але протягом останніх двох-трьох я почав використовувати два згадані раніше ORM і вражений тим, наскільки добре вони інтегруються в існуючі бази даних, і наскільки добре вони можуть розшифрувати базу даних, якщо дотримуватися їхніх конвенцій, або я знайду час, щоб дати їм підказки, необхідні для розуміння застарілої БД.

Я не знаю, чи є якісь загальні рекомендації щодо створення схем, щоб добре грати з ORM, але я думаю, що всі ми отримаємо користь, маючи певні стандарти. Виразно є час і місце для ORM, особливо якщо ви використовуєте хорошу мову OO і ви дотримуєтесь жорсткого розкладу.

Це трохи (:)) залежить від того, яким ІЛИ картографом ви користуєтесь, тому приділіть деякий час дослідженню того, які функції db мають АБО Mapper у питанні підтримки / не підтримки.

Наприклад, картографічні оператори Майкрософт не підтримують усі вбудовані типи даних SQL Server, не підтримують деякі новіші / розширені функції TSQL (рекурсивні запити, підказки оптимізатора тощо.

Теоретично хороший АБО-картограф повинен бути досить гнучким, щоб подолати (і дозволити вам зіставити) добре розроблену схему реляційних баз даних до хорошої об'єктної моделі. Насправді нам ще належить ще трохи пройти, перш ніж всі частини головоломки будуть на місці; хоча багато АБО картографів підтримують розширене картографування, воно часто виникає за рахунок складних запитів та проблем продуктивності.

Для гарної продуктивності DB (і для збереження здорової інформації :), все ж слід дотримуватися кращих практик, коли справа стосується дизайну схеми db; нормалізуйте спочатку і денормалізуйте там, де [/ якщо] необхідно. Що стосується коду, не перестарайтеся з моделлю об'єкта ; навіть якщо ОР-картограф підтримує складні моделі успадкування та об'єкти, які об'єднують багато таблиць разом, це також сфери, де ви ризикуєте зіткнутися з надмірно складними запитами, потрапивши в базу даних тощо. Профіль, профіль, профіль і не просто приймайте ORM генеровані запити як належне. Майте на увазі, що АБО запити, створені в картографічному режимі, часто можна налаштувати так само, як звичайні запити SQL і що два функціонально еквівалентні запити на стороні об'єкта (наприклад, запити linq) іноді можуть призводити до дуже різних запитів SQL.