Design question and databases

[Guest]

Hey guys,

I'm in the process of designing a small app that will be used by myself and
a few other people. Now, there is some data that this app will need to run.
I know it is possible to put this data, for example, in an Access database
and include it with the app. However, I was wondering if it would be a
better idea to just include the data directly in my app. There isn't a huge
amount of data and it will rarely, if ever, change. It also does not need to
remain secret.

Any suggestions/comments if it would be better to just create a separate db
and bundle it with the app or just include it directly? I'm looking if there
is any way that this situation is usually handled by developers with more
experience than myself. Personally I would prefer to have as few files
bundled with the exe as possible but if storing all of the data inside the
exe is not a good idea I'll go another way.

Thanks.

 

[Otis Mukinfus]

Hey guys,

I'm in the process of designing a small app that will be used by myself and
a few other people. Now, there is some data that this app will need to run.
I know it is possible to put this data, for example, in an Access database
and include it with the app. However, I was wondering if it would be a
better idea to just include the data directly in my app. There isn't a huge
amount of data and it will rarely, if ever, change. It also does not need to
remain secret.

Any suggestions/comments if it would be better to just create a separate db
and bundle it with the app or just include it directly? I'm looking if there
is any way that this situation is usually handled by developers with more
experience than myself. Personally I would prefer to have as few files
bundled with the exe as possible but if storing all of the data inside the
exe is not a good idea I'll go another way.

Thanks.

Can you tell us more about the data? Is it in a file? If so are all the rows
in the file the same, etc.?

One method would be to put the data in a file and read it into the application
when it loads, but not knowing what the data is makes it hard to give you a good
answer.
Good luck with your project,

Otis Mukinfus
http://www.arltex.com
http://www.tomchilders.com

 

[Chris Mullins]

I frequently store resource files inside the EXE - Xml files, html files,
javascript files, and other data types are easily stored in there.

Doing this really helps ease deployment issues, as there are fewer things to
deploy, and therefore fewer things that can get messed up. Anytime you can
eliminate the "must deploy a database" requirement for an application, your
ability to deploy and support the application is bound to get alot better...

If the data is "almost" static, you could also store it in your app.config
file. This would allow updates to it, but still eliminate the need for a
database.

 

[Simon Tamman]

If the data isn't going to change then you should probably just serialize it
to xml or binary.
I used to do this on simple apps, you can directly serialize your
application objects and reload them, this makes life really easy.

Check out the XmlSerializer (requires all class properties to be public),
the BinarySerializer (doesn't require public properties) and the
ISerializable attribute for more information.
I think one or both of those also needs special attributes on weakly typed
collections (so it knows what's inside them).

If you're using a tabular/relational approach you can also serialize
datasets really easily. ( DataSet.WriteXml(), DataSet.ReadXml() )

If the data is going to change a little (eg. you'll load and save it a bit)
then remember to back up the file before writing, as an exception halfway
through serialization can result in a corrupt file. :O!

If your application will use more data and change more frequently then
definately use a database Access is okay, SQL is better though (MySQL, MSDE
and SQLExpress are free too!).

HTH

Simon

 

[Cor Ligthert [MVP]]

Flack,

The important part is, is the data fixed. Than it is even the question if
you should call it constants or whatever or data.

If it is not fixed but is not much and seldom changes, than you can think
about an XMLdataset. However more easy it is probably to use the free and
downloadable SQLServer Express.

I hope this gives some idea, but it is better to give us some more
information what you want.

Cor

 

[SP]

Hey guys,

I'm in the process of designing a small app that will be used by myself
and
a few other people. Now, there is some data that this app will need to
run.
I know it is possible to put this data, for example, in an Access database
and include it with the app. However, I was wondering if it would be a
better idea to just include the data directly in my app. There isn't a
huge
amount of data and it will rarely, if ever, change. It also does not need
to
remain secret.

Any suggestions/comments if it would be better to just create a separate
db
and bundle it with the app or just include it directly? I'm looking if
there
is any way that this situation is usually handled by developers with more
experience than myself. Personally I would prefer to have as few files
bundled with the exe as possible but if storing all of the data inside the
exe is not a good idea I'll go another way.

I think the following things need to be considered.
1. If the data changes is this done by the user or as part of an update to
the application?
2. Will the data changes always be done as part of an application update? If
not then you need to handle a mismatch between the data and your objects,
e.g. a new data file needs to work with an older version of the application.
3. Do you see a need to move to a database server because the amount of data
will be very large at some point?

On the simple end you can do what others suggested; embed the data into the
app, use app.config or supply a file. Simply deserialize or use the data to
populate classes. The more complicated route will be to use mapping and to
have a data layer that makes the use of a file or database transparent
outside of the data layer. Personally I use the seperate data layer approach
but I bring the structure of the "data" in line with the object structure.
Handling a mismatch between data structure and object structure can get
complicated.

SP

 

[Simon Tamman]

Oh I should also add that serializing classes has a serious sting attached.
If you change the definition of the serialized class (add, remove or rename
a property) than old serialized versions will not be loadable anymore.

 

[SP]

Oh I should also add that serializing classes has a serious sting
attached.
If you change the definition of the serialized class (add, remove or
rename
a property) than old serialized versions will not be loadable anymore.

I don't believe that is entirely true but you are correct that a mismatch is
a serious sting. I remember reading articles before 2.0 was released that it
would handle some of these issues better (using attributes to specify
default values etc.). I guess it depends on the .Net version and the type of
serializer, i.e. the XmlSerializer seems to handle new properties.

Regards,

SP

 

[Guest]

Thanks for all of the suggestions guys. As for your questions SP:

1. Any changes will be part of an update to the app. The user has no
control over the data.

2. Data changes will always be done at the same time as an app update.

3. The size of the data as it is right now is not that large and it is
highly unlikely (I would like to say never...) going to be large enough to
absolutely require a database server.

I'm leaning towards the idea of just embedding the data in the app since it
will not change unless the entire app is updated.

Thanks for all of the tips and if you need any more info please let me know.