Rails - Apr 2007 - tables with only an id

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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
  http://www.oreilly.com/catalog/9780596510657/
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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


On 22/04/07, Phlip <phlip2005-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> 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
>   http://www.oreilly.com/catalog/9780596510657/
>   "Test Driven Ajax (on Rails)"
>   assert_xpath, assert_javascript, & assert_ajax
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---