Сообщество Ruby простоты ... Каков ваш аргумент для упрощения схемы db в новом проекте?

Question

Я работаю над проектом с разработчиками, которые раньше не работали с Ruby OR Rails.

Они создали схему, которая слишком сложна, на мой взгляд. Схема имеет 117 таблиц, и получение простейшей части информации потребует прохождения/объединения 7 таблиц ... и, конечно же, нет «основной» таблицы, которая служит в качестве своего рода ключа между ними. Схема отображает многие инструменты рельсов, такие как метод «найти», и многие из has_many/относятся к отношениям почти бесполезно. И кодирование для всех этих отношений, вероятно, будет более трудоемким, чем у нас есть деньги для кодирования.

ВОПРОС:

Предполагая, что вы очень убежден (ИМХО ... хе-хе), что схема не является идеальной, и существует множество способов для представления домена, как бы вы спорите для упрощения схемы (кроме из того, что я уже сказал)?

Answer 1

Я буду стоять в 2-х ролей здесь

• DBA: База данных администратора/дизайнер.
• Dev: Разработчик приложений.

Я предполагаю, что DBA является человек, который действительно знают все трюки базы данных. Рейалли знает.

---

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

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

DBA:
База данных не магазин это ядро ​​приложения. Нет приложения без базы данных.

Дев:
№ Приложение Ядро. Нет приложения без интерфейса и бизнес-логики, применяемой к нему.

И начинается война ...

---

Обе точки являются действительными, и это всегда компромисс.

Если база данных ТОЛЬКО будет использоваться RoR, то вы можете использовать ее более как простой магазин.
Если БД может использоваться другим приложением или он будет использоваться с большим количеством данных и высокого трафика это необходимо применять оптимальные методы.

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

Таким образом, вам необходимо, чтобы работала тесно, вместе.

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

---

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

С другой стороны. Если DBA может принять, что все PK - это автоматические добавочные целые числа, которые облегчат жизнь разработчика (по умолчанию это делает ActiveRecord).

С другой стороны, если разработчики согласятся с некоторыми ограничениями DBA, это упростит жизнь DBA.

---

Теперь, чтобы ответить на ваш вопрос:

как бы вы аргументировать для упрощения схемы

Do не аргументировать. Познакомьтесь с командой и доставьте сообщение и укажите, ПОЧЕМУ, что это должно быть сделано.
Возможно, это действительно не так, и вы не знаете ничего, может быть, они ничего не знают.

Вы можете согласиться с общей структурой базы данных и попытаться описать ее с использованием миграции RoR в качестве метаязыка.

Таким образом, они будут видеть общую картину, и вы будете использовать свои замечательные ActiveRecords. А также все будут на одной странице.

Answer 2

Ваша схема БД должна отражать домен и его отношения.

Де-нормализация должна выполняться только тогда, когда вы измерили, что есть проблема с производительностью.

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

Answer 3

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

Архитектурно-технический аргумент здесь прост. Вы решили использовать Ruby on Rails. Поэтому вы решили использовать шаблон ActiveRecord. Шаблон ActiveRecord управляется тем, что таблицы базы данных соответствуют объектной модели. Это шаблон, используемый здесь, и во многих других местах, поэтому лучшие методы, которые они пытаются применять для экстремальной нормализации данных, просто не применяются. Купите копию Patterns of Enterprise Application Architecture и положите небольшую красную закладку на стр. 160, чтобы они могли понять, как шаблон работает с точки зрения архитектуры.

Что такое типы DBA, как правило, не знают о том, как работает ActiveRecord для вас, от генерации запроса, каскадных удалений, оптимистической блокировки, автоматически заполненных столбцов, управления версиями (с act_as_versioned), мягких удалений (с act_as_paranoid) и т. Д. . Существует сильный аргумент в пользу использования хорошо протестированных библиотечных функций, поддерживаемых сообществом, для выполнения этих операций по сравнению с пользовательским кодом, который должен поддерживаться администратором баз данных.

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

Если вы потеряете политическую битву за разумную схему, вы можете захотеть переключиться на DataMapper. Это следующий образец в PoEAA. Другое дело, что вы можете заставить их сделать, это создать представления в базе данных, соответствующие объектной модели. Таким образом, вы можете использовать многие возможности поиска в модели ActiveRecord на основе представлений, но иметь собственные методы вставки, обновления и удаления.