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

Dmitry Shuklin wrote:
> Hi Cimode
> > > Primary purpose - modeling neural system with up to 2000000000 neurons.
> > > 1 neuron == 1 object instance.
> > So you are saying that a specific implementation is the end of a entire
> > logical model based on applied mathematics (as a reminder, some people
> > have worked for more than 40 years onto creating RM). Don't you think
> > this is hasty?
>
> Why you think that i am ignoring these 40-60 years? Or why you think
> that i spent few days to my research? )) Of course i am using all that
> i can use. But RM is not unique model which can be used.
What other similar models are you refering to?

> > Good support for data type is the ability for instance to apply
> > specific querying operators on the data belonging to that data type.
>
> I am not implementing complete and independent DB. My application is
> based on Microsoft .NET Framework types library. I don't make my own
> programming language. C# is supported. My OODB is a dll which can be
> used from .NET So it is inherited all specific operations from standart
> .NET types. And all .NET functionality can be used when application
> working with DB. But inside persistent classes delegates and events are
> not supported.
I see...
> > Can you create a data type *neuron* that you can manipulate at wish?

> Of course. Just need to create yer anoter .NET class.
All right..What kind of operations are currently supported over neurons data type?

> > for instance lets say neuron has a property *wavelength*...can you you
> > find all neurons with specific wavelength? superior to specific
> > wavelength?
>
> yes, but i don't support indexes for properties. current version
> supports only ObjectIDs index. so if needed search between count of
> objects you should use your own index implementation. It is very easy
> to use System.Collection.Hashtable and serialize it as part of some
> persistent object, for example.
>
> > What capability of operations involving neurons can your
> > system handle? What kind of behavior do you aim at tracking in storing
> > neurons?

> System can create new object instances, dereference ObjectID to object
> reference, remove reference to persistent object from current context.
> When all references to some instance are removed from all contexts this
> instance is removed from storage.
By operations I mean operators that can be applied to data of neuron data type...
Can you for instance apply equal operator to state that 2 neurons are equal? Can you find all neurons that fit a particular description, 2 particular description...How do you find for instance ALL neurons that have a specific wavelength but not a particular configuration (assuming wavelength and configuration being properties applyable of neuron)?

> also i support undo/redo transactions.
How do you support read consistency...For instance what happens when you begin a insert transaction with committing over a table then run a select over the same table...What kind of version of the table does you select return?

> persistent objects can contain methods. one persistent object can
> invoke method from another persistent object. objects are instantiated
> in ram by demand. so it is not needed to load all instances from
> storage file at system startup.
>
> > domain are RM counterpart of mathematical ensembles of values. For
> > instance, let's say you have ensemble of values (neuron1, neuron2,
> > neuron3, neuron4, neuron5). Can you define a data type involving only
> > (neuron2, neuron4, neuron5) ? How? When(at execution time? compile
> > time?)
>
> I don't need this feature. All instances are objects derived from
> System.Object. objects can implement some interfaces. If object
> implement some interface which needed in some context - you can use
> this instance. If not - you can check this and decide what you want to
> do with this object. Constraints can be implemented in property getters
> and setters. It is not a RM database at all.
Are you stating this is always done at run time and not by definition...Mmmm, RM does not require to run anything in this kind of situation. This kind of segregation is done at compile time which saves resources...

> You should develop your class by C#, compile it. Register assembly and
> types in DB and then you can use your types. If you will use structured
> serialization it is ok to recompile assembly from one run to another.
I do not know C# but I have complied classes in VB DOT NET. Running it is one thing but making it a DBMS is another thing.

> WBR,
> Dmitry
Received on Tue Jul 04 2006 - 17:46:47 CEST