Re: Requesting suggestions on layout for simple "name" catalogs

On Wed, 22 Feb 2012 15:32:12 -0800 (PST), Jair Trejo
<jairtrejo@gmail.com> wrote:

>I've got a system with three main tables, say "offices", "commercial
>spaces" and "industrial properties". Many of their features, like the
>type of glass of their windows, need to come from a catalog, so I have
>a base class like:
>
Are they that different enough that you needed three tables for
them? Makes it difficult to do queries for, say, "not office" <G>

>Right now I'm using:
>
>class GlassTypeOffice(SimpleNameCatalog):
> pass
>class GlassTypeIndustrialProperty(SimpleNameCatalog):
> pass
>class GlassTypeCommercialSpace(SimpleNameCatalog):
> pass
>

Same situation -- you are creating three essentially identical
tables which have to be maintained separately. No easy way to do queries
on glass types that might be common among two or more categories. AND
you now have to maintain three more tables individually.

I'd add a "usage" field using some sort of enumerated type
(personally, if the spaces are common enough I'd use one table for the
core information and use this same type to identify the space too).

Usage (ID, usage)
1 Office
2 Industrial
3 Commercial

Space (ID, usageID, GlassID, ..., common, properties, ...)

OfficeSpecific(ID, SpaceID, ...)

IndustrialSpecific(ID, SpaceID, ...)

CommercialSpecific(ID, SpaceID, ...)

Glass(ID, UsageID, ..., whatever, ...)

GlassSpace(ID, GlassID, SpaceID)
{This handles if a single space entry can have multiple
sources/types of glass}

Granted, I tend to think in SQL -- not ORM... Actually, to avoid
duplicating entries in Glass, it should be normalized to

Glass(ID, ..., whatever, ...)

GlassUsage(ID, GlassID, UsageID)
{This allows a single glass entry to be applied to multiple usages}

and then

GlassSpace(ID, GlassUsageID, SpaceID)

Yes, that does mean that to properly find the (multiple) Glass
linked to a space is a set of joins on:

space -> glassspace -> glassusage -> glass
(possibly with space->usage->glassusage in parallel)

It might make the autogenerated admin interface rather ugly -- but
that's partly good... The admin interface (IMO) is meant for dirty
low-level tweaking of the data contents, it isn't really a production
maintenance view; you should write the views for maintaining the data in
a friendlier manner (thereby hiding the dual many-many linkage from the
operator),
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.