Re: KirbyBase

Randy Kramer wrote:

>   * Now, not knowing anything (?) about object databases (is that what 
>KirbyBase is trying to be) (and not all that much about objects) my 
>  
>
Randy, that is an excellent question.  :-)

This may explain some of the debate that has been going on here (as well 
as the debate in my head).

I think I first wrote KirbyBase with sqlite in mind.  Except, I wanted 
to be able to use Ruby expressions to "express" my select query rather 
than have to use SQL.  To me, that and the fact that tables were just 
plain-text files that could be edited by hand, were the two compelling 
reasons to use KirbyBase.

Hal then came up with the bright idea to have query results be an array 
of custom class objects, if the user so desired.  It was an excellent idea.

Next, Hal made the request to be able to "embed an object within another 
object", which, in DB guy terms meant, to me, allow for one-to-one links 
(I threw in one-to-many links as a bonus).  See, I think I have always 
been thinking of KirbyBase as a simple alternative to sqlite with Ruby 
expression syntax, some relational capabilities, and the ability to 
return objects instead of just records.

Hal has been looking at KirbyBase as more of an object database/object 
repository (I have to be careful here because my knowledge of object 
oriented dbms and ORM is pretty sketchy.  I'm probably not using terms 
correctly).

This helps me to more fully see the disconnect.  Where I think it is 
perfectly normal to have the result set of the "many" side of a 
one-to-many link be a KBResultSet holding a bunch of records, Hal is 
expecting it to be more "integrated" into the parent object so it only 
seems natural for him to be able to turn around and insert the parent 
object back into the table and have KirbyBase automagically insert the 
child objects into the child table.  This is something as a "relational 
db guy", I would never think to do, something that actually makes me a 
little uncomfortable to think about.  All of the little extenuating 
circumstances come to mind like, what if Hal is doing an "update" on the 
parent object instead of an insert, and what if, in this update, he has 
added some new child objects to go along with the ones that already 
exist in the embedded array of children.  How do I handle the update on 
the child table?  How do I know which child objects are new and need to 
be inserted, versus which child objects already exist and just need to 
be updated.  Stuff like that runs through my head and makes me start to 
sweat.  :-)

I mean, I know that it can be done, but it is starting to look like some 
very complex coding to make sure like it all works right, and being a 
relational-db-guy, I'm asking myself, "Is it worth it?".

I mean, if I have a parent table called Orders and this table holds 
customer orders and I have a child table called Items and this table 
holds the detail items for each Order record, having a one-to-many link 
that I can use in a select statement to select an order and all of its 
related detail items in one fell swoop, well that makes a lot of sense 
to me.  It is the kind of select query I have done a million times in 
SQL.  To me, it's even better than SQL because, instead of getting back 
a denormalized result set that has all of the Order fields duplicated in 
every record of the result set, KirbyBase will give me back a result set 
containing the one Orders record and within the Orders.items field of 
that one record will be a reference to *another* result set holding all 
of the detail Items records that belong to that Order.

Then Hal comes along and says, "Hold on, buddy.  I want to be able to 
add a new Order object, embed an array of new detail Item objects in 
that Order object and, performing a single #insert, have KirbyBase add 
that Order object to the Order table and also add all of those Item 
objects to the Items table."  And I think, "What?!  Why wouldn't you 
just do an #insert to insert the Order record and then, for each of the 
detail order items, do an #insert on the Items table?"  And Hal says, 
"Because if I can automagically get the detail Items when I do a #select 
on Orders, then I should be able to automagically insert the detail 
items when I do an #insert on Orders.".

And, without knowing that much about ORM or object databases, I am 
guessing that this is what they allow you to do.  This is how I think 
that KirbyBase has started to slide down that slippery slope from 
"psuedo-relational, sqlite alternative" to object database (or whatever 
term is correct here).

I'm not saying what Hal is asking for is wrong at all.  I just never 
thought of KirbyBase in those terms and I don't know if that is the 
direction I want to take KirbyBase.  Or do I want to just keep KirbyBase 
as (hopefully) a small, tight, well-performing, pure-Ruby DBMS that uses 
Ruby syntax, has some relational capabilities and stores its data in 
plain-text files.

>So, I can see that going either way depending on the aims of KirbyBase.  (And, 
>of couse, nobody needs my blessing/permission/agreement to implement whatever 
>they want. ;-)
>
>Hope something here helps, or I've not made to much noise.
>
>  
>
It has helped me to clarify in my head the question, "What do I want 
KirbyBase to be?".  Now if I only knew the answer.

Thanks, Randy.

Jamey

Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient(s), you are hereby notified that any dissemination, unauthorized review, use, disclosure or distribution of this email and any materials contained in any attachments is prohibited. If you receive this message in error, or are not the intended recipient(s), please immediately notify the sender by email and destroy all copies of the original message, including attachments.