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

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.

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