• 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: Class design question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Class design question


  • Subject: Re: Class design question
  • From: Andy Armstrong <email@hidden>
  • Date: Sun, 13 Feb 2005 19:07:05 +0000

On 13 Feb 2005, at 18:33, Ken Tozier wrote:
If these subclasses literally differ only in the size of the data they encapsulate then surely you just need a pointer to a variable sized chunk of memory? But surely they must differ in more than that? Otherwise what were all the function pointers for in your first design?

The primary difficulty is that I read and write the data to disk myself as the files have, at least the potential, to be terabytes in size. With one exception (variable length strings) The data within a file is always factored by size, that is, every piece of data in a file will be the same type and size, but what those types and sizes are is completely up to the user. The problem I'm running into is in reading a chunk of data from disk and dispatching it to the correct decoder.

So you're variable sized chunks of data from a file that may contain many like sized chunks. What else about the data differs? How complex is the interface to the data? You haven't really let us know what kind of thing these chunks of data represent.


Can you tell us more about the problem? What are the twenty different types of thing (or at least what are some of them - to give us a flavour).

I'm writing an objective C database application that addresses the issues I dislike about SQL. The data types generally follow the SQL table definition capabilities, but my app will have a richer set of types (ie: built in money, length measure, weight measure and many others) and will allow for very easy cell level localization.

Is there any reason why you don't just use Foundation classes and encode them for storage? May we also infer from what you've said elsewhere that you're not supporting variable length records?


To be honest if you're planning to build a database engine that'll handle 'terabytes' of data I wouldn't be starting the design work at this end. If you don't want SQL but you do want a record oriented database why not something like Berkeley DB with serialised Foundation objects as fields?

--
Andy Armstrong, hexten.net

_______________________________________________
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


References: 
 >Class design question (From: Ken Tozier <email@hidden>)
 >Re: Class design question (From: Andy Armstrong <email@hidden>)
 >Re: Class design question (From: Ken Tozier <email@hidden>)

  • Prev by Date: Re: Class design question
  • Next by Date: Re: Class design question
  • Previous by thread: Re: Class design question
  • Next by thread: Re: Class design question
  • Index(es):
    • Date
    • Thread