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 -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )