XML Database

  • Thread starter Thread starter Jonathan Wood
  • Start date Start date
J

Jonathan Wood

I'm creating a simple site that will display photos, which I'd like to
organize and display.

A full database would be WAY overkill for this site. I'm wondering if an XML
files could be used instead as a simple database. I know it wouldn't be as
efficient, but if I can open, read, search, modify and save the contents, it
seems like it would work pretty good for me.

Concurrency would be nice too, although I don't really think that's
necessary for this current site.

Thanks for any tips.

Jonathan
 
I'm creating a simple site that will display photos, which I'd like to
organize and display.

A full database would be WAY overkill for this site. I'm wondering if an XML
files could be used instead as a simple database. I know it wouldn't be as
efficient, but if I can open, read, search, modify and save the contents, it
seems like it would work pretty good for me.

Concurrency would be nice too, although I don't really think that's
necessary for this current site.

Thanks for any tips.

Jonathan

XML data is fine. Just need to remember:

(1) There is no support for more than one user modifying the data at
any one time.

(2) Don't have the convenience of the SQL language for retrieving data
where joined tables are involved.

ASP.NET does have good support for typed datasets using XML and in
simple cases XmlDataSource for binding visual controls.

I find it useful to create DataSets in the App_Code directory. There
you can define primary keys with auto-increment and relations between
tables. Then create a class file named as being a DataObject and put
all your db handling in there. Use ObjectDataSources rather than
XmlDataSources because the latter object only reads attribute based
fields (unless you know how to write Xsl transforms). Typed datasets
are in node format.

A good case for XML is data that is largely static and read-ony to
ordinary users but with edting facilities for a site administrator.

Performance wise I don't see any problem unless the volume of data is
very large which would probably warrant SQL server anyway.

HTH
 
Mark,
In addition to Stan's comments, I'm a firm believer in using the correct
tool for the job.
Indeed.

You say "a full database would be WAY overkill for this site".. I'm not
really sure what you mean by a "full" database,

Microsoft SQL Server 2005, for example.
but is there any real reason that you can't use a bog-standard Jet
database? Instantly, you have all of the advantages of ADO.NET, plus all
the concurrency you could want...

Here's a couple of reasons off the top of my head: I don't know anything
about Jet database, probably don't have it, don't know how to use it, don't
want to spend a week learning it, and suspect it would also be overkill for
my needs.
Even if the database contained only one table, it would still be much
better than using a text file...

So then you appear to disagree with Stan's comments?

Thanks.

Jonathan
 
Stan,
XML data is fine. Just need to remember:

(1) There is no support for more than one user modifying the data at
any one time.

(2) Don't have the convenience of the SQL language for retrieving data
where joined tables are involved.

ASP.NET does have good support for typed datasets using XML and in
simple cases XmlDataSource for binding visual controls.

Cool. All I really want to do is organize the heirarchy of some images and,
rather than hard code them in the HTML files, thought it would be cool to
simply edit an XML file. Not only would this be quicker, but it gives me the
option of writing code to make it easy for my client to modify the data as
well.

I suppose it's possible that two people could attempt to modify the data at
the same time, but in the extremely unlikely event that happens, it would be
okay if it just overwrote whatever else had been done.

It could mean the difference between requiring my client to upgrade his
account to simply modifying the one he has.
A good case for XML is data that is largely static and read-ony to
ordinary users but with edting facilities for a site administrator.

That's me.

Thanks.

Jonathan
 
I was actually aware that it was the Access database. I just wasn't sure (in
fact, I have no idea) what is available to use it from ASP.NET.

At any rate, it would be overkill for my needs.

Thanks.
 
Mark,
<rolls eyes> OK...

What the hell does that mean? I said from the start that a full database
would be WAY overkill. You question almost every term I use and push forward
with database recommendations. (And make dubious statements that there is no
such thing as an Access database.)

Everything is cool with the exchange unless you have an attitude about me
not needing a database. Then, I think you're up in the night.

Jonathan
 
Someone stating there is no such thing as an Access database is not a
dubious statement it is a fact. Access is only referred to as a database
because morons (like you are starting to sound like) do not understand the
difference between a GUI and the actual JET database engine. I suppose we
can thank the Micromoron Marketing fools but still, people just get
downright tired of explaining to lazy fools over and over again.

So regardless, you're really being unnecessarily argumentative Jonathan.
Developers have responded to your concerns now you should accept the advice
or go do your own thing. Either way you and only you manage the consequences
and IMO some very pertinent concerns have been brought to your attention.
Don't ya think?

<%= Clinton Gallagher
 
AFAIC, the only morons are those who think they understand my requirements
better than I do. And this nonsense about Access is simply a game of
semantics. Some people think it's more important to argue about semantics
than discuss the issue being raised, and then even start calling names when
everything they say is not blindly accepted.

Oh well, thanks to one reply, this thread has served a useful purpose to me.
I'm out of here.

Jonathan
 
Someone stating there is no such thing as an Access database is not a
dubious statement it is a fact. Access is only referred to as a database
because morons (like you are starting to sound like) do not understand the
difference between a GUI and the actual JET database engine. I suppose we
can thank the Micromoron Marketing fools but still, people just get
downright tired of explaining to lazy fools over and over again.

It is reasonable to make the distinction between Microsoft Access as
an application and the underlying database that it connects to but we
shouldn't be too hard on those who tend to refer to the two entities
interchangeably.

Microsoft themselves do this. The data source component introduced in
Framework 2 that connects to a JET database is called an
AccessDataSource and the help documentation contains the following
words:

"Represents a Microsoft Access database to data-bound controls."

However it may become necessary to emphasise the distinction if this
misleads anyone into thinking that using an AccessDataSource requires
Microsoft Office to be installed or that a knowledge of MicroSoft
Access is required. In reality the only difference between using this
type of component and SqlDataSource is in the connection strings and
some of the SQL syntax (e.g. parameters can't be named in the SQL
command text, only "?" is allowed).

HTH
 
Back
Top