Было бы сумасшествием использовать (сериализованный) массив вместо таблицы соединения для связи двух таблиц базы данных? - PullRequest
Новая
       4

Было бы сумасшествием использовать (сериализованный) массив вместо таблицы соединения для связи двух таблиц базы данных?

2 голосов
/ 22 июня 2010

Я использую Ruby on Rails для разработки веб-приложения.

У меня есть система статей в вики как часть моего проекта.

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

Прямо сейчас, я получил егонастроить и работать следующим образом с центральной моделью Article, которая имеет has_many Revisions и has_many AuthorCredits: 

class Article
  has_many :revisions
end
class Revision
  has_many :author_credits
end
class AuthorCredit
  belongs_to :revision
  belongs_to :author
end

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

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

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

Одна огромная потеря, которую я вижу сразуБат в том, что я больше не смог бы вызывать операции с базой данных, такие как соединение напрямую с моими данными.Я предполагаю, что это также убило бы мою способность использовать удобные методы Rails, такие как own_to: авторы.Вместе это означает, что я полностью потерял бы способность идти в противоположном направлении и видеть все вещи, зачисляемые определенному Автору, и это само по себе может убить всю эту идею, если я не смогу найти способ обойти ее.Я мог бы пойти на компромисс, имея набор объединений для текущих AuthorCredits, но сохраняя их также в виде сериализованного массива, чтобы он все еще отслеживался таким образом, но тогда реверсии становятся проблематичными с готовыми решениями, и мне придется изменить PaperСлед или что я использую для восстановления или удаления AuthorCredits при возврате.

Как бы вы справились с моделированием такой системы?

1 Ответ

3 голосов
/ 22 июня 2010

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

Возможно, вы можете настроить вашу модель.

Измените отношение так, чтобы "AuthorCredit" был "hasmany" для "Article".

Затем вы можете добавить атрибут «от ревизии» к «ревизии» в отношение или просто принять, что вам нужен только список текущих авторов.

Вам нужно будет только добавить Авторский кредит на ревизию, в которой они впервые появляются, и вы можете пометить их как удаленные, просто установив атрибут "to revision:", когда они будут удалены.

...