Re: [SQLObject] creating joins

Quoting Nick <ni...@dd...>:

> Most non-MySQL schema designers (in my experience, anyway) tend to
> name
> columns that are the same data the same in every table they appear
> in.
> That means, if person_id is in Address, then the key in Person is
> person_id as well.  This uncomplicates JOINS in a major way, as
> well as
> maintains consistency in your data dictionary.  Therefore, idName
> for a
> table is almost always the same name as the foreign key in another
> table, except where you have 2 in the same table.

I'll have to say this is a style issue, not so much a MySQL issue. :)
A quick poll amongst developers here (all Postgres or MSSQL people)
shows 50/50 between naming id columns "table_id" or just "id". I'm
definitely an "id" person. :) (We've got one guy who routinely names
every column in a table "tablename_colname". This makes as much sense
to me as "tablename_id", so yeah..

This is not SQLObject specific, but I guess I've never understood the
"tablename_id" argument for making joins cleaner. in SQL:

".... ON person.id = other.person_id...." vs
".... ON person.person_id = other.person_id"

always seemed to be duplicating the person metadata to me, and makes
me forget which is primary. whereas there's no doubt in my mind
whether something is a foreignKey or primaryKey if it's just "id".

Everyone here names foreignkeys "table_id" except in rare cases (two
that come to mind: foreignKey to own table (usually called
"parent_table_id" by myself) and multiple foreignKeys to another
table, called arbitrary things). So yeah. Not sure what my point is,
except I'll assume the new Style object ought to cover this, and
that's that.

> I was originally
> using class references for my foreign key definitions and ran into
> the circular dependecy probelms, but there were ways around that,
> too. The programmer *could* get into an infinite loop of they follow
> circular references, but that's their problem :-P
> That can happen now.

The problem (that i've experienced) is circular *import* dependencies.
I would agree, strings seem to solve this. With caveats mentioned in
another mail about joined/FK'ed classes possibly needing to be
imported by a third-party class that doesn't want to have to know
that Person has a Phone object (and hence where to import Phone
from), just that Person.phone returns a Phone object.

Automatically creating the joins might conceivably solve this,
although I'm pretty sure I can come up with with the same import
circular dependencies whether it is at module import time (solved by
strings) or object instantiation time (although classRegistry can
probably be used to save this: you'll never import that FK'ed class
if it's already in the classRegistry...) Hmm.

- Luke