Hey Jonathan, and everyone else,
On the subject of large-table databases and representing them in an ORM
environment, could I interest you in expanding on the following issues? These
issues are more at the 'design' level then the typical 'it doesn't work'
issues we deal with here, but with a collection of fairly clued-up people like
this, I'd love to hear what some of you think.
1) How do you manage your interactions with the non-mapped tables?
2) What kind of factors do you take into account in deciding whether to
represent a table within the ORM or not? Obviously there's a strong
"does it make sense" judgement, but if you can be verbose... :)
3) Do you try to create Objects's that spread across multiple tables (ie
against arbitrary selects) or use properties or custom select statements
to access related data?
4) On a schema of this complexity, do stored procedures play a role, and if
so how do they interface with the ORM?
5) How about any other advanced rdbms features such as views, triggers,
etc? A strong ORM as SA is, from my impression, encourages the user to
develop the "logic" in (this case) Python, whereas a less representative
more SQL-ish interface encourages developers to implement within the
RDBMS-side, usually as SP/triggers/etc. There's a religious war at the
heart of this, for sure, but I'm curious for other peoples opinions.
Much appreciate any comments people have :)
-G
On Monday, May 8, 2006, 10:44:32 PM, you wrote:
> On May 7, 2006, at 4:55 PM, Michael Bayer wrote:
>> regardless of if you have a DB with 250 or 1000 tables. is it then
>> appropriate to have 1000 separate classes ?
> no way in hell. that would be a mindfuck.
> in my case, I have 200+ tables and about 50 classes / objects that
> are mapped against them
> would I rather
> a - write 50 class definitions for sqlalchemy
> b - have a script autogenerate 200 table definitions in the
> sqlalchemy syntax , delete 150 of them, and then just extend 50 with
> the inter-table mappngs
> i'm solidly in the b camp
>> I have only seen one database schema that had several hundred
>> tables before. the guy basically represented every single element
>> of a large and complicated DTD as a separate table, i.e. <taga> was
>> one table, <tagb> was another, etc. To him,
> =snip
>> you cant tell me thats the proper way to do something. and even if
>> it was, you dont represent an XML document with a different class
>> for each XML tag, you use a DOM tree, which uses about half a dozen
>> classes.
> sure i can. i might have to practice saying it with a straight face
> for a while, but yeah, i could definitely say that.
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Sqlalchemy-users mailing list
> Sqlalchemy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
