Re: [SQLObject] Re: SQLObject

[Brad B. <br...@bb...>]

On 04/10/03 01:06, Ian Bicking wrote:
> On Thu, 2003-04-10 at 00:38, Edmund Lian wrote:
> > Composite keys are used an awful lot in any schema of moderate complexity,
> > and they are important (when used with foreign key constraints) for
> > enforcing relational integrity. If the aim is for SQLObject to support
> > complex projects, then composite key support would be pretty important.
> 
> Can you describe some situations where they'd be used?  For instance, if
> either key was modified at any time that'd cause a lot of problems for
> SQLObject.  If not, then what would be the problem with a third simple
> ID/PRIMARY KEY column?

I use concatenated keys all the time.

e.g.

Site
site_id PK
...

User
user_id PK
...

UserSite
user_id	FK
site_id FK 
(together they're the PK)
...

or

Project
project_id PK
...

Worker
worker_id PK
...

ProjectWorker
project_id FK
worker_id  FK
(together they're the PK)
hourly_rate
...

and so on.

The problem with not having complex primary key support is not that it
makes it impossible to write a certain kind of application but that it
creates extra unnecessary, boring work for the programmer to have to
hardcode the validation checks (and the unit tests for them) to ensure
-- taking from one example above -- that a user hasn't been granted
access to a site twice.

-- 
Brad Bollenbach
BBnet.ca