You're going to have to maintain something at some point... either sprocs or
your own code.
It sounds like you really do have a relational database (at least
conceptually) - even though you apparently don't want to store it physically
in a database product like SQL Server. If that's true (your data really is
relational), then depending on how you use the data, it might become much
more of a maintentance problem to work with your relational data in XML vs
in a true relational database.
If you are simply not wanting to take the time to do it using a tool
designed to work with relational data (SQL Server, Access, etc), then you'll
have to take the time to roll your own code that will do what the true
database would have made easy (e.g., a SQL statement executed against a
table is much simpler to write and maintain than your own code that loops
through flat data...).
Of course your not telling us much about how you plan to use the data and
the nature of the data limits our ability to offer you much specific
guidance.
Good luck
-G
"George Durzi" <gd****@hotmail.com> wrote in message
news:eQ*************@tk2msftngp13.phx.gbl...
One one hand, the SQL way is familiar, but as you said, it becomes a pain
to maintain the stored procedures and methods, etc.
The Xml alternative would be an interesting and different way to do this (
which is more preferable than sitting down to write a 50 parameter stored
proc ;)
I'll probably have about 1000 records per year. Does that qualify as a lot
of records, or is it still a manageable quantity for doing searches, etc.?
Thank you Bryan
"Bryan" <an*******@discussions.microsoft.com> wrote in message
news:7F**********************************@microsof t.com... George,
There are always advantages and disadvantages to everything... if you're going to have a lot of records... you'll have to deal with the pain
of keeping up stored procedures and keeping evrything in SQL. If the
amount of records are going to be small then I'd go xml (This is what I've been
hearing). Searches through xml start to get slower as you create bigger
amounts of data. SQL is considerably faster through searches as your data
is bigger.