XML as configuration files

[Alain R.]

Hi,

I would like to create a small application which will use a XLS file as
database.

for that purpose, i was thinking to use XML files as configuration files
for my application in order to make it more flexible.

for example, i would like to have :
A - 1 XML file to hold on software and their status (standard, option
standard,...)
this file could be updated based on new software detection.

B - 1 XML file to hold on all users and for each of them the list of
software they can use (let's say validated software)

C - 1 XML file to hold on all application settings (color, language, ...)

D - 1 XML file to hold on all results of my work / application work.

basically application should open XLS file, do some work and write a
report into the result.xml file.

as my XLS file includes around 25.000 records, you can easily guess that
my users.xml file (xml from B) will be quite huge (maybe 1500 users * 25
softwares).

DO you think that it's the best how to do it ?
i do not want to hear anything about a database as i can not get one
(the purpose of this application is to work with a XLS file as input)

do you have any suggestions ?

thanks a lot,

Alain

 

[Marc Gravell]

Xml as a data format... in the absense of a database, it'll do... but
your XLS comments only seem to apply to the XLS bit... is there
anything stopping you using SQL Server express (or other similar)
instead of the xml files? I did see your comment, but it wasn't 100%
clear to me. It seems like you are really describing 2 databases (and
perhaps an import/export/sync/whatever process)...

Note that for this volume (using xml) you should really be using
XmlReader / XmlWriter (not XmlDocument), otherwise life might get
painful. Of course, this then limits your ability to cross-reference
data at runtime. Another option is to represent the data in classes at
runtime, but use serialization (XmlSerializer or
DataContractSerializer) to read/write the files (this will handle the
XmlReader grunginess for you).

I know you state that you are fixed to Excel, but red warning flag: if
the xls contains 25000 rows, remember that you can only have 65536
rows max - so you are 40% of the way to it going "pop". If it needs to
scale, this might not be wise.

As for the range of files - again, it depends on what you need... it
might be perfectly reasonable to put all the data into 1 file, and
perhaps use standard .NET configuration files (user section) for the
app-colours etc. If the xml files turn out to be huge, perhaps
consider sticking a gzip stream (either from System.Compression, or
#ZipLib) between the FileStream and the XmlReader/XmlWriter - this
will have a significant effect on disk size, at a relatively small CPU
cost.

Marc