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

Brought additional few comments and I wish you good luck on your implementation efforts...

Dmitry Shuklin wrote:
> Hi Cimode
>
> > > > How are they attached?
> > > Via configuration DB. It is like a RDB, it contains tables, rows, ...
> > > but it is not RDB. It is RDB emulation on OODB. So tables, rows and
> > > columns has different behavior. For example row can be contained in
> > > many tables at one time. So if you change row field via one table it
> > > automatically changed in all tables which contains this row.
> > You lost me. On one side, you told me there's no concept of table but
> > now you use table concepts...Please clarify...
>
> Yea, there are no tables as concept and at the same time there are
> "tables".
>
> On the most low logic level of DB the network of nodes or or-graph is
> exists. There are no tables, rows, objects, ... only nodes and links.
> All links are single directional. Each link has a "color" or
> identifier. Each node can have as many links as needed. But each node
> can have only one link with one color. There can't be two or more links
> with the same identifier directed from one node. There can be many
> links with the same color directed to the one node. There can be many
> links with different identifier directed from one node to another. From
> some node you can found other nodes only when you know identifier for
> link to these nodes. Each node knows about and owns links dercted from
> this node. Node doesn't know about links directed from another nodes.
>
> Each node can have a .NET object instance attached. In the database the
> root node is exists. the root is the beginning of the database. Each
> persistent object can discover what node is attached to and root node.
>
> links are just pointers. and all works very fast.
>
> Thats all about Cerebrum.Runtime.dll
>
> Also Cerebrum.Integrator.dll has some meta information implemented.
> Each node(object) at the same time can be considered as collection of
> related objects. If we take two nodes and call one 'columns collection'
> then call another 'rows collection' as result we get a 'table' of rows.
> Table is a node related to two another nodes - columns and rows. Each
> row is a node too. And as node each row has links to some related
> nodes. Columns collection contans links to some another nodes. They are
> AttributeDescriptors. Attribute Descriptor knows about identifier
> (color) of corresponding attribute. So when we have a rows collection
> and columns collection we can navigate to row attribute instance. It is
> a logical model of 'table'. Also there table of tables is exists.
>
>
> > I was refering to principle as what set of concepts permit to guarantee
> > that the system is for instance less hardware dependent..
>
> I think it is absolutelly hardware independent - on the logical
> abstraction level. As implementation it depends from Win32 and .NET .
> the same DB storage file works ok with .NET 1.1 or .NET 2.0 compiled.
> So DB storage file format is independent from .NET version or from user
> DLLs version where methods of user objects is implemented. It is
> because of the low logic level as single direction graph.
>
> > > > Don't this approach increase resource consumption at linkage editing
> > > > time. (compile/link/run?)
> > >
> > > may be, may be not. it is relative to point of view. i afraid about run
> > > time more then about devtime.
> > Maybe/maybe not? Does not this question require more particular
> > attention if you think that a system would be more performant.... In
> > most computing cycles the primary ressource consumer is not run time
> > (execution time) but more compile and link edit time.
>
> Hm, i think that a run time and development time (not compile and link)
> are matter.
>
> > If your primary worry is devtime, it is an additional reason to spend
> > it carefully by using sound logical principles on which to build on.
>
> yes.
>
> > Do not base abstract reasonning on current implementations
> > technologies(DOT NET).
>
> It is not logical restriction. It is by design. Even more, the Cerebrum
> Kernel is written on C(not C++).
> .NET and kernel glue is written on MC++ If i need i can port kernel to
> some another plaform.
>
> > By their semantics and current capabilities,
> > they should not guide your reasonning. The opposite should happen.
>
> yes. i understand.
>
> > I have explained to you that metadata in RM would be treated at compile
> > time only.
> > run time is decomposed into compile/link/execute. The method you
> > suggest requires definitions to be executed no matter what. In RM,
> > definitions, value and operator constraints are implemented at compile
> > time only.
>
> I think that RM is theoretical concept and can't have a compile time,
> is it?
> I am about real compile time in real PC.
True but the nature of the abstract concept of domain makes it possible to segregate data by intersection at compile time...

> >There are unfortunately no RDBMS existing today
>
> Too bad for RM ))
Too bad for all of us...If RM was implemented we would be gaining orders of magnitude in performance as opposed to current SQL DBMS

>
> > > My DB also allows use many abstract models. For example, i implemented
> > > simple RDB like database to store configuration metadata.
> > I believe you implemented a SQL Table like DB.
>
> Sorry for bad english. I want to say simple RDB-like database. A
> database which similar but not equal to RDB. I talk about this earlier
> when describe how table is implemented as sub-graph
>
> > > No it is not needed load all network into RAM. You just need to load
> > > one instance which holds count attribute. that is all.
> > So you store the count value? .
>
> Yes. Collection stores value inside own instance. It is one of
> optimization. The most optimization i done - O(1) when searching object
> instance by it ID.
But do you treat NULL values? How do you count all instances that satisfy a specific condition? If it is statically stored in a point in time?

> > Again there's no such thing as an RDBMS already implemented.
>
> Ok then when i say 'RDBMS' - read 'table-based DBMS'. For me while it
> don't exists yet it is no matter if MS SQL truely RDBMS or not. It just
> called RDBMS.
>
> WBR,
> Dmitry
Received on Wed Jul 05 2006 - 19:29:49 CEST