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.
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.