C# pure xml database?

[BA]

Hello,

Anyone know of an open source C# pure xml database that is available?

I've done some looking around and can't locate anything.

Thanks in advance,

BA
http://biztalkia.blogspot.com/

[Sharon]

Give this one a try.
It's native XML and open source:
http://exist.sourceforge.net/

"BA" <bi***************@gmail.com> wrote in message
news:71**************************@news.microsoft.c om...

Hello,

Anyone know of an open source C# pure xml database that is available?

I've done some looking around and can't locate anything.

Thanks in advance,

BA
http://biztalkia.blogspot.com/

[BA]

Hello Sharon,

Thanks for the link but I am hoping for something out there written in C#,
this one looks Java based.

BA
http://biztalkia.blogspot.com/

Give this one a try.
It's native XML and open source:
http://exist.sourceforge.net/
"BA" <bi***************@gmail.com> wrote in message
news:71**************************@news.microsoft.c om...

Hello,

Anyone know of an open source C# pure xml database that is available?

I've done some looking around and can't locate anything.

Thanks in advance,

BA
http://biztalkia.blogspot.com/

[Michael Nemtsev]

Hello BA,

What are the features you are looking for? What's wrong with using DataSet
and serialize it or SQLExpress they both can keep data in XML

B> Hello,
B> Anyone know of an open source C# pure xml database that is available?
B> I've done some looking around and can't locate anything.
B> Thanks in advance,

---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[BA]

Hello Michael,

Its for a proof of concept.

We'd like to experiment with the different types of storage available (such
as fragments stored as data trees, etc) and using xml-like queries for retrieving
xml fragments rather than having to work with an entire document. This project
deals with a large xml file to describe a customer + purchased product +
historical data, etc which can become cumbersome to move around when you
want to work with it. Retrieving, updating, adding and storing fragments
might be a nice way to handle it.

All that said, there is alot I dont know about xml db's which is why I'd
like to see an open source C# implimentation to judge whether there really
are any advantages to it and also the ability to extend it since I am sure
it wont have the array of capabilities I need, ie, wont meet the 80-20 rule.

BA
http://biztalkia.blogspot.com/

Hello BA,

What are the features you are looking for? What's wrong with using
DataSet and serialize it or SQLExpress they both can keep data in XML
B>> Hello,
B>> Anyone know of an open source C# pure xml database that is
B>> available?
B>> I've done some looking around and can't locate anything.
B>> Thanks in advance, ---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour
"At times one remains faithful to a cause only because its opponents
do not cease to be insipid." (c) Friedrich Nietzsche

[Mark Rae]

"BA" <bi***************@gmail.com> wrote in message
news:71**************************@news.microsoft.c om...

are any advantages to it and also the ability to extend it since I am sure
it wont have the array of capabilities I need, ie, wont meet the 80-20
rule.

I've never thought of XML as anything other than a very flexible data
transport - it's certainly not a database, nor was it ever intended to be
one.

If you were writing a letter, you wouldn't use Excel because that simply
wouldn't be the right product. You could, of course, write a letter in Excel
if you really wanted to... Same goes for using XML as a database.

If you need a database solution, then use a database.

[BA]

Hello Mark,

While I understand your point (since I need easily accessible storage), I
dont need a database solution, I need an XML solution.

My intention is to investigate how I could use and XML database as a tool
to work on large amounts of XML more efficently.

Let me give you an example to illustrate my point:

Lets say a customer changes an address and I need to check if the new address
is within a servicable area.

There is a 250k xml file associated with the customer (or a large array of
database columns), but all I want is to check an address node with a business
rule inside BizTalk's Business Rules engine. Rather than store all the data
for the customer relationally and have to return it (or part of it) as XML,
might it be more efficent to just pull that node from the XML store, validate
it, update it and slap it back in?

Those are the kinds of questions I am trying to answer.

Dont get me wrong, I'm not trying to sound like an advocate here, I am interested
in experiementing, thats all.

BA
http://biztalkia.blogspot.com/

I've never thought of XML as anything other than a very flexible data
transport - it's certainly not a database, nor was it ever intended to
be one.

If you were writing a letter, you wouldn't use Excel because that
simply wouldn't be the right product. You could, of course, write a
letter in Excel if you really wanted to... Same goes for using XML as
a database.

If you need a database solution, then use a database.

[Mark Rae]

"BA" <bi***************@gmail.com> wrote in message
news:71**************************@news.microsoft.c om...

While I understand your point (since I need easily accessible storage), I
dont need a database solution, I need an XML solution.
Not from what you say below...
There is a 250k xml file associated with the customer (or a large array of
database columns), but all I want is to check an address node with a
business rule inside BizTalk's Business Rules engine. Rather than store
all the data for the customer relationally and have to return it (or part
of it) as XML, might it be more efficent to just pull that node from the
XML store, validate it, update it and slap it back in?
Without seeing your schema, I can pretty much guarantee that you're NEVER
going to get anywhere close to the speed of a proper database in this
scenario.
Dont get me wrong, I'm not trying to sound like an advocate here, I am
interested in experiementing, thats all.

I understand that, but I'm pretty certain you're wasting your time...

[Michael Nemtsev]

Hello BA,

B> My intention is to investigate how I could use and XML database as a
B> tool to work on large amounts of XML more efficently.

Take into account that XML is not a tons of text data, but a stuctured
and validated data.
It brings you that 1mb XML file needs 30mb RAM to be parsed

B> Let me give you an example to illustrate my point:
B> Lets say a customer changes an address and I need to check if the new
B> address is within a servicable area.
B> There is a 250k xml file associated with the customer (or a large
B> array of database columns), but all I want is to check an address
B> node with a business rule inside BizTalk's Business Rules engine.
B> Rather than store all the data for the customer relationally and have
B> to return it (or part of it) as XML, might it be more efficent to
B> just pull that node from the XML store, validate it, update it and
B> slap it back in?
B>
B> Those are the kinds of questions I am trying to answer.

Weak of this solution is that you are trying to map customers data directly
to your DB data. You need not to check all your
customers data for DB in your case.
I suggest to create cannonical XML format, where map your customer's data
and then validate it.

---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[Bruce Wood]

While I agree with the other posters here that storing XML directly is
probably not what you want (given what you've told us), do you know
that SQL Server 2005 has native XML columns, complete with XQuery
searches within the XML stored there?

I've never tried it myself, but apparently it's there.

I do intend to use this funcitonality someday, but not for what you
want to use it for. I see it as a good solution for creating an archive
of documents moving in and out of our (web services) system. As a live
data source, I would avoid it like the plague, but that's just me.

[Marcin Grze;bski]

BA napisa?(a):

Hello Sharon,

Thanks for the link but I am hoping for something out there written in
C#, this one looks Java based.

BA
http://biztalkia.blogspot.com/

If you're looking for C# DB with XML I/O, then
look for DataSet in .NET Documentation.

--
Marcin Grze;bski
mg*******@taxussi.no.com.spam.pl

[BA]

Hello Bruce,

Good Point.

SQL 2005 has xml as a data type. That gives me a good reason to toy with it.
BA
http://biztalkia.blogspot.com/

While I agree with the other posters here that storing XML directly is
probably not what you want (given what you've told us), do you know
that SQL Server 2005 has native XML columns, complete with XQuery
searches within the XML stored there?

I've never tried it myself, but apparently it's there.

I do intend to use this funcitonality someday, but not for what you
want to use it for. I see it as a good solution for creating an
archive of documents moving in and out of our (web services) system.
As a live data source, I would avoid it like the plague, but that's
just me.

[Nick Hounsome]

"BA" <bi***************@gmail.com> wrote in message
news:71**************************@news.microsoft.c om...

Hello Bruce,

Good Point.
SQL 2005 has xml as a data type. That gives me a good reason to toy with
it.

Do you really want to make it impossible to port your app to another (maybe
free) database?

You will be limiting your market.

[BA]

Hello Nick,

Its custom built for a client, they are all Microsoft so its no problem.
I cant leverage the code even if I wanted to since I've signed a bunch of
confidentiality agreements.

Cheers,
BA
http://biztalkia.blogspot.com/

"BA" <bi***************@gmail.com> wrote in message
news:71**************************@news.microsoft.c om...

Hello Bruce,

Good Point.
SQL 2005 has xml as a data type. That gives me a good reason to toy
with
it.

Do you really want to make it impossible to port your app to another
(maybe free) database?

You will be limiting your market.

[William Stacey [MVP]]

Sql 2005 Express is free.
--
William Stacey [MVP]

"Nick Hounsome" <nh***@nickhounsome.me.uk> wrote in message
news:zL*******************@fe1.news.blueyonder.co. uk...
|
| "BA" <bi***************@gmail.com> wrote in message
| news:71**************************@news.microsoft.c om...
| > Hello Bruce,
| >
| > Good Point.
| > SQL 2005 has xml as a data type. That gives me a good reason to toy
with
| > it.
| >
|
| Do you really want to make it impossible to port your app to another
(maybe
| free) database?
|
| You will be limiting your market.
|
|

[Kevin Spencer]

> Do you really want to make it impossible to port your app to another

(maybe free) database?

You will be limiting your market.
This statement makes several assumptions which are just plain wrong. First,
it assumes that a SQL Server database cannot be exported to another format
if necessary. SQL Server has more capability for this sort of thing than any
other database, with the possible exception of Oracle (I haven't been
keeping up with Oracle lately, so I can't make the call there).

Second, it assumes that the application will be dependent upon the database
format. A well-designed application is loosely-coupled to the database
layer.

Finally, let's for a moment imagine that what you are saying is correct (I
have a vivid imagination). What database would *not* have the same effects
you describe (which I deny) as using SQL Server?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
To a tea you esteem
a hurting back as a wallet.
"Nick Hounsome" <nh***@nickhounsome.me.uk> wrote in message
news:zL*******************@fe1.news.blueyonder.co. uk...
"BA" <bi***************@gmail.com> wrote in message
news:71**************************@news.microsoft.c om...

Hello Bruce,

Good Point.
SQL 2005 has xml as a data type. That gives me a good reason to toy with
it.

Do you really want to make it impossible to port your app to another
(maybe free) database?

You will be limiting your market.

[Nick Hounsome]

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uL**************@TK2MSFTNGP12.phx.gbl...

Do you really want to make it impossible to port your app to another
(maybe free) database?

You will be limiting your market.
This statement makes several assumptions which are just plain wrong.
First, it assumes that a SQL Server database cannot be exported to another
format if necessary.

No - It assumes that code designed to retriev data from a database with XML
support will not work with a database that hasn't got it.
SQL Server has more capability for this sort of thing than any other
database, with the possible exception of Oracle (I haven't been keeping up
with Oracle lately, so I can't make the call there).

Second, it assumes that the application will be dependent upon the
database format. A well-designed application is loosely-coupled to the
database layer.
Through a bunch of code that you would have to change.
Finally, let's for a moment imagine that what you are saying is correct (I
have a vivid imagination). What database would *not* have the same effects
you describe (which I deny) as using SQL Server?

Any database that doesn't directly support XML

[Kevin Spencer]

Well, Nick, you may have something there, but let's not forget that XML can
be easily transformed to just about anything you want. That includes text.
Assuming that the OP wants to work with XML *as* XML, the only dependency
should be in the business layer (if the app is well-designed). So, exporting
XML from SQL Server to any other database as text is certainly an option. In
addition, exporting the XML data to any other database in any other format
is also an option.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A brute awe as you,
a Metallic hag entity, eat us.
"Nick Hounsome" <nh***@nickhounsome.me.uk> wrote in message
news:Hp*******************@fe1.news.blueyonder.co. uk...

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uL**************@TK2MSFTNGP12.phx.gbl...

Do you really want to make it impossible to port your app to another
(maybe free) database?

You will be limiting your market.

This statement makes several assumptions which are just plain wrong.
First, it assumes that a SQL Server database cannot be exported to
another format if necessary.

No - It assumes that code designed to retriev data from a database with
XML support will not work with a database that hasn't got it.

SQL Server has more capability for this sort of thing than any other
database, with the possible exception of Oracle (I haven't been keeping
up with Oracle lately, so I can't make the call there).

Second, it assumes that the application will be dependent upon the
database format. A well-designed application is loosely-coupled to the
database layer.

Through a bunch of code that you would have to change.

Finally, let's for a moment imagine that what you are saying is correct
(I have a vivid imagination). What database would *not* have the same
effects you describe (which I deny) as using SQL Server?

Any database that doesn't directly support XML

[BK]

Bruce,

I am working on something similar to what you "intend" to do. The (final)
system will have a cataloging component that would essentially be a
Folder/File structure. So far I have coded the Iteration over a selected
folder and am displaying the data/structure in a TreeView (VB.NET 2005). I
then serialize the Treeview and store the serialized XML in a SQL 2005 XML
Column. I can also retrieve an entire XML (one record, that is) and rebuild
the TreeView.

Never having worked with XML, I think I could make the serialized XML
smaller. Presently, I am displaying File Name and related attributes
(Creation Date, Size etc) as child nodes to the FileName Node. This makes the
serialized XML large. If I knew more about XML, I would have been able to
put them in as Attributes and display them "On Click" or something.

What I need now - is for help on how to build a xQuery to select FRAGMENTS
from all XMLs in the Database – filtered/searched on say, a File Name, and
return those (xml fragments) to the Client (VB Interface).

Does XQuery have a client-Side XQuery Implementation? Or will I have to work
with Stored Procedures? Any XML related suggestions on building the TreeView
and developing and executing the XQuery would be much appreciated.

Thanks.

"Bruce Wood" wrote:

While I agree with the other posters here that storing XML directly is
probably not what you want (given what you've told us), do you know
that SQL Server 2005 has native XML columns, complete with XQuery
searches within the XML stored there?

I've never tried it myself, but apparently it's there.

I do intend to use this funcitonality someday, but not for what you
want to use it for. I see it as a good solution for creating an archive
of documents moving in and out of our (web services) system. As a live
data source, I would avoid it like the plague, but that's just me.