• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: storing, searching, and displaying variable-sized data sets
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: storing, searching, and displaying variable-sized data sets
      • From: Brendan Younger <email@hidden>
References: 
 >storing, searching, and displaying variable-sized data sets (From: Matthew <email@hidden>)

  • Prev by Date: Re: NSDecimalSeparator localization II
  • Next by Date: Tying manipulation of two NSTableViews
  • Previous by thread: Re: storing, searching, and displaying variable-sized data sets
  • Next by thread: Re: storing, searching, and displaying variable-sized data sets
  • Index(es):
    • Date
    • Thread