views:

38

answers:

1

Overview: I'm designing a restaurant management application, and I have an entity called Order which has Items. Since a restaurant can operate for many years, with many thousands of completed 'orders', and in the interest of making the networking side of my application easier and keeping the database fast, I want to introduce the concept of a ClosedOrder, which is an Order has been paid for, esentially.

I have a few options for doing this: I could add an isClosed attribute to my Order entity, and perform all fetch requests for 'open' orders with a predicate, but that keeps the problem of there being lots of records for the DB to go through every time a fetch is needed, which is often with the Order entity because of the workflow of my app. If I understand correctly, creating a 'ClosedOrder' subentity would also have the same problem, as Core Data stores all subentities in the same table in the database.

Is creating a completely separate entity foolish in this case? Or is it exactly what I need to do? I apologize for my overall lack of knowledge about database performance, Core Data is beautiful in that it abstracts needing to learn about that away, but at the same time it can't actually make it not important, especially in a case like this where performance could severely degrade if it's pushed far by my users.

+1  A: 

If you're using SQLite store type and the "isClosed" attribute is "Indexed" (a setting in your entity editor panel), you could have hundreds of thousands of orders and still have a nice, quick fetch time when filtering only for "isClosed == YES".

Creating a separate entity won't really buy you much performance but it will make it more of a pain to maintain when things change (two migration steps for the price of one, for example). You're still storing all those items and SQLite is a competent DB library when it's setup correctly. Use an indexed attribute here, then generate some test data, then measure the performance. I'm sure you'll be satisfied.

Joshua Nozzi
Ah interesting, do you have any more information on what indexing is/how indexing works for a noob? :) There's nothing in the Core Data documentation, and when I was Googling it a week ago, it was mostly people asking what it was and noting it wasn't in the docs. Sounded like I should be indexing my UUID attribute too if I understood the little I found correctly.
refulgentis
1) Select the "isClosed" attribute and check "Indexed" and you're done. 2) It should only be indexed if you're interested in filtering/fetching instances based on their UUID. Personally, I'd use a numeric attribute, rather than a string UUID (less text to store/manipulate/search).
Joshua Nozzi
Oh no I understand how to do it, just don't understand what's going on "behind the curtains." is it a SQLite thing I should be googling?
refulgentis
No, when working with Core Data, you're to leave dealing with SQLite *entirely* to Core Data. What it's doing is telling SQLite to create an index for whatever attribute you selected. This helps SQLite find table rows much more quickly. Don't go index-happy, though, and index everything as too many indexes will have a negative performance impact. Index only the primary attributes you'd use to find/fetch/sort/whatever. This, in general, is a relational database thing.
Joshua Nozzi