Вчення та пропел використовують спадкування однієї та конкретної таблиці для відображення об'єктних зв'язків. Перший бачить усі можливі поля в дереві класів, відображені в одній таблиці - тоді як останній відображає кожен клас у конкретній таблиці, дублюючи загальні поля в ієрархії спадкування.
Хоча це полегшує апарат ORM, він пропонує мені поганий дизайн бази даних. Ці погані схеми дизайну застосовувати в базі даних?
Відповіді:
Неможливо сказати, чи поганий той чи інший дизайн бази даних, не знаючи, що робить додаток, форма даних, очікування від ефективності тощо. Хоча нормалізація (певною мірою) вважається найкращою практикою, досить часто денормалізувати ділянки баз даних з міркувань продуктивності, тому хороші та погані дуже відкриті для обговорення без набагато більшої кількості даних, ніж більшість людей, коли вони починають виходити.
Додайте до безлічі підходів, які можна застосувати до заперечення щодо реляційних відображень, і речі стають ще складнішими, оскільки "найкраща" структура бази даних буде залежати від конкретної об'єктної моделі, рівня успадкування тощо.
Приймаючи один розмір, який відповідає всім підходам до стійкості ORM, бібліотеки майже завжди створюватимуть неоптимальну структуру бази даних для будь-якої даної ситуації та використовуватимуть деякі речі, які можна вважати поганою практикою для даної ситуації .
Ви, звичайно, можете написати ORM, який нормалізується, але ви побачите досить здоровенні наслідки для продуктивності, як і для кожної вставки в головну таблицю, яка потрібна для сканування різних таблиць пошуку, щоб побачити, чи існували значення, чи отримали вони свої ключі та чи не зробили вони не виконувати відповідні вставки.
(Коли ви робите це вручну, ви можете скоротити частину цього, оскільки ви знаєте, що ви подали їм спадне меню, що містить лише дійсне значення, тому вам не потрібно робити ці перегляди, ви можете просто скористатися ключем, який задоволений тим, що це відбувається щоб бути дійсним, ORM не міг зробити це припущення, оскільки він не контролює інтерфейс користувача.)
Але ви повинні пам’ятати, що вони не прагнуть оптимізувати продуктивність бази даних та цілісність даних, вони оптимізують для швидкості розвитку . Якщо конкретна структура ваших даних для вас важлива, вам потрібно або кодувати об'єкти / RDBMS-карти вручну, або, принаймні, зробити детальну оцінку всіх наявних бібліотек і вибрати ту, яка найбільш відповідає вашим потребам ( якщо така існує).
По суті, це зводиться до вимог і взаємодії між добре структурованими даними, продуктивністю бази даних та швидкістю розробки. Як і у багатьох компромісах, ви не можете вибрати всі три.
Я не згоден з тим, що ORM сприяє денормалізації або поганому дизайну бази даних. Насправді, найгірші розроблені бази даних, які я бачив, були зроблені без ORM. Здійснюючи просте встановлення належних відносин на основі ідентифікатора рядка, а не створення відношення на основі значення випадкового поля, це швидше сприяє гарному проектуванню бази даних.
Можливо, це не сприяє нормалізації, але знову ж таки ОРМ, де легко створити таблиці / об’єкти і відносини, майже можна побачити, щоб просувати це. Не набагато більше роботи в ОРМ, щоб створити таблицю "місцеположення" з адресами та зв’язати співробітників з місцем розташування, а не додавати адресу до таблиці співробітників. Але без ORM, відокремлення місця розташування означає, що кожного разу, коли ви хочете отримати доступ до місця розташування, вам також потрібно зробити приєднання.
Тож моя відповідь: Ні, я не думаю, що так . Насправді, навпаки, хороші ОРМ заохочують хороший дизайн бази даних, принаймні щодо тих, хто має мало досвіду.