Использование моделей ORM вместо правильного моделирования базы данных

Question

Я недавно унаследовал проект, в котором база данных была интересно смоделирована (т. Е. Отсутствовали некоторые определения индекса и внешнего ключа).В проекте используется GORM, и, насколько я могу судить, в этих моделях есть теги, которые все правильно определяют.

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

Answer 1

Единственные недостатки, о которых мне известно, когда я делаю то же самое в моей компании:

1. Взаимодействие - вам нужно использовать golang для запуска и запуска, поэтому если у вас есть проекты, которые хотели бы использовать другой язык в новой базе данных, это немного странно.
2. Сложные вещи SQL - иногда вам может понадобиться использовать сложную функцию, для которой может быть неудобно писать теги (например: составные индексы требуют, чтобы теги во всех полях использовали одно и то же имя индекса, но это странно для умственного анализа и Вы не можете решить заказ)
3. Миграция - если вы используете встроенный AutoMigrate, вы можете получить созданные таблицы, столбцы и индексы, но вы не можете добавлять данные по умолчанию или записывать переход данных, а также не сбрасывают столбцы и не сохраняют история изменений. Если все разработчики используют одну и ту же базу данных dev, это не слишком большая проблема, но если вы начнете иметь отдельные базы данных, вы, вероятно, тоже начнете переносить файлы sql миграции, которыми вам придется управлять отдельно от Gorm.

Я не жалею, что использовал его изначально, поскольку было гораздо проще объявить модель и sql в одном месте, но когда мы выросли и начали использовать более продвинутые функции sql и больше баз данных, нам пришлось переключиться на делает на самом деле определения схемы и миграции.