ODB's and C#

[Logician]

Are there any ODBMS's that work well with C#?

eg storing Uri as a database type (CustUri Type(Uri)) and then queries
such as select CustUri.AbsolutePath should be used).

I would find this useful. I know Oracle software has some object
functions, but it would be nice if something exists to handle C#
objects naturally.

[Peter Morris]

www.db4o.com - I ruled it out due to the runtime license costs and went for
an object->rdbms mapper (and more) at www.capableobjects.com instead.

Pete

[Logician]

On Aug 25, 5:17 pm, "Peter Morris" <[e-mail]:

www.db4o.com- I ruled it out due to the runtime license costs and went for
an object->rdbms mapper (and more) atwww.capableobjects.cominstead.

Pete

I'll try this.

[Alun Harford]

Logician wrote:

Are there any ODBMS's that work well with C#?

eg storing Uri as a database type (CustUri Type(Uri)) and then queries
such as select CustUri.AbsolutePath should be used).

I would find this useful. I know Oracle software has some object
functions, but it would be nice if something exists to handle C#
objects naturally.

You would need a OODBMS for that. db4o is apparently good (I've not used
it though).

Otherwise, you're going to hit the object relational impedance mismatch.

An ORM (such as NHibernate) is the other option...

Alun Harford

[Logician]

On Aug 25, 7:17 pm, Alun Harford <[e-mail]:

Logician wrote:

Are there any ODBMS's that work well with C#?

eg storing Uri as a database type (CustUri Type(Uri)) and then queries
such as select CustUri.AbsolutePath should be used).

I would find this useful. I know Oracle software has some object
functions, but it would be nice if something exists to handle C#
objects naturally.

You would need a OODBMS for that. db4o is apparently good (I've not used
it though).

Otherwise, you're going to hit the object relational impedance mismatch.

An ORM (such as NHibernate) is the other option...

Alun Harford

I am thinking of using Java for the OO work since there is a lot of
support for Java OO and OODBMS, eg with ORACLE. It is just a let down
that the IDE's for Java are so bad. I think the online interaction for
C# is good and also the IDE which are all pros for c#.

I really want a fully OO type of database so that I store a type of
data by meaning, eg a type Price which has attributes bargain, low,
high, budget etc. This will lead into semantics which I want as one
aspect but also easier processing of complex objects. Relational
models are really old now, and I think the web of data (Web 3) will
really strain relational models. I know LINQ is touted by MSFT as the
next best thing, but I am not convinced so far.

[Pavel Minaev]

On Aug 25, 11:06*pm, Logician <[e-mail]:

I really want a fully OO type of database so that I store a type of
data by meaning, eg a type Price which has attributes bargain, low,
high, budget etc. This will lead into semantics which I want as one
aspect but also easier processing of complex objects. Relational
models are really old now, and I think the web of data (Web 3) will
really strain relational models. I know LINQ is touted by MSFT as the
next best thing, but I am not convinced so far.

LINQ is absolutely orthogonal to the whole relational / object
dichotomy - if anything, the fact that you can do LINQ queries against
in-memory collections of plain .NET objects should be proof enough.
db4o supports LINQ queries, by the way; see
http://www.codeproject.com/KB/databa..._for_db4o.aspx for an
example.

If you rather mean ADO.NET Entity Framework (aka LINQ to Entities),
then it is, indeed, just another ORM, and not particularly powerful
one at that.

[Logician]

On Aug 26, 3:17*pm, Pavel Minaev <[e-mail]:

On Aug 25, 11:06*pm, Logician <[e-mail]:

I really want a fully OO type of database so that I store a type of
data by meaning, eg a type Price which has attributes bargain, low,
high, budget etc. This will lead into semantics which I want as one
aspect but also easier processing of complex objects. Relational
models are really old now, and I think the web of data (Web 3) will
really strain relational models. I know LINQ is touted by MSFT as the
next best thing, but I am not convinced so far.

LINQ is absolutely orthogonal to the whole relational / object
dichotomy - if anything, the fact that you can do LINQ queries against
in-memory collections of plain .NET objects should be proof enough.
db4o supports LINQ queries, by the way; seehttp://www.codeproject.com/KB/database/LINQ_for_db4o.aspxfor an
example.

If you rather mean ADO.NET Entity Framework (aka LINQ to Entities),
then it is, indeed, just another ORM, and not particularly powerful
one at that.

I am using db4o (or trying to) and it apparently stores whole objects
without any further defintion, eg

IObjectContainer db = Db4oFactory.OpenFile( ...)

db.Store(myObject)

Which is what I want.

I am still wondering why 90% of all dbms access is relational, when
that technology is very old (at least 30 years old). Is this just the
commercial influence of Oracle, Microsoft and others who have
financial interests in keeping systems working in rdbms technologies?

[Pavel Minaev]

"Logician" <sa***@logicians.comwrote in message
news:f7**********************************@59g2000h sb.googlegroups.com...

I am using db4o (or trying to) and it apparently stores whole objects
without any further defintion, eg

IObjectContainer db = Db4oFactory.OpenFile( ...)

db.Store(myObject)

Which is what I want.

It's all well and good, but db4o is positioned as a solution for embedded
and other low-footprint projects. What are its scalability properties? What
about concurrent access - how many active connections to the database can it
sustain? What happens if I start hitting it with 100 queries/second? 1000?

I am still wondering why 90% of all dbms access is relational, when
that technology is very old (at least 30 years old). Is this just the
commercial influence of Oracle, Microsoft and others who have
financial interests in keeping systems working in rdbms technologies?

To my knowledge, there are still no fully OODBMS solutions that match the
raw performance and scalability of RDBMS solutions. The reason is simple -
relational model is very well understood, and existing products have built
upon the old, mature, proven solutions (if you ask the vendors, you'll find
out that the core of their query analyzers is often still based around the
code of a few original RDBMS pioneers of 1970s).

[Logician]

On Sep 6, 2:02 pm, "Pavel Minaev" <[e-mail]:

"Logician" <[e-mail] in message

news:f7**********************************@59g2000h sb.googlegroups.com...

I am using db4o (or trying to) and it apparently stores whole objects
without any further defintion, eg

IObjectContainer db = Db4oFactory.OpenFile( ...)

db.Store(myObject)

Which is what I want.

It's all well and good, but db4o is positioned as a solution for embedded
and other low-footprint projects. What are its scalability properties? What
about concurrent access - how many active connections to the database can it
sustain? What happens if I start hitting it with 100 queries/second? 1000?

I do not know. I am still trying to get it work with one query.

>

I am still wondering why 90% of all dbms access is relational, when
that technology is very old (at least 30 years old). Is this just the
commercial influence of Oracle, Microsoft and others who have
financial interests in keeping systems working in rdbms technologies?

To my knowledge, there are still no fully OODBMS solutions that match the
raw performance and scalability of RDBMS solutions. The reason is simple -
relational model is very well understood, and existing products have built
upon the old, mature, proven solutions (if you ask the vendors, you'll find
out that the core of their query analyzers is often still based around the
code of a few original RDBMS pioneers of 1970s).

You make a good point.

However with RDF about to be mainstream, we need Object databases.