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@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7