History for WhatWhyHowZODB

??changed:
-
    The 'backing store' for the ZOPE platform is the Zope Object Database.  Its extremely powerful and flexible supporting a API that allows pluggable Storage Mechanisms behing the ZODB interface.  Two phase commit.  Has no size limit [mindlace said python has a 'large file support' turned off so it is a python limitation OUT OF THE BOX its an option you must turn on when you compile python interperter].  Features:

    * Transactions - ZODB supports the concept of transactions between try/except blocks.  

    * Versions - could be thought of as a long running transaction that can span hours, days, weeks.
 
    * Undo - any transaction that is 'committed' inside the ZODB can ultimately be rolled back.  if you change 4 objects in a transaction, you can undo the transaction and the objects would be restored to their previous state.
 
    * Undoable Undo  - available to some types of Storage interfaces.  they call this "Transactional Undo"

    * Permissions - the ZODB, standalone, has no known Permissions.  Permissions are layered ontop of ZODB via ZOPE.  

    * Pluggable Storage - 
  
        * Berkley DB - <a href="Products/bsddb3Storage">ZODB Storage</a>

        * RDBMS Storage - There is an OracleStorage, and InterbaseStorage.

        * Remote Storage (ZEO) - a ZEO client is essentially a ZOPE install but its Storage is a remote server.  

        * File Stroage - [default]
         
            * NFS - dont use NFS, because of NFS's locking scheme (?)

            * NTFS - works just fine

            * FAT/FAT32 - works just fine

            * Intermezzo - anyone have experience?

            * ext2/ext3 - works just fine (anyone running ext3?)

            * reiserfs - i assume it works (egenius I believe sells ZOPE/Reiser configurations)


----------------------------------------------------------------------
  
    **note** I think this is probably the most important thing to make sound nice :) since its the scariest thing for people to get over: 
  
    * ODBs are unpopular becuase there is no standard interface into them, or 'ways to get your data out'

    * most ODBs - seem to have performance issues related to them vs. their relational breathren

----------------------------------------------------------------------

some quick comments:

* as stated above, usually one major issue people come about with OODBMS
is performance. the topic is complex, dependent on many factors and
design decisions ..

just one fact: currently (8/2002) the world's largest database with over
500 TB is run on an OODBMS (objectivity.com) by the Stanford Linear Accelerator Center (SLAC) -
http://www.slac.stanford.edu/slac/media-info/20020412/database.html

This is 50x the probably biggest Oracle installation in Europe
(at a german telco).

Also: how much complex, highly-structured master data (like contract
information, product definitions, .. not log-data) do you have?

100MB, 1GB? And, what does 1GB of RAM cost today? Just go out and by RAM
and operate your ZODB out of main memory.


* The impedance-mismatch.

.. at the design level:
Have you ever gone through the full spectrum of pain of having both
a relational DB designed as an entity-relationship model plus an
object-oriented model designed with e.g. UML?

.. at the implementation level:
Not to speak of the the object-relational mapping layer you also have
to come along. It too often develops into a nightmare. Even with stuff
like supporting code generators or libraries of mapping layers.

Enter ZODB. Transparent. Orthogonal. Single design paradigm (OO) and
single design method possible (e.g. UML). Pluggable storage backends.


* ZODB, OODBMS and language neutrality

ZODB is a closed system - it is _directly_ only accessible from Python.
Of course, this makes possible a very tight language integration and
thus transparency. It is quite clear, that no language neutral access
method would ever allow such transparency over all (existing) languages.

More important: Why do you need language neutrality? Allowing access
to the data store from all system components?

Using the data store, regardless if relational or OO, as the integration
platform of a system is at least a qustionable architecture. It introduces
deep semantic dependencies and only on the surface level solves the integration
problems.

One alternative is a service-based architecture where a stateless service API
mediates accesss to the data store and implements business logic.

* Hot schema evolution.

What if your definition of "contract" changes? With RDBMS, you usually
write new DDL for the revised tables plus migration scripts to move the
data. Then you must take a downtime to upgrade the schema and migrate the
data.

With ZODB, you implement the revised classes plus implement hooks that
get called when instances of old classes get loaded to migrate data on-the-fly.
You don't need to take any downtime!


* You're not forced to use ZODB. You can perfectly build on a backend RDBMS
if you like for all your data, or you can use a mixture:

   * complex, highly-structured master data in ZODB
   * simple record oriented mass data in RDBMS