[Zope-dev] Idea: Create SQL-Alchemy tables via interfaces

[Hermann Himmelbauer]

Am Donnerstag 04 September 2008 09:10:22 schrieb Brian Sutherland:
> On Wed, Sep 03, 2008 at 05:18:50PM +0200, Hermann Himmelbauer wrote:
> > Am Mittwoch 03 September 2008 16:02:17 schrieb Brian Sutherland:
> > > On Wed, Sep 03, 2008 at 02:43:31PM +0200, Hermann Himmelbauer wrote:
> > > > Hi,
> > > > In my current SQLAlchemy / Zope-based design, I need the following:
> > > >
> > > > - SQLAlchemy table definitions
> > > > - classes + mappers
> > > > - Zope interfaces
> > > >
> > > > The problem with this design is that much data has to be defined
> > > > twice, e.g. the datatype "varchar(50)" should be represented by an
> > > > interface with TextLine(max_length="50"). Moreover, any changes such
> > > > as adding columns etc. also have to be done in the interface and the
> > > > table definition.
> > > >
> > > > To overcome this, I just had the idea to use the interface/schema
> > > > definitions for the table definition itself. Probably I'm not the
> > > > first who had this idea, but I'm not aware of such an extension to
> > > > interfaces.
> > > >
> > > > Any thoughts on this?
> > >
> > > I'm much more in favour of the reverse procedure. I think the database
> > > is the canonical store of this information and that SQLAlchemy should
> > > read that and make it available for doing form validation.
> >
> > But isn't exactly that the real meaning of interfaces?
> > So I have the impression that at the beginning of the design process, I'd
> > model the interfaces, which describe and express everything I expect from
> > the underlying objects.
> >
> > And when that is done, I'd program the underlying objects. And for
> > content objects, the storage could be in an RDB (SQLAlchemy), or
> > somewhere else. And for that, the table structure could be derived from
> > the interface.
>
> Trying to derive an RDB table structure from an object model's design
> has nearly always left me with badly designed and/or badly performing
> database tables.
>
> Every time, it's paid me to design the database structure to be
> application independent. Basically assume that your application will
> never be the only application using the database. Many projects have a
> way of sprawling and having a database usable by non-application code is
> a big advantage.

But wouldn't the database still be application independent this way? The only 
difference seems to be that I'd define the database structure in the 
interface. And zope.interface is a package that can easily be included in a 
non-zope.app related application.

> So, given that I believe the above, trying to use the application to
> create an application independent database schema is the wrong way
> around.

To be honest, I personally also always went the RDB -> Zope way, either 
because the database already existed, or for some other reasons.

Therefore I don't really had such negative experiences, but I expect that 
there will problems if one has an object-only design and tries to stuff these 
objects in the database later on.

Thanks for you comments; I'm curious if other people see that issue the same 
way.

Best Regards,
Hermann

-- 
hermann at qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7