Doctrine и Propel используют наследование одной и конкретной таблицы для сопоставления объектных отношений. Первый видит все возможные поля в дереве классов, сопоставленные с одной таблицей, тогда как второй отображает каждый класс в определенную таблицу, дублируя общие поля в иерархии наследования.
Хотя это облегчает аппарат ORM, он предлагает мне плохой дизайн базы данных. Эти плохие шаблоны проектирования применяются в базе данных?
Ответы:
Невозможно сказать, является ли конкретный дизайн базы данных плохим, не зная, что делает приложение, форма данных, ожидания производительности и так далее. Хотя обычно нормализация (в некоторой степени) считается наилучшей практикой, довольно часто денормализуют области баз данных по соображениям производительности, поэтому хорошие и плохие очень открыты для обсуждения без большого количества данных, чем у большинства людей в начале.
Добавьте к этому множество подходов, которые можно использовать для возражения на реляционные отображения, и все станет еще сложнее, поскольку «лучшая» структура базы данных будет зависеть от конкретной объектной модели, уровня наследования и так далее.
Принимая один размер, подходящий для всех подходов, библиотеки персистентности ORM почти всегда будут создавать неоптимальную структуру базы данных для любой конкретной ситуации и будут использовать некоторые вещи, которые можно рассматривать как плохую практику для данной конкретной ситуации .
Вы, конечно, могли бы написать ORM, который нормализовал бы, но вы бы увидели довольно здоровенные последствия для производительности, так как для каждой вставки в основную таблицу нужно было сканировать различные справочные таблицы, чтобы увидеть, существуют ли значения, получили ли они свои ключи и не сделали ли они. не выполняйте соответствующие вставки.
(Когда вы делаете это вручную, вы можете сократить некоторые из них, так как знаете, что представили их с выпадающим списком, содержащим только допустимые значения, поэтому вам не нужно делать эти поиски, вы можете просто использовать ключ, довольный тем, что он работает чтобы быть действительным, ORM не мог сделать такое предположение, поскольку он не контролирует пользовательский интерфейс.)
Но вы должны помнить, что они не стремятся оптимизировать производительность базы данных или целостность данных, они оптимизируют скорость разработки . Если конкретная структура ваших данных важна для вас, то вам нужно либо вручную написать код отображения вашего объекта / СУБД, либо, по крайней мере, провести детальную оценку всех доступных библиотек и выбрать ту, которая наиболее соответствует вашим потребностям ( если таковой существует).
По сути, это сводится к требованиям и компромиссу между хорошо структурированными данными, производительностью базы данных и скоростью разработки. Как и во многих компромиссах, вы не можете выбрать все три.
Я не согласен с тем, что ORM способствует ненормализации или плохому дизайну базы данных. Фактически, худшие разработанные базы данных, которые я видел, были сделаны без ORM. Упрощая правильные отношения, основанные на идентификаторе строки, вместо создания отношения, основанного на значении случайного поля, это скорее способствует хорошему дизайну базы данных.
Возможно, это не способствует нормализации, но, опять же, ORM, где легко создавать таблицы / объекты и отношения, можно было бы увидеть и в этом. В ORM не так много работы, чтобы создать таблицу «месторасположения» с адресами и связать сотрудников с местоположением, вместо добавления адреса в таблицу сотрудников. Но без ORM разделение местоположения означает, что каждый раз, когда вы хотите получить доступ и к местоположению, вам нужно присоединиться.
Итак, мой ответ: нет, я так не думаю . Возможно, в действительности все наоборот, хорошие ORM поощряют хороший дизайн базы данных, по крайней мере, для тех, у кого мало опыта.