Re: [SQLObject] two postgres questions

[Bud P. B. <bu...@si...>]

On Mon, 19 May 2003 00:17:32 -0400
Edmund Lian <el...@in...> wrote:

> I've seen these issues again and again. I've chosen, in my latest work, 
> to forgo a third-party TP layer and just put the constraints in the DB. 
> This way, I don't have to deal with API and cross language issues since 
> the data is accessed from Python, VB, Access, Crystal Reports, etc.

thanks for your insight.  I'm still digesting but it seems that there
is a considerable range of needs.  People (like you) who need a single
DB model accessed by multiple languages and apps and people who do
just python and single app (like possibly me at the moment) and don't
do legacy db models...  

I see three ways of doing constraint kind of stuff:

* all in python, dbms doesn't know about constraints.  This works
  if everything that accesses the data goes through the same
  middleware layer  (not directly to dbms)

* specification of constraints in python/middleware that translates it
  to SQL statements to send to the dbms (such as check constraints).
  As you already say, there is a lot of diversity with dbms
  capabilities here  (I've only looked at Postgres so far)

* doing everything in the dbms.  

It seems that the first and last are easy, the middle one more
difficult (as you mention).  

What about a middleware layer who usually does the first solution but
doesn't block you from doing the third?  Would that be useful or does
anyone see a strong need for the middle solution?

--b


/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D. 
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------