Philosophical question - Zope Objects vs Entities in a RDBMS
Okay so I'm getting into this whole Zope deal, and from what I have seen so far it looks pretty darned good, I like the OO concept, but with it it poses a few design issues for websites / web applications Traditionally all data is stored in some form of relational database, and then the scripts pull it back out again. Now we all know and hate relational databases (well I do anyway as I'm a child of the information age - learning in OO concepts and then having to go back to a relational database) but they are remarkably good for what they do - storing large amounts of data and allowing you to retrieve it in a quick and relatively painless manner, if you get your head around SQL. Now Zope comes along with the ability to create and persist objects without the need for a relational database. Wooohooo... all my prayers have been answered, or have they?. Q1. Has anyone tried to build webapplications with large (maybe into the 10's of thousands) numbers of Zope objects? Q2. How much more or less efficient is Zope for storing a piece of data over a traditional relational database ? Q3 (I'm a newbie here) Can a python external method access Zope objects ? Eg if I create a task object from a ZClass can I then do things with it from a python script? Q4. I think I remember seeing a post about the Zope database being a single large file posing problems with the Linux filesystem.. or was that the windows filesystem.. if so then that could limit Zope's potential in a commercial production enviroment, surely ?? If this is true what have people done to try and get around this, ie archiving objects (however that could occur) etc.. ? Thanks in advance for any responses, Rowan Hick Business Analyst Soft Tech NZ LTD, Auckland, New Zealand.
In article <384EB897.ED918A0F@softtech.co.nz>, Rowan Hick wrote:
Q1. Has anyone tried to build webapplications with large (maybe into the 10's of thousands) numbers of Zope objects? Q2. How much more or less efficient is Zope for storing a piece of data over a traditional relational database ?
I'm very interested in this as well. Has anyone got any performance stats on Very Large Zope Applications? I'm looking at data on number of objects as well as load-related information, eg how hard is the server being hit? K. -- Kirrily 'Skud' Robert - skud@netizen.com.au - http://netizen.com.au/ "Darkly hinting of head hitting desk" -- Megahal (trained on asr), 1998-11-05
Rowan Hick wrote:
Okay so I'm getting into this whole Zope deal, and from what I have seen so far it looks pretty darned good, I like the OO concept, but with it it poses a few design issues for websites / web applications
Traditionally all data is stored in some form of relational database, and then the scripts pull it back out again. Now we all know and hate relational databases (well I do anyway as I'm a child of the information age - learning in OO concepts and then having to go back to a relational database) but they are remarkably good for what they do - storing large amounts of data and allowing you to retrieve it in a quick and relatively painless manner, if you get your head around SQL.
Note there are also OO extension to RDBMSs (e.g. Oracle) and Postgres has also some concepts implemented.
Now Zope comes along with the ability to create and persist objects without the need for a relational database. Wooohooo... all my prayers have been answered, or have they?.
Well it uses it's own database anyways :-)
Q1. Has anyone tried to build webapplications with large (maybe into the 10's of thousands) numbers of Zope objects? [skiped - no idea ] Q2. How much more or less efficient is Zope for storing a piece of data over a traditional relational database ? Even a ``traditional'' database may be good to store object w/ a little logic. Also, I dunno much about the data types definitions in Postgres but I know you can define your own types, so why not to try to define class-like type where methods are triggers (just a thought) Of course a DB design specially for this purpose will fit much better.
Q3 (I'm a newbie here) Can a python external method access Zope objects ? Eg if I create a task object from a ZClass can I then do things with it from a python script?
I am a newbie too :-) but learning fast cause python looks very easy itself.
From what I know so far, yes.
Q4. I think I remember seeing a post about the Zope database being a single large file posing problems with the Linux filesystem.. or was that the windows filesystem.. if so then that could limit Zope's potential in a commercial production enviroment, surely ?? If this is true what have people done to try and get around this, ie archiving objects (however that could occur) etc.. ?
IIRC that is a limit for the ext2 file system. There may be other Linux FSs that don't have this limit. Also I've heard ext3 is about to come wich I guess/hope won't have this limit anymore. -- CIMPOESU Teodor, Web Programmer @ DIGICOM S.A. Bucharest, Romania @ Internet, site development @ teo@digiro.net , +(401)-330.47.28 official home page ~ http://www.digiro.net/ Internet web page ~ http://internet.digiro.net/
Teodor Cimpoesu wrote:
Q4. I think I remember seeing a post about the Zope database being a single large file posing problems with the Linux filesystem.. or was that the windows filesystem.. if so then that could limit Zope's potential in a commercial production enviroment, surely ?? If this is true what have people done to try and get around this, ie archiving objects (however that could occur) etc.. ?
IIRC that is a limit for the ext2 file system. There may be other Linux FSs that don't have this limit. Also I've heard ext3 is about to come wich I guess/hope won't have this limit anymore.
ext3's big deal right now is journalling support. ext2fs is _not_ the cause of the 2GB limit, as stated elsewhere, it is the 32bit VFS that is the issue, and there is the LFS patch to fix that. -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
Rowan Hick wrote:
Okay so I'm getting into this whole Zope deal, and from what I have seen so far it looks pretty darned good, I like the OO concept, but with it it poses a few design issues for websites / web applications
Traditionally all data is stored in some form of relational database, and then the scripts pull it back out again. Now we all know and hate relational databases (well I do anyway as I'm a child of the information age - learning in OO concepts and then having to go back to a relational database) but they are remarkably good for what they do - storing large amounts of data and allowing you to retrieve it in a quick and relatively painless manner, if you get your head around SQL.
Now Zope comes along with the ability to create and persist objects without the need for a relational database. Wooohooo... all my prayers have been answered, or have they?.
Q1. Has anyone tried to build webapplications with large (maybe into the 10's of thousands) numbers of Zope objects?
Yes, although I suspect some people wouldn't consider this large.
Q2. How much more or less efficient is Zope for storing a piece of data over a traditional relational database ?
That's an interesting question. It depends on alot of things, such as the indexes used in the RDBMS, or even what RDBMS you use. I imagine that ZODB and RDBMS are similar in the storage required, although it would be interesting to do a comparison with some sample data.
Q3 (I'm a newbie here) Can a python external method access Zope objects ? Eg if I create a task object from a ZClass can I then do things with it from a python script?
Yup.
Q4. I think I remember seeing a post about the Zope database being a single large file posing problems with the Linux filesystem.. or was that the windows filesystem.. if so then that could limit Zope's potential in a commercial production enviroment, surely ?? If this is true what have people done to try and get around this, ie archiving objects (however that could occur) etc.. ?
A very important thing to note is that ZODB has an *open* storage interface. You can plug in (with a fairly small amount of Python code) any storage manager you want. The default storage manager that comes with Zope uses a single file. This storage manager is a resonable default but might not be best for everyone. Ty Sarna has written a BDB storage manager, and it's only a matter of time before someone writes an RDBMS storage manager. The approach of puting data in a single file is a feature of the FileStorage, it is not a feature/limitation of ZODB. Here's a bonus question: Q5. I really need to store my data in an RDBMS, can I integrate it with Zopes objec't system and get some of those nify OO benefits. Good question. ;) You sure can. Zope SQL methods return objects, not just rows. The objects returned support acquisition, can particpate in URL traversal, can have DTML and other forms of methods, etc. In Zope 2.2, you'll even be able to define ZCLasses (Zope classes) for relational data.
Thanks in advance for any responses,
No problem. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
participants (5)
-
Bill Anderson -
Jim Fulton -
Rowan Hick -
skud+usenet＠netizen.com.au -
Teodor Cimpoesu