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.