In my opinion, Core Data would be a better option for this particular case, particularly with the relationships you have between the appointments, customers, and employees.
Core Data is more than just a database, it's an object graph management system. This means that you can easily maintain your relationships of customer, employee, and appointments by specifying these in your data model as one-to-one, one-to-many, or many-to-many, depending on what is appropriate. Assigning an appointment to an employee can be as simple as setting that assignment's employee relationship to the appropriate object, or doing the inverse of adding an appointment to an appointments relationship within the employee. Fetching these appointments is as easy as grabbing the objects in that employee's relationship, and the code for this can be made very clean by the use of custom NSManagedObject subclasses with matching properties for these relationships.
As SteAp points out, it's easy to write NSPredicates to filter based on a certain time range as explained in this question. By using the appropriate options, you can run your application in a debug logging mode to see the SQLite queries produced in response to these predicates, and they're usually what you would have written to achieve the same fetch.
On iOS, Core Data almost always uses SQLite as its backing data store, so you would think that it would introduce significant overhead on top of this. To the contrary, it performs some pretty good optimizations such as batched fetching that can cause Core Data to outperform raw SQLite in many cases. I've witnessed this within my own applications, particularly when it comes to long lists of results that you want to present in a table or a similar structure. There are certain cases where it breaks down, but those are few and far between.
I've done both raw SQLite and Core Data implementations of data models in my applications, and in every case Core Data has dramatically reduced the amount of code I've needed to write. Combined with the performance advantages I've seen, I have moved or will be moving all of my SQLite-based projects to Core Data.
Even Brent Simmons, who wrote the above-linked article about a specific performance issue that caused him to stay away from Core Data in one case, has this to say:
I bet Core Data is the right way to go 95% of the time. Or more. It’s
easy to work with. It’s fast (in most cases).
and he followed that up with the more recent statement:
This may come as a surprise to people who have it in their head that
I’m the guy who doesn’t like Core Data. So I’ll say this — on top of
all the other good reasons to use Core Data, here’s another: Core Data
is the standard Cocoa object persistence system.
When it gets better, our apps get better. (And it does keep getting
better.)
And, more importantly, as the standard it means that any Cocoa
developer — a teammate or someone who acquires the app — can jump in
and quickly understand how it works.
Yes, your custom thing may be better for your app. But will it stay
better? And if you bring someone on to help you, how quickly will they
learn your custom thing?
Use Core Data.
