Re: storing, searching, and displaying variable-sized data sets
Re: storing, searching, and displaying variable-sized data sets
- Subject: Re: storing, searching, and displaying variable-sized data sets
- From: Tim Ramsey <email@hidden>
- Date: Thu, 30 Dec 2004 18:45:24 -0600
On Thursday, December 30, 2004, at 08:57 AM, Matthew wrote:
Hello List,
I have what hopefully turns out to be a conceptual design question
here involving a table view, a data source, and a search. It boils
down to the (sort of pedagogical) software engineering 101 question:
if you were coding up something along the lines of a cataloging system
(assume read-only and a size range of a few megs to a few hundred
megs) and wanted to design generic and reusable classes to do this,
how would you choose to store/search your data given the available
Cocoa tools available? I've searched the archives and seen lots of
project specific details about such things as this, but none that I
could find really addressed the rationale for design so much as they
did what to do in a specific situation or project.
The obvious way to be able to search the data and populate the table
view from what I gather is to simply have the data archived with
something like NSKeyedArchiver, load it into memory one time, and
iterate over the relevant fields for the search--filling in an array
or whatever is your binding to the table view. For a data source of a
few megs, this sounds fine and has the advantage of being able to
bundle the catalog inside the app if you want, which can be a good
thing.
If that's your "final answer", then great, but from a previous thread,
it appeared that using NSKeyedArchiver to do the archiving could
result in a very undesirable performance hit although this was still
considered the preferred method of handling things. Additionally, if
you do bundle the data in the app, then the app size could grow and
grow and grow.....
So my concerns are:
1) At what point (and I know it's a fuzzy line) does the size of
something being archived need to move from something like a keyed
archiver to a more sophisticated db of some sort? One answer is
"whenever you're unwilling to wait for the data to load anymore,
switch to the db" but as a general design principle given today's
computing power, are we talking 10s of megs or 100s of megs?
2) With respect to searching on some type of archived data that's in a
situation like this, is there some automated clever way of searching
out the data to populate some kind of view other than iterating over
the entire collection, or is this pretty much it? It seems almost too
obvious. I understand you could use the key in the keyed archives to
your advantage if that's your approach, but in a catalog your key
might end up being the concatenation of all of your fields...so in
effect you're searching everything, right? the sql approach obviously
has the solution built in.
3) If a sql db turns out to an undesirable option for whatever reason,
what is a desirable approach for handling very large data sets? File
seeking around in a flat file comes to mind, but intuition is telling
me that such an option became obsolete some time ago?
Best,
Matthew
___________________________________________
If you go with 3), check into red/black trees. AFAIK algorithms based
on red/black tree methods are presently the fastest way to access huge
data volumes.
(If they are not, someone give a faster one. I'm interested too.)
Tim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden