Блог

У меня плохо спроектированная база данных. По разным причинам так и должно оставаться.

По моему опыту, мне нравились ORM, такие как ActiveRecord, но я использовал их только для новых проектов без существующей базы данных.

Есть ли способ создать хорошую модель данных с использованием ORM в стиле ActiveRecord без изменения плохо спроектированной базы данных?

Другие затрагивали техническую сторону этого, поэтому я хочу добавить другое представление:

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

• Займет ли из-за этого больше времени завершение вашего проекта?
• Потребуется ли для этого больше людей?
• Требует ли это особой компетентности для работы?
• Поставит ли это под угрозу качество данных?
• Усложняет ли это техническое обслуживание?
• Будет ли это иметь серьезные последствия для производительности?
• Какие последствия это будет иметь для следующего проекта после вашего?

и

• Что нужно сделать, чтобы перейти из текущего состояния в желаемое
• Какова стоимость за это
• Каковы будут последствия для вашего текущего проекта, если вам сначала придется исправить дизайн?

Потому что, в конце концов, такого рода вещи — это действительно все, что имеет значение. Если вы не можете «продать» идею о том, что дизайн плох, на самом деле это не так, и вы просто жалуетесь на вещи, которые не имеют значения ни для кого, кроме нас, коллег-гиков, которые также живут в бинарном мире, где NOT(Good) = Bad .

Конечно, этот столбец bigint можно было бы заменить на tinyint , и эти столбцы следовало переместить в другую таблицу, и этот фрагмент повторяющейся логики можно было бы спрятать за каким-нибудь представлением / функцией, и этот API будет работать медленнее, чем необходимо, но это все дрянные детали, которые могут иметь значение, а могут и не иметь, в недвоичном мире.

У меня есть любимый столик, который я ненавижу на работе. Примерно 1% данных противоречивы и просто неверны. Затраты на очистку этого последнего 1% были бы огромными (консолидированные данные из нескольких систем), а ошибки даже не отображаются в десятичных числах при агрегировании. На самом деле, это у меня есть проблема. Я не могу добавить определенное ограничение к таблице. Поэтому вместо этого я должен добавить предикат where к двум программам, использующим его. Я несколько раз пытался привести доводы в пользу того, чтобы это исправить, но никто не хочет вкладывать деньги во что-то, что не является проблемой. И я согласен с ними.

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

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

Первый способ сделать это:

1_ Большинство ORM допускают способ представления нескольких таблиц в одном объекте и наоборот. Но это решение сложное и таит в себе опасность.

2_ Моим предпочтительным решением было бы использовать методы де-нормализации базы данных, такие как View, материализованные представления и процедуры, для создания нового слоя поверх вашей модели данных и создания ORM поверх этого слоя. (Желательно создать новую схему и создать view mv в схеме владельца. Таким образом, любое приложение, использующее старую схему, может продолжать работать, и у вас есть полный контроль над тем, как вы хотите спроектировать свой уровень доступа к данным.).

Я переписал ваш вопрос как:

Можно ли создать интерфейс прикладного программирования, обладающий желательными или положительными качествами, особенно подходящими для того, что указано для базы данных, имеющей нежелательные или отрицательные качества?

Итак, мой ответ для вашей базы данных:

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

Задумайтесь об этом на секунду. Действительно.

У меня дома проблемы с влажностью. По разным причинам так и должно оставаться.

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

Есть ли способ создать дом без проблем с влажностью, используя такие украшения, как штукатурка и обои, без изменения самих проблем с влажностью в доме?

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

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

В остальном делайте все, что можете, со схемой БД: внесение «мягких изменений», таких как добавление новых полей или индексов, когда это необходимо, не должно нарушать существующий код, выполняемый в БД (если это основная причина, по которой вы не можете изменить схему).

По разным причинам так и должно оставаться.

Я в это не верю, но на самом деле это не имеет значения. Управлять этим на уровне базы данных действительно довольно просто. (Но простой не обязательно означает легкий.)

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

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

Что касается того, можете ли вы использовать ORM для создания хорошей модели данных без изменения плохо спроектированной базы данных, я бы сказал: «Не рассчитывайте на это».