Databases
StackOverflow2013
Postsdbo
POWould it be crazy to use a (serialized) array instead of a join table to link two database tables?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWould it be crazy to use a (serialized) array instead of a join table to link two database tables?
    primarykey
    data
    text
    <p>I'm using Ruby on Rails to develop a web application.</p> <p>I have a wiki article system as part of my project.</p> <p>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.</p> <p>Right now, I've got it setup and working as follows with a central Article model, which has_many Revisions, which has_many AuthorCredits:</p> <pre><code>class Article has_many :revisions end class Revision has_many :author_credits end class AuthorCredit belongs_to :revision belongs_to :author end </code></pre> <p>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.</p> <p><b>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.</b> 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.</p> <p>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.</p> <p>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.</p> <p>How would you handle modeling a system like this?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USWilliam Jones
    1. USWilliam Jones
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWould it be crazy to use a (serialized) array instead of a join table to link two database tables?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POWould it be crazy to use a (serialized) array instead of a join table to link two database tables?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POWould it be crazy to use a (serialized) array instead of a join table to link two database tables?
      1. USmushroom
      1. VTFavorite
    1. COCrazy ideas are good and creative, as long as they work the way you desire them to.
      singulars
      1. POWould it be crazy to use a (serialized) array instead of a join table to link two database tables?
      1. USBlessed Geek
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload