Автоматическое создание таблиц ORM нарушает настройки администратора баз данных.

Question

Я использую ORM для автоматического создания таблиц из классов моделей. Я называю классы и их поля так, как это естественно для приложения. Затем ORM использует те же имена для таблиц и столбцов и автоматически генерирует имена других объектов, таких как ограничения и последовательности, которые полностью абстрагируются ORM.

Я не объявляю, как должны именоваться таблицы, столбцы и т. Д. Я оставляю это на усмотрение ORM. Я вижу в этом здравый смысл с точки зрения приложения.

Администратору БД для моей команды это не нравится. Администратор базы данных говорит, что если столбец «B» в таблице «A» имеет ограничение внешнего ключа для поля «Y» в таблице «X», то имя должно быть «A.X_Y» вместо «AB» ». Администратор базы данных говорит, что это «правильный» способ присвоения имен внешним ключам, и поэтому ORM называет их неправильно . Оба механизма ORM, с которыми я знаком, позволяют явно отображать имена классов / полей на имена таблиц / столбцов, поэтому я знаю, что можно разместить DBA без изменения классов.

Мой вопрос: , на практике, делает ли это (явное сопоставление имен) обязательным вводом дополнительного объекта (т. Е. Новых файлов / разделов конфигурации, нового кода) или связывания (т. Е. Импорта, декораторов, аннотаций)? ) в приложении, которое иначе не могло бы существовать? Конструкции ORM могут быть разными, поэтому я думаю, что ответ может быть разным для разных двигателей.

Если ответ на этот вопрос почти повсеместно да, я бы посчитал хорошим аргументом, что администратор БД должен уступать ORM в интересах производительности, исходя из логики, что база данных существует для удовлетворения потребностей приложения, а не наоборот. Комментарии по этому вопросу также приветствуются.

Обратите внимание, я НЕ прошу конкретных рекомендаций о том, как следует называть классы / поля / таблицы / столбцы.

Answer 1

Конструкция ORM может быть разной, поэтому я думаю, что ответ может быть разным для разных двигателей.

Вы здесь. В зависимости от ORM, явное указание отображения поля-> столбца может (или не может) вводить дополнительные сущности в форме записей конфигурации, аннотаций, атрибутов и т. Д. Сказав это, это хлеб с маслом (или я должен сказать, очень основы) для механизма ORM и, следовательно, обработка этих отображений обычно не добавляет заметных накладных расходов.

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

Answer 2

Стандарты кодирования существуют по причине - если бы я был администратором баз данных, я мог бы предположить, что выигрыш в производительности от использования ORM без изменений должен приносить пользу во имя обслуживания.

Это вопрос компромиссов: если дополнительные усилия по названию столбца внешнего ключа в соответствии с корпоративным стандартом минимальны (и в большинстве ORM, с которыми я работал, это так), я бы простосделай это.

Если ваш ORM делает это очень сложно, я бы объяснил администратору базы данных, что это архитектура, отличная от той, к которой он привык - использование ORM означает, что будет редко, если вообще когда-либо будет выполняться ручная запись SQL- все это автоматически создается ORM, поэтому имеет смысл ослабить стандарты кодирования.

Answer 3

Нет, явное сопоставление имен не создает дополнительную сущность или связь; он определяет политику и процесс, которые ваш администратор БД решил использовать для своих баз данных. Я также утверждаю, что ваша логика немного отсталая; приложение существует для обслуживания потребностей базы данных. Программное обеспечение, которое устанавливает ЛЮБАЯ компания, существует для обслуживания / заполнения / представления данных, которые существуют в базе данных, а не наоборот.

Учтите это; программное обеспечение, которое делает все, что делает ваша компания, будет меняться по мере изменения требований и технологий и подвергаться рефакторингу по мере развития стандартов и сложности. Данные, которые хранятся в базе данных, однако, не будут; даже когда схема меняется / развивается, лежащие в основе данные будут меняться очень мало, если вообще будут.