Как построить хороший API поверх плохой базы данных?

Question

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

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

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

Answer 1

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

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

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

и

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

Answer 7

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