Opinion Needed: Storing Small Amount of Records

[Lint Radley]

Hi Everyone,

I need an opinion here on storing data for a program I am working on the
processes DICOM images. Essentially, my program stores 25-45 (it varies
depending on the user) ranges of pixel values to search the image for.

Currently, I am using a .MDF database that requires SQL Express to be
installed. For only 25-45 records it seems like overkill to me. That
being said, I love the ability to easily update records, delete, add, etc.

Does anyone have any thoughts on whether I should explore other methods
for storing this data? If so, what is it? The key is to be able to
easily allow for modifications and additions.

Thank you,

Lint Radley

[Larry Smith]

I need an opinion here on storing data for a program I am working on the

processes DICOM images. Essentially, my program stores 25-45 (it varies
depending on the user) ranges of pixel values to search the image for.

Currently, I am using a .MDF database that requires SQL Express to be
installed. For only 25-45 records it seems like overkill to me. That being
said, I love the ability to easily update records, delete, add, etc.

Does anyone have any thoughts on whether I should explore other methods
for storing this data? If so, what is it? The key is to be able to easily
allow for modifications and additions.

What about XML? You can store your data in a strongly-typed dataset and
read/write via "DataSet.ReadXm l()" and "DataSet.WriteX ml()". You therefore
have the benefit of the native ADO.NET classes which provides adequate
RDBMS-like functionality with no external DB req'd. Keep in mind that you
lose the benefits of a full-blown RDBMS but for a small app it works very
well IMHO.

[Lint Radley]

Hi Larry,

I will look into this. I had thought about XML but didn't go too far
into checking the solution for suitability. Sounds like from your
description you can still bind to it?

Thanks,

Lint Radley

Larry Smith wrote:

>I need an opinion here on storing data for a program I am working on the
processes DICOM images. Essentially, my program stores 25-45 (it varies
depending on the user) ranges of pixel values to search the image for.

Currently, I am using a .MDF database that requires SQL Express to be
installed. For only 25-45 records it seems like overkill to me. That being
said, I love the ability to easily update records, delete, add, etc.

Does anyone have any thoughts on whether I should explore other methods
for storing this data? If so, what is it? The key is to be able to easily
allow for modifications and additions.

What about XML? You can store your data in a strongly-typed dataset and
read/write via "DataSet.ReadXm l()" and "DataSet.WriteX ml()". You therefore
have the benefit of the native ADO.NET classes which provides adequate
RDBMS-like functionality with no external DB req'd. Keep in mind that you
lose the benefits of a full-blown RDBMS but for a small app it works very
well IMHO.

[Mac McMicMac]

"Lint Radley" <sc********@for wardbounding.co mwrote in message
news:WwtSi.907$ uE4.459@trnddc0 7...

Hi Larry,

I will look into this. I had thought about XML but didn't go too far into
checking the solution for suitability. Sounds like from your description
you can still bind to it?

UI controls can be bound to an ADO.NET DataTable. The DataTable natively
understands XML, and can read and write to/from XML files directly:

http://msdn2.microsoft.com/en-us/lib...e.readxml.aspx

http://msdn2.microsoft.com/en-us/lib....writexml.aspx

If you are unfamiliar with ADO.NET, consider that a standard approach to
working with data is to query a database and load data into a DataSet or
DataTable via an ADO.NET DataAdapter instance. Note that a DataSet is
basically a container for DataTable objects. Data lives only in DataTables -
and never directly in a DataSet. To over simplify, you can pretty much think
of a DataSet as an in-memory relational database, as you can set up
DataRelations amongst contained DataTables. Anyway, you then bind your UI
components to the DataSet (specifying the particular DataTable) or a
DataView, or bind directly to a DataTable (DataTables are not required to
exist within a DataSet). The user can then update the data in the
DataTable(s) (perhaps via contained in a DataSet). You then persist the
changes back to the database with an ADO.NET DataAdapter instance.

Keep in mind that (1) DataTables have no clue as to where their data came
from. And (2) because DataTables natively store their data as in-memory XML,
they are capable of reading and writing directly to XML files on disk (no
need to get data from a typical database like MS Access or SQL Server). The
two links above have overloads you can use to read and write directly
to/from XML files on disk.

-HTH

[Lint Radley]

Hi Mac,

I really appreciate your write up here. I will be reading up on this
tomorrow. Thanks! :-)

Lint Radley
Mac McMicMac wrote:

"Lint Radley" <sc********@for wardbounding.co mwrote in message
news:WwtSi.907$ uE4.459@trnddc0 7...

>Hi Larry,

I will look into this. I had thought about XML but didn't go too far into
checking the solution for suitability. Sounds like from your description
you can still bind to it?

UI controls can be bound to an ADO.NET DataTable. The DataTable natively
understands XML, and can read and write to/from XML files directly:

http://msdn2.microsoft.com/en-us/lib...e.readxml.aspx

http://msdn2.microsoft.com/en-us/lib....writexml.aspx

If you are unfamiliar with ADO.NET, consider that a standard approach to
working with data is to query a database and load data into a DataSet or
DataTable via an ADO.NET DataAdapter instance. Note that a DataSet is
basically a container for DataTable objects. Data lives only in DataTables -
and never directly in a DataSet. To over simplify, you can pretty much think
of a DataSet as an in-memory relational database, as you can set up
DataRelations amongst contained DataTables. Anyway, you then bind your UI
components to the DataSet (specifying the particular DataTable) or a
DataView, or bind directly to a DataTable (DataTables are not required to
exist within a DataSet). The user can then update the data in the
DataTable(s) (perhaps via contained in a DataSet). You then persist the
changes back to the database with an ADO.NET DataAdapter instance.

Keep in mind that (1) DataTables have no clue as to where their data came
from. And (2) because DataTables natively store their data as in-memory XML,
they are capable of reading and writing directly to XML files on disk (no
need to get data from a typical database like MS Access or SQL Server). The
two links above have overloads you can use to read and write directly
to/from XML files on disk.

-HTH

[sloan]

This is what I do.

I create a directory like

DataStores\

and put things like

dicom.xml
and i do this

create a strong dataset

add a few rows using code and using the strong typed methods

ds.WriteXml(fil eName);

look at it in notepad. save it in dicom.xml

then use the ds.ReadXml when I need it.

(as a previous person has said)

Its for my very very static data. But still updateable if need be.


"Larry Smith" <no_spam@_nospa m.comwrote in message
news:uI******** ******@TK2MSFTN GP02.phx.gbl...

>I need an opinion here on storing data for a program I am working on the
processes DICOM images. Essentially, my program stores 25-45 (it varies
depending on the user) ranges of pixel values to search the image for.

Currently, I am using a .MDF database that requires SQL Express to be
installed. For only 25-45 records it seems like overkill to me. That
being said, I love the ability to easily update records, delete, add,
etc.

Does anyone have any thoughts on whether I should explore other methods
for storing this data? If so, what is it? The key is to be able to easily
allow for modifications and additions.

What about XML? You can store your data in a strongly-typed dataset and
read/write via "DataSet.ReadXm l()" and "DataSet.WriteX ml()". You therefore
have the benefit of the native ADO.NET classes which provides adequate
RDBMS-like functionality with no external DB req'd. Keep in mind that you
lose the benefits of a full-blown RDBMS but for a small app it works very
well IMHO.

[Rad [Visual C# MVP]]

On Sat, 20 Oct 2007 18:00:07 GMT, Lint Radley
<sc********@for wardbounding.co mwrote:

>Hi Everyone,

I need an opinion here on storing data for a program I am working on the
processes DICOM images. Essentially, my program stores 25-45 (it varies
depending on the user) ranges of pixel values to search the image for.

Currently, I am using a .MDF database that requires SQL Express to be
installed. For only 25-45 records it seems like overkill to me. That
being said, I love the ability to easily update records, delete, add, etc.

Does anyone have any thoughts on whether I should explore other methods
for storing this data? If so, what is it? The key is to be able to
easily allow for modifications and additions.

Thank you,

Lint Radley

You can also use a small footprint database, which are basically DLLs
that you reference for the database functionality rather than full hog
databases.

There are several of these:

- SQL Lite
- SQL Server Compact Edition
- VistaDB

*Vista DB is not free

--
http://bytes.thinkersroom.com