From: David Vallner <david@...>
Date: 2006-12-28T09:46:58+09:00
Subject: Re: Modified Single Table Inheritance

--------------enig769AF9E99DE70C00A818BF51
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ryan Glover wrote:
> Hello,
>=20
> I am developing an application that will have 100's of model classes
> each derived from a single source class. Each model will have 4 similar=

> attributes but then have about a dozen unique ones each.

Why are they deriving from a single class anyway?

If it's only for a few identical attributes without significant
functionality to go along, I'd say it's a bad idea to use inheritance.
And with latent typing in Ruby, you Rarely If Ever need inheritance
anyway. Saves you the bother that is inheritance mapping at any rate.

> Problem is, I'll end up with 100's of
> tables, which also does not appeal to me.
>=20

I can't understand this. It's rather common that an ORM database schema
has a number of tables in the same order of magnitude as there are model
classes. My biased opinion is that data should be modelled on the
database level where you have some theorethical foundations about what
are "good shapes" for the data. It also doesn't hurt to at least make
the DB schema somewhat document the data model - the data an application
gathers / stores is the most likely part of it to persist in the long
term. Of course, you're probably in a better position to judge this.

> My third solution, the one I am asking advice on, is this.
>=20
> I create a single table with the 4 common columns and a dozen columns
> with names such as float1, float2, float3, ... , string1, string2, ..
> etc.  Creating enough columns of each type to cover my largest subclass=
=2E
> Then I use STI and for each class I map the generic columns to the nice=
r
> names inside the subclasses.  So in one class float1 may be miles/hour
> while in another class it might be turkeys/hectare.
>=20
> Does this sound like a reasonable approach?
>=20

Database schemas like this tend to make it into The Daily WTF with some
regularity.

(Unfortunately, they also make it into production systems.)

If there's a chance someday, someone, somewhy might want to access your
data at a DB level (using a reporting tool maybe), there'd be no end to
the grief.

Or, if a bug in your code gets the database into an inconsistent state,
and you have to drop down to SQL to patch things up.

Avoid.

> And of course, does anyone see a much better way to do what I have
> proposed?
>=20

Use migrations to create the schema from scratch if you just want to
avoid writing a lot of SQL up front?

David Vallner


--------------enig769AF9E99DE70C00A818BF51
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFkxP8y6MhrS8astoRArEBAJ9HDubMhGUbZHdfCV+nscweMInkjACffcfQ
vBgA0l4e+GbXt3GUNlmTtBE=
=07NB
-----END PGP SIGNATURE-----

--------------enig769AF9E99DE70C00A818BF51--