Alan,
At first you mention ways to store data, but then you ask about
records and fields so I'm not sure exactly what you're looking for. As you
know there are many different ways to "hold" data while your application is
running. Records, Stringlists, ObjectLists, database tables, etc., and just
as many different ways of storing that data on disk for later use, such as
inifiles, xml, delimited text files, binary files, etc. So it really
depends on the particular circumstance you're dealing with! There's no
all-powerful way of handling these things across the board!
For example, if I have simple text data that I need to read and hold
and possible change during the run of a program, I might simply use a string
variable, and if it needs to be stored between sessions, usually an ini-file
if it's a single line, or straight file I/O if it's larger. If the text
will fit properly I'll use a stringList for this because it has a savetofile
and a loadfromfile method built-in. If the data needs to be sent across the
internet, xml might be a better choice, especially when dealing with
different protocols along the way! And xml can also usually be made to work
well with a stringList for saving out to a file for temporary storage. And
if it's a really large amount of text I might even create a locally scoped
instance of an invisible Tmemo, load the text into it and save it out to a
file, doing the opposite when it's needed again for the next session!
I've found that unless I'm dealing with really huge amounts of data
speed is really not much of an issue. I guess it might have been at one
time, but with the average processor speeds of today and the amount of
onboard memory, this is no longer as much of a worry as it used to be. I'm
more concerned with the number of windows handles and other resources
different solutions take, and that was why I asked the questions I did. As
I already have a database up and running, what's the difference between
using an extra table to hold my data and using a TInifile instance? In all
respects both methods are just as easy to work with and will yield the same
results, but what are the differences between the two methods as handled
internally? I guess the only way I'll ever find out is to do some hard
testing! That's where years of experience pays off as you would probably
have enough to rationalize one method over the other!
from Robert Meek dba Tangentals Design CCopyright 2006
"When I examine myself and my methods of thought, I come to the conclusion
that the gift of Fantasy has meant more to me then my talent for absorbing
positive knowledge!"
Albert Einstein
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Alan Colburn
Sent: Thursday, March 23, 2006 11:41 AM
To: [email protected]
Subject: Re: Storing Data
Do you mind if I open Robert's question up just a little, to make the
responses even more edifying to a newbie? ... How does one go about planning
the kind of data structure to use for storing information, given the number
of choices--home made scheme with text file, name-value pairs and string
lists, ini file "database," records, XML, etc. I'm thinking about situations
where a separate database is not involved. I recognize speed issues are
important as the amount of data to be stored/retrieved increases. I'm new
enough to programming that I'm still thinking more about how long it takes
*me* to write the code than for others to use it :)
I'm trying to keep this as a general question; I'm learning a lot -- still,
I'll add I often have a 'field' that includes a large amount of text. I'm
under the impression that records either can't handle this, or would be a
poor choice because of having to set aside a large chunk of memory in each
record, even if the stored text was sometimes small. Is this accurate?
Thanks for the lessons!
Al C.
_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
