SOTD: Prefered Storage

[lost in transition]

Survey of the Day What type of storage do you prefer to use for an application where the data to be stored is minimun? i.e.: records < 100

Programmer: A biological machine designed to convert caffeine into code.
Developer: A person who develops working systems by writing and using software. [^]

[MoustafaS]

I think XML files will be good.

------------------------------
"The Soapbox has been so ..."

[Ryan Roberts]

I have used sqlite quite a few times for making a small application embedded database. That combined with Subsonic (an Active Record inspired lightweight .NET ORM)[^] would make a killer combination for small scale application storage.

[badgrs]

I'll second that!

[HalfWayMan]

Flat binary files. Preferably in opposite endianness. This data must also be compressed using a shockingly poor proprietary compression method.

[Douglas Troy]

I would use SQLite[^] or use an XML file, accessing it via TinyXml[^] SQLite makes scaling the application later easier, if it were to ever "out grow" your 100 record storage "limit" ... My two cents. [Edit] Just occurred to me that you never stated what development language you were using for this, which I believe matters; mainly because if you're doing this in .NET, the framework already has support for XML, just use that, instead of binding to all sorts of external storage sources (like SQLite), since that carries even more overhead. Now, if it's C/C++ or the like, then I believe my suggestions apply.

---

:..::. Douglas H. Troy ::..
Bad Astronomy |VCF|wxWidgets|WTL

[Clickok]

Firebird 2.0 Embed [^]

---

Engaged in learning of English grammar ;)
For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger:

[Nemanja Trifunovic]

jason_lakewhitney wrote:

What type of storage do you prefer to use for an application where the data to be stored is minimun? i.e.: records < 100

Just display the data on the screen and give the user 5 seconds to take a photo of it.

---

Programming Blog utf8-cpp

[Marco Stinger]

I Third

;)

[Roger Stoltz]

jason_lakewhitney wrote:

What type of storage do you prefer to use for an application where the data to be stored is minimun? i.e.: records < 100

Nemanja Trifunovic wrote:

Just display the data on the screen and give the user 5 seconds to take a photo of it.

Fantastic idea! Perhaps we should point out that it should be a digital camera, otherwise he cannot connect it to the computer and store it on the disk. However it's still possible to do it the old way by taking the picture, send it to be developed and then use the scanner to scan it to a file and store that one. I'd prefer the new way. ;P

---

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

[Chris Losinger]

if it's less than 100 items, i assume the user can just re-enter the data each time the app's run. keyboards are getting easier to use every year. a modern keyboard makes data entry almost pleasant!

image processing toolkits | batch image processing | blogging

[Chris Losinger]

HalfWayMan wrote:

This data must also be compressed using a shockingly poor proprietary compression method.

maybe Base64-encoding? it features an impressive 3:4 compression ratio.

image processing toolkits | batch image processing | blogging

[Chris Losinger]

<Response> <Name>Chris Losinger</Name> <Msgtext> I 4<super>th</super> it! </Msgtext> </Response>

image processing toolkits | batch image processing | blogging

[El Corazon]

jason_lakewhitney wrote:

for an application where the data to be stored is minimun?

random access in real-time? or load and forget? or load and in-memory retrieve? random access to disk in real-time you want an indexed database, either a light SQL, or a self-built (many libraries out there for b-tree, m-tree, etc indexing). You want to choose something for rapid reading, including binary files if the data is indexed sequentially and doesn't need to be resorted. (though the latter is frowned upon -- go for the light SQL) load and forget or in-memory retrieve after load works great for XML. the right tool for the right job. :)

_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)

[Shog9 0]

If it's only a few hundred KB, max, i'll go with XML. XML's fairly easy, saves me writing a complicated parser, and allows a fair bit of structure to be represented. Also, it's easy to use XSLT to generate reports, or use a text editor to view or tweak...

---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums

[MoustafaS]

Nice one.:laugh:

------------------------------
"The Soapbox has been so ..."

[TridentWhite]

Index cards. Small, compact, easily indexed and searched and not susceptible to the occassional EMP.

---

Happiness is knowing that somewhere out there, there is a bullet with your name on it.

[Member 96]

Without reading the other responses and since you said "records" adn "data" I'm assuming you don't mean an ini file type data. I'd store it as xml, there really isn't any other choice worth doing is there?

[Member 96]

Or 30 seconds to "write down everything you see on the screen quickly and accurately" with a rolling countdown and increasingly nerve inducing music.

[Bassam Abdul Baki]

Just use the Windows' registry. :)

---

"The trouble with the profit system has always been that it was highly unprofitable to most people." - E. B. White Web - Blog - RSS - Math - LinkedIn - BM