[Nitro] a 'database' entity?

chiron sun chiron.sun at gmail.com
Thu Jun 8 12:32:15 EDT 2006

Hi there Kashia

Thanks for reviewing my comments.  The 'theory' however is not mine.  There
is quite a body of work on what a database is, what it needs to do, etc.
I'm only taking  credit for my errors in describing 'theory' or
misunderstandings about Og or ruby.  

I have written a couple of databases from the ISAM-up.  And I feel I can
comment on places where "there be dragons".  Unfortunately I think quality
tools like mysql or oracle encourage me to take some things I think of as
"basic" for granted.

There's good descriptions for the things that make databases 'reliable',
'trustworthy' and 'consistent'.  This paper on data integrity from Oracle is
nicely done:


Some people will find it interesting, to observe that Og and ActiveRecord
are mechanisms to implement "hierarchical databases" atop (so far)
relational database engines.  Postgress remembers its hierarchical roots.
Before foreign key tables and joins hierarchical databases saved 'pointers'
(on-disk references) to dependant and back to parent rows.  A big problem
was referential integrity.  When I update my Foot, my Toe instances must
'know'.  All the hierarchical issues and advantages are likely to come-up as
more people use these OO persistent data.

I have been working through the Og documents and source in order to document
a catalogue of attributes, and features.  In the process I'm realising some
DB things that I'd like.  At some point I hope to have a picture of what's
there and a more informed opinion.

As an aside, is there is a place for a discovery lexxer to enumerate class
attributes (I have seen something along those lines.  The automatic
documentation doesn't seem to list legitimate options and attributes.) 

Back onto your comments, I see what you are saying, and I believe I can see
"why" you see things this way.  I'd like to ask you to accept that there are
some good reasons for holding an alternative point of view on this.  Perhaps
I phrased my earlier description poorly.

Comments below ...

-----Original Message-----
From: On Behalf Of Jonathan Buch
Sent: Wednesday, 7 June 2006 22:37

>w> A database entity is the structure for the tables and other structures 
>w> that are all related to the same thing.  A database encapsulates these 
>w> model objects as the owner object.
 k> This description fits $db = Og.start(....) very well..
>w> In this simple case, a high-level database entity would be something
>w> like:
>w>     class BasicBlog
>w>        entity  :Category
>w>        entity  :Post
>w>        entity  :Comment
>w>     end
 k> This is done by:
 k> $db.manage_classes(Foo, Bar, Asdf)

Unfortunately I do not agree.  The code sequence given:

     $db = Og.start(....)                     #  [1]
     $db.manage_classes(Foo, Bar, Asdf)       #  [2]

Does not encapsulate a database entity or 'object'.  The "$db" global
correlates to a database connection.  In DB API it would be an "Open()" or
"Connect()" call [1]. 

The other 'maverick' thing here is my application need to know my tables,
viz. "Foo", "Bar" and "Asdf" [2].  So my object is not integral, it is

Finally my test of this sequence demonstrates that the line:

     $db.manage_classes(Foo, Bar, Asdf)       #  [2]

Will incorporate any currently 'require'-d Og classes (tables) in my
application.  As you recall Kashia, you reminded me that the order of
'require'-s is critical (necessary) to correctly open two databases.

This may or may not be desirable.  I know from my exercise to open two
distinct databases, the results were highly undesirable.  My second
programming affirmation is "do no harm".  Propagating new tables can be
convenient, when I want.  It can be extremely wrong, especially if data goes
to the wrong data store.  

For example, this would be acceptable:
     $db.manage_classes(Foo, Bar, Asdf)      
   # ==>  LOG ... "Bar" not found.
   # ==>  LOG ... Creating new table "ogbar", class(es): "Bar".
   # ==>  LOG ... Creating foreign key "og_foo_bar", class(es): "Foo",.

What I saw, is something more like this:

     class NewFoo < Foo

     $db.manage_classes(Foo, Bar, Asdf)      
   # ==>  LOG ... "bar" not found.
   # ==>  LOG ... Creating new table "ogbar", class(es): "Bar".
   # ==>  LOG ... Creating foreign key "og_foo_bar", class(es): "Foo",.
   # ==>  LOG ... "ognewfoo" not found.
   # ==>  LOG ... Creating new table "ognewfoo", class(es): "NewFoo".   #

So in line [3], a new table was created for the NewFoo class.  Unless I take
specific steps to 'require' or declare the NewFoo class after the
"og.setup()" call.  

In brief I'm saying that a DB entity would be a container, it is nominally a
management entity.  The example give:

     $db.manage_classes(Foo, Bar, Asdf)       #  [2]

This is something that at best describes a 'managed' logical connection.  If
there is a dependency or constraint in the database linking Foo with table
pay_scale, the application runs a real risk of blowing the business' data
integrity right out of the water.  

Why?  Because the "view" provided in [2] is not integrated.  It is probably
not wholistic in the sense of OO analysis.  For the Foo, Bar, Asdf
application this is probably fine.   It could be a simple 'read-only
reporting' program.  

The challenge comes in six months or later when the payroll manager decides
the report program should also apply the new pay grades or when the
government decides to introduce a new tax on Foo-s.

If I'm clear on these points, then I've covered the part I think is useful.
A 'database entity' would represent the whole for a domain of data.  A data
domain can be many different applications.  If we take a different example
for line [2], like:

     $db.manage_classes( Members, Category, Comment )       #  [4]

There is an equally valid application that might want a different connection
(and view) of the data such as:

     $db.manage_classes( Members, BugsDesc, Comment )       #  [5]

Both lines [4] and [5] can exemplify distinct applications over the same
data 'universe'.  It is no mistake that some DBMS-s is call the database
disk area "a universe".  

For now Og apps are single or limited domain in scope.  As these tools
develop, they will grow in scope and application.  I have a deep abiding
faith in the creativity of people to come up with fantastic ways to use
software and most especially middleware.  

Thanks for the chat.  My aim is to add comments that are constructive, I
ought to admit that my perspective one that sees database as the most mature
element of software development.  The way things are, stems from survival of
the "most suitable".    


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.2/356 - Release Date: 05-Jun-2006

More information about the Nitro-general mailing list