Hi off-topic'ers, Having done a decent amount of work in both an RDBMS and an ODBMS (mainly PostgreSQL and the ZODB). It has definitely been a love/hate relationship for me - when I am working in an RDBMS I yearn for a ODBMS and vice-versa. The grass is always greener ...
Some Pros for an ODBMS: * Embeddable: Having your database embedded within your application can be quite useful in certain cases. Here the ZODB is a good competitor to SQLite (http://www.blueskyonmars.com/2005/06/18/zodb-vs- pysqlite-with-sqlobject/). Some portion of Plone's popularity has stemmed from it's ability to ship with a database that is managed as part of the application, as not having to pick and install an RDBMS is one less barrier to entry. * Model Inheritance: Doing model inheritance with pure objects is very easy. Jeffrey Shell has done some light comparisons of ActiveRecord versus the ZODB. http://griddlenoise.blogspot.com/ 2006/03/yay-object-database.html * Rapid Prototyping: You've got some data that you've cooked up in Python, say a tuple of dictionaries. With on object database you can just store that data as an attribute on your object - sure it's messy and your code to access the data breaks encapsulation, but sometimes it's damn nice to be able to just prototype without design tables to hold every bit of data. Also, I've seen Perl developers abuse the filesystem and treat it like a database, certainly any DBA would cringe at such practices, but damn Perl developers can bang out prototypes and do migrations insanely fast. Bjorn has pointed out many of the pros of relational database already, such as easy indexing, SQL is a widely known standard, referential integrity and strict data type enforcement. A couple additional points and corrections in defense of an object database: * You can integrate a GUI with an object database quite easily. John Barham recently gave a talk about this at the Vancouver Python Conference (http://www.vanpyz.org/conference/2006/proceedings/8rMJUi/ RestZope.html). Having your GUI talk to your application services via REST instead of doing SQL from the client GUI is going to allow you to keep all your business logic in one place, and doesn't tie you to a specific schema. * Storing pointers: In Plone this is provided at the framework level in Archetypes. You can have a ReferenceField which makes it very easy to refer to another object. Relational databases of course excel at references, and it does feel nicer to have this functionality be very robust and lower down in your framework stack. * Quering: SELECT statements and schemas make it very easy to walk up to a foreign system and easily understand it and query it. However, having to maintain indexes at the framework level means that Plone (and other CMF-based systems) allow you to query multiple content types with a single API call (something that I've not seen a RDBMS- backed framework do, although I suspect some of the Java ones might?): results = context.portal_catalog.searchResults( Type=['Document', 'File', 'Image'], Creator='kteague') * Schemas: In Plone many people use UML to diagram the schema and workflows and then simply export that into a Plone product using ArchGenXML. In Zope 3 there are Schemas and interfaces which are both quite good at building clean data models. Finally, in defence of RDBMSes it is possible to "model the dynamic operations or rules that change the state of the data in the system" as this is what stored procedures are often used for (for better or worse). Anyways, I've enjoyed (and cursed) using both relational and pure object databases as they each lead the developer to approach the problem from a different perspective and using both ultimately helps me to create better data models regardless of which system I happen to be working in at the time. - Kevin Teague --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
