storing, searching, and displaying variable-sized data sets
storing, searching, and displaying variable-sized data sets
- Subject: storing, searching, and displaying variable-sized data sets
- From: Matthew <email@hidden>
- Date: Thu, 30 Dec 2004 09:57:46 -0500
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
_______________________________________________
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