Would it be crazy to use a (serialized) array instead of a join table to link two database tables?

Question

I'm using Ruby on Rails to develop a web application.

I have a wiki article system as part of my project.

As part of the wiki, articles can be linked to authors, and those links also need to be tracked by the revision system. Authors is an attribute of the Article as a whole, and not related to who enters particular Revision, and is a list that is updated over time along with the other wiki attributes.

Right now, I've got it setup and working as follows with a central Article model, which has_many Revisions, which 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

While this works, it's pretty awkward, in that I have to build a whole additional set of joins (in the form of AuthorCredits) each time I make a new Revision, no matter how small. Furthermore, there's quite a bit of additional complexity inherent in using this approach with my actual models that makes this really quite complex and fragile.

I'm thinking about reducing the whole thing into just the Article model, and adding a serialized Array to the model that's a list of authors. Essentially, I'd be moving the join table into a serialized text field. Then I could just slap on an out of the box revision tracking plugin like Paper Trail, and have an extremely clean model schema.

Has anyone ever done anything like this before? I've never heard of it, so I'm worried this might be a crazy idea, but my current situation is so complicated/fragile that I'm seriously tempted.

One huge loss I see right off the bat is that I wouldn't be able to call database operations anymore like join directly on my data. I assume this would also kill my ability to use convenient Rails methods like belongs_to :authors. Together this means I would entirely lose the ability to go in the opposite direction, and see all things credited to a particular Author, and that alone might kill this entire idea unless I can figure out a way around it. I might compromise by having a set of joins for the current AuthorCredits, but store them also as a serialized Array so that it's still tracked in that manner, but then reversions become problematic with off the shelf solutions, and I'd have to modify Paper Trail or whatever I use to handle rebuilding or removing AuthorCredits when reverting.

How would you handle modeling a system like this?

Answer 1

Yes, its a bad idea! You lose out on the power and flexibilty of having a database plus you have an excedingly awkward data structure to manage.

You could perhaps adjust your model.

Change the relationship so that "AuthorCredit" is a "hasmany" of "Article".

Then you can then either add a "from revision" to "to revision" attribute to the relationship or just accept that you only want a list of current authors.

You would only need to add an Author Credit on the revision they first appear in and you can mark them as dropped by merely setting the "to revision: attribute when they are dropped.