Re: KirbyBase

On Monday 12 September 2005 10:53 pm, Hal Fulton wrote:
> Kevin Brown wrote:
> > On Monday 12 September 2005 17:06, rubyhacker@xxxxxxxxx wrote:
> >>Randy Kramer wrote:
> >>7. And I think: What would a one-to-many databasse relationship look

> And yet, no. I retract that. There would be *two* one-to-one relationships.
> You could store a separate key for each. You only have a one-to-many when
> you use the same field to look up a variety of child records, correct?
> Resulting in, essentially, an array of rows?

A few things:
* (aside) the attribution above is a little misleading (not if you read it
carefully, though)--I did not write what is in the item 7
* my background is more in relational database systems than, for example,
in objects in any way shape or form--my earlier answers were purely from the
viewpoint of a "traditional" relational database (hence I feel like I'm in
over my head and should try to bow out gracefully but quickly ;-) (And, I'm
not an expert in relational databases, just struggled with them a few times,
in the "good old days". ;-)

* re the last paragraph above, yes, (in a vacuum) you could look at the two
situations above as either a one-to-many relation or two one-to-one
relations, but unless there is some mitigating circumstance (which I won't
try to imagine atm), in a relational database "world" (i.e., by relational
database practitioners, it is a one-to-many). I won't try very hard to
explain why, but I'll throw out words like normalization (generally, getting
the database in a form that minimizes the duplication of information) and ask
one (hopefully leading question):

Consider your example of "someone" having two bosses. What you suggest (to
treat that as two one-to-one relations) is to have two boss fields in the
"someone" record--one pointing to boss1, one pointing to boss2. So, what do
you do when you encounter someone else with 3 bosses? In your scenario (and
a relational data base world, you'd have to modify the "someone" table to add
an additional column for the third boss. In a normalized relational
database, you'd just add another boss record to the boss table pointed to by
the same key that points to that someone's first and second boss.

* Now, not knowing anything (?) about object databases (is that what
KirbyBase is trying to be) (and not all that much about objects) my
impression is that object databases are not nearly as structured as a
relational database, in fact as someone else mentioned (iirc), they are
almost more of a persistence mechanism so that when you restart an
application after a shutdown, you can recover data that might have been
captured in prior "runnings" of that program. My impression is that there is
(can be) a pretty ragged mixture of objects of all shapes and sizes.

(The object database / persistence mechanism that I have the most knowledge /
experience with is the one in Instiki (is that Madeleine) and that only based
on a short experience with installing and using a local Instiki.)

I guess I'd think two things: I'd like anything that billed itself as an
object database to be able to handle any object (no matter how convoluted,
more below) with something like one save command (and later, one load
command).

By convoluted, I'm trying to remember (without looking back) how you defined
the objects you used as examples. Seems there was one "main" object that
included some sub-objects. (ATM, I don't have any feel for the right
vocabulary (its not "inheritance" iiuc) to describe that situation, nor do I
know whether objects can have sub-objects (I know objects can have attributes
and methods, but I never thought in terms of sub-objects), but, if that is
possible, I would hope for an object data base that could handle such an
object in "all its glory" (ie., with its subobjects) as simply as possible
(one command to save, one command to load).

On the other hand, I can imagine simplified object databases with limited
scope for various reasons (reduced complexity, whatever), that would not
undertake to handle such complex objects but instead require that the various
subobjects be stored separately.

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.

regards,
Randy Kramer

I can








.

Relevant Pages

  • Re: POD speed
    ... > consider use of such a POD product to be without disadvantages. ... Enforcement of database constraints in application code is one solution generally ... > application-private data into a relational database on the suspicion ...
    (comp.lang.java.databases)
  • Re: Why would I want to serialise something
    ... >I read a lot about serialising things to XML. ... Serialization is a very helpful mechanism. ... rows and columns and stored in a relational database. ...
    (microsoft.public.dotnet.general)
  • Re: No knowledge of the database?
    ... > Now I know a whole lot more about RDBs but I don't work in IT anymore. ... about the data structure to not know about the database, ... > T-Accounts, debits, and credits are of no concern to persistence. ... few features of a relational database (joining, querying, referential ...
    (comp.object)
  • Re: Advise
    ... use this Table to link One Subscriber to Many Magazine and One ... of Relational Database Design. ...
    (microsoft.public.access.forms)
  • Re: Advise
    ... use this Table to link One Subscriber to Many Magazine and One ... of Relational Database Design. ...
    (microsoft.public.access.formscoding)
Loading