Re: I think that relational DBs are dead. See link to my article inside

From: Dmitry Shuklin <shuklin_at_bk.ru>
Date: 3 Jul 2006 14:45:37 -0700
Message-ID: <1151963137.015244.53310_at_a14g2000cwb.googlegroups.com>


Hi,

Bob Badour wrote:

> > What differ my DB from the rest? :
> >
> > - one object can have a many ObjectIDs
> > - one ObjectID can address many different object instances
>
> In short, no logical identity whatsoever. Sounds, um, charming. ::rolls
> eyes::

Not yet. Logical identity exists. But it strong only for each context.
>From one context to anoter identity not strong and all depends from
developer. When I am doing experiments i found that it is ok to make almost all identification in all contexts equal. but not in all contexts. let take object 1000 for example. In global context (sector) it represent meta descriptor to attribure 'name'. if some object has a name then object has an attribute 1000. but attribute 1000 also has its own name. so object 1000 has attribute 1000. if you dereference OID 1000 in global context you got instance of AttributeDescriptor for attribute 'Name'. If you dereference OID 1000 in some object - you got name of this object. If you dereference OID 1000 inside context of OID 1000 then you got string 'Name'.

So in each context OID 1000 references different instances. Each context == object instance.

> So, can we assume it fully supports join, project, extend, union,
> intersect, transitive closure, restrict, the existential quantifier and
> the universal quantifier? Or do you not consider the lack of any of
> those 'restrictions'?

it is very interesting question. i can't answer yes or no. may be right answer is 'this question is not applicable to my DB' but it is uninteresting answer. Let i try to describe what i have implemented and you decide for youself do i support this or not.

at first my DB is written for Microsoft .NET and supports objects written on any managed language. it support 2 modes of serialization. solid and structured. I will describe only structured because solid saves object as one unbreakable peace.

structured serialization gives programmer API which he can use to serialize object attributres. for this mode class should not have any fields. class can have only methods. all data will be stored in DB via API. it is some kind like a ViewState in ASP.NET

classes stores attributes into network DB. i don't write yet anoter relational DB. So data storage based on anoter conception. it don't has a tables. and it don't support relations as subset of Cartesian crossproduct. if you want to compare my DB with RDB then you should assume that relation is a one table row (not a whole table). In this case row is subset of Cartesian crossproduct from 'set of all column names' on 'set of all values'. yea it is too heretic )))

so it doesn't support all conception that you asked about exactly as it RDB does. but you can use C# and do what you want. from this point of view you can assume it fully supports all of them.

i forget for yet another big restriction. i don't support any declarative language. only imperative. C# for example is supported.

it is interesting that possibility for one ObjectId address many instancess allow me to make object joins or aggregates. lets assume that we have collection of objects C1 which all implements interface I1. then we change requirements and want to make view from objects which has the same IDs but supports I2 : I1 let assume that I1 has one property CompanyObjectID and we want to have a I2 with additional CompanyName. It is ok.
We should make new object collection. Then we should make new class C2 . Implement I2 and add instances of C2 into new collection with original IDs. let continue. C1 has attribute CompanyObjectID. we can map this attribute to C2. And each C2 will have access to the same attribute instance of CompanyObjectID as C1. And when we will change property CompanyID in some C2 instance then property from corresponding C1 instance will changed too. then CompanyName can be implemented (pseudo code) as public string CompanyName { get { return global.dereference(this.CompanyId).Name; }}

it is anoter way to do the same. we can map each Company.Name attribute as attribute CompanyName to each C1. and implement C1 : I2 C1 will think that he accessed its own attrribute but will access attribute of another object. small workaround is needed here - we should override CompanyObjectID set and remap attriburtes as needed. In previous sample this overriding is not needed.

unions - it is very simple. just add as many instances to some collecion as you want.

and e.t.c.

I have plans to implement some kind of declarative system. but don't need it now. as i describe i am specializing in neural networks and natural language processing (by ANNs) so i just don't need this functionality now and don't want to spend my time on it.

WBR,
Dmitry Received on Mon Jul 03 2006 - 23:45:37 CEST

Original text of this message