Hello,
I have several tables in my design which have nothing but an id, and I
can’t
help thinking that makes them a little superfluous. I’m keeping track of
versions on a lot of my models, and so I have a venues table and a
venue_revisions table, for example. The venues table has nothing except
an
id, because everything about a venue can be changed from one version (or
revision, as I have called it) to the next. Can anyone see a better way
of
organising this, or should I just stop concerning myself with it?
-Nathan
njmacinnes wrote:
I have several tables in my design which have nothing but an id, and I
can’t
help thinking that makes them a little superfluous. I’m keeping track of
versions on a lot of my models, and so I have a venues table and a
venue_revisions table, for example. The venues table has nothing except an
id, because everything about a venue can be changed from one version (or
revision, as I have called it) to the next. Can anyone see a better way of
organising this, or should I just stop concerning myself with it?
-Nathan
In terms of database theory, is the database “normal”? There must be
some
field in the venue_revision table that is always the same across one set
of
venues. The first example that comes to mind is the ‘name’ field.
Refactor
to migrate this field to the venue table.
Otherwise, you have a “compilable comment”. Take it out, and use
.with_scope
to limit venue queries by some criteria.
–
Phlip
Test Driven Ajax (on Rails) [Book]
“Test Driven Ajax (on Rails)”
assert_xpath, assert_javascript, & assert_ajax
Thanks for the suggestions, but there is no field which will always stay
the
same. If you think about it, the name of a venue can change, a venue can
move (or it can just be that the people who first added the venue didn’t
know the postcode or got it wrong, or the postcode changed) and a venue
can
change ownership.
I could take it out, then use with_scope as you suggest, but there’s a
problem with that too. At the moment, a venue has_many :events (well
actually, it has_many event_revisions, thus creating the same problem
again,
but to make things easier to describe, let’s just stick with events). I
could make venue_revisions and events have a many-to-many relationship,
but
having a seperate venues table (or at least a venue_id), ensures that an
event never has more than one venue, although it be related to more than
one
venue_revision.
What I’d ideally like to do is have rails pretend there’s a venues
table,
but without actually having one. So each venue revision has a venue_id,
and
each room has a venue_id, and these are maintained by rails. It’d also
mean
people can visit venue pages with ids in the urls, and the latest
revision
will automatically be used. I’m not sure if this is entirely normalised,
but
it seems it’d do the job pretty well.
-Nathan