Where is the best place to store such data

[Guest]

I have some data values that will will rarely change over the life of the
program. I don't think it is wise to save it in a database. Is it ok to save
them in Properties.Settings if I have many different values? Example I want
to save information about the user of the software, eg, name, address,
telephone #.

 

[Dave Sexton]

Hi Dave,

When you say, "many different values", how many are we talking about?

Other options are the AppSettings in the .config file, a custom XML file, a
custom flat-file and the system registry. You've excluded the database as an
option, and I agree with that choice only if you don't need to establish any
relationships with data that is going to be stored in the database. Using
Settings in VS 2005 will require the least effort on your part for persisting
the data in your example, but if you have relational data then you should
think about using a structured format such as XML, or even consider the
database, regardless of its static nature.

 

[Guest]

What did I mean by "many different values"? I meant if I want to store
information about an entity which has say 'n' attributes, however, if I
should use a table, then it be '1xn' (row by column) table. Is this an
acceptable use of a table? What is the de facto (or popular) standard for
saving such data?

 

[Dave Sexton]

Hi Dave,

I wasn't asking what you meant by that statement. I was asking for
quantification.

Exactly how much is "many"?

If your answer is 10000 then I'm probably going to recommend using a database
table. If your answer is 5, unrelated, arbitrary pieces of information, I'd
probably recommend Settings. If your answer is 20, static, hierarchically
related pieces of information then I'll probably recommend XML.

Where you store data all depends on relationship, quantity, type and use.
Your choice may also depend on other things such as security, performance,
scalability, interoperability, flexibility, ease of use, ease of management,
and I'm sure other variables as well.

Settings is great for data that needs to be easy to add at design-time, easy
to code for read/write at runtime, isn't required in large quantities, isn't
complex, isn't related or hierarchical in nature, and when security isn't
required.

The data you've cited in your example seems most appropriate in Settings, from
the limited information you've stated thus far.

 

[Guest]

Thank you.
--
L. A. Jones

Hi Dave,

I wasn't asking what you meant by that statement. I was asking for
quantification.

Exactly how much is "many"?

If your answer is 10000 then I'm probably going to recommend using a database
table. If your answer is 5, unrelated, arbitrary pieces of information, I'd
probably recommend Settings. If your answer is 20, static, hierarchically
related pieces of information then I'll probably recommend XML.

Where you store data all depends on relationship, quantity, type and use.
Your choice may also depend on other things such as security, performance,
scalability, interoperability, flexibility, ease of use, ease of management,
and I'm sure other variables as well.

Settings is great for data that needs to be easy to add at design-time, easy
to code for read/write at runtime, isn't required in large quantities, isn't
complex, isn't related or hierarchical in nature, and when security isn't
required.

The data you've cited in your example seems most appropriate in Settings, from
the limited information you've stated thus far.