locate static data in xml file vs db table

How do people see the security of locating static data (such as config
settings) in an XML file (a copy is located on each web-server, or a single
copy is located on a specific server) , versus locating this data inside the
db ?
An XML file that contains all app config settings is much easier to maintain
and track from the standpoint of source-code-control , and it is much easier
to apply changes to settings in production environments (just swap the XML
file and restart the web-servers).
The replication and other redudancy advantages accorded data inside SS are
not really necessary for static, load-on-app-start, config settings.
If not possible for data in an XML file to achieve the security of a data in
a db , one option would be to locate the XML file in a SS05 col of XML
datatype.
Anyone have real-world experience making this sort of trade-off decision ,
or any insights ?
Thanks.When did go through a similar exercise for our application. One of the
things that we considered was to look at configuration as something that is
"configurable". This means that the location of the configuration file
should be abstracted from your code so that you are free to move it around.
This is where the Configuration Application Block from Microsoft comes into
play:
http://msdn.microsoft.com/library/d...i
g.asp.
This block abstracts the ability to read and write from the configuration
file and from a deployment perspective, the configuration can be in XML or
in SQL Server. Maybe future editions of this block might put it in an SQL2K5
XML column, but the block would abstract it from you and you would always
have a consistent way of programming.
--
HTH,
SriSamp
Email: srisamp@.gmail.com
Blog: http://blogs.sqlxml.org/srinivassampath
URL: http://www32.brinkster.com/srisamp
"John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message
news:OnfTXLs0FHA.3812@.TK2MSFTNGP09.phx.gbl...
> How do people see the security of locating static data (such as config
> settings) in an XML file (a copy is located on each web-server, or a
> single copy is located on a specific server) , versus locating this data
> inside the db ?
> An XML file that contains all app config settings is much easier to
> maintain and track from the standpoint of source-code-control , and it is
> much easier to apply changes to settings in production environments (just
> swap the XML file and restart the web-servers).
> The replication and other redudancy advantages accorded data inside SS are
> not really necessary for static, load-on-app-start, config settings.
> If not possible for data in an XML file to achieve the security of a data
> in a db , one option would be to locate the XML file in a SS05 col of XML
> datatype.
> Anyone have real-world experience making this sort of trade-off decision ,
> or any insights ?
> Thanks.
>|||Problem I see with Configuration Application Block is that it assumes only
the simplest data structure is needed for config settings: discrete named
values.
To get around this, you can write your own transformers. But to leverage the
advantages that CAB offers, you should write them to work against multiple
data-providers/data-stores). This is quite a bit of work -- might be better
to spend that time writing an app-specific solution from scratch.
Also, I think it's not a good idea to avoid upfront analysis of the
app-specific trade-offs between different data-store solutions. CAB seems to
be saying "avoid the tough design decision" ... and, in the process,
sacrifice the advantages offered by a custom design.
But maybe I'm mistaken ...
"SriSamp" <ssampath@.sct.co.in> wrote in message
news:O4Ervev0FHA.460@.TK2MSFTNGP15.phx.gbl...
> When did go through a similar exercise for our application. One of the
> things that we considered was to look at configuration as something that
> is "configurable". This means that the location of the configuration file
> should be abstracted from your code so that you are free to move it
> around. This is where the Configuration Application Block from Microsoft
> comes into play:
> http://msdn.microsoft.com/library/d...br />
fig.asp.
> This block abstracts the ability to read and write from the configuration
> file and from a deployment perspective, the configuration can be in XML or
> in SQL Server. Maybe future editions of this block might put it in an
> SQL2K5 XML column, but the block would abstract it from you and you would
> always have a consistent way of programming.
> --
> HTH,
> SriSamp
> Email: srisamp@.gmail.com
> Blog: http://blogs.sqlxml.org/srinivassampath
> URL: http://www32.brinkster.com/srisamp
> "John A Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message
> news:OnfTXLs0FHA.3812@.TK2MSFTNGP09.phx.gbl...
>|||You're right in saying that CAB out of the box is for simple named values.
We have not tried writing our own formatters, thus, I cannot comment on the
complexity of the same. We did do an anslysis of an application specific
version, but found that the time it takes to provide a UI for the
configuration (like what CAB has) and the simple model of exposing the
configuration as properties of a class for our application looked like a
re-invention of the wheel.
Did you try posting your question to the GOTDOTNET site for Enterprise
Library? It is usually manned by the architects of the library and you may
get more specific answers.
--
HTH,
SriSamp
Email: srisamp@.gmail.com
Blog: http://blogs.sqlxml.org/srinivassampath
URL: http://www32.brinkster.com/srisamp
"John Grandy" <johnagrandy-at-yahoo-dot-com> wrote in message
news:O71N%23oz0FHA.2132@.TK2MSFTNGP15.phx.gbl...
> Problem I see with Configuration Application Block is that it assumes only
> the simplest data structure is needed for config settings: discrete named
> values.
> To get around this, you can write your own transformers. But to leverage
> the advantages that CAB offers, you should write them to work against
> multiple data-providers/data-stores). This is quite a bit of work --
> might be better to spend that time writing an app-specific solution from
> scratch.
> Also, I think it's not a good idea to avoid upfront analysis of the
> app-specific trade-offs between different data-store solutions. CAB seems
> to be saying "avoid the tough design decision" ... and, in the process,
> sacrifice the advantages offered by a custom design.
> But maybe I'm mistaken ...
> "SriSamp" <ssampath@.sct.co.in> wrote in message
> news:O4Ervev0FHA.460@.TK2MSFTNGP15.phx.gbl...
>