You're developing a customer loyalty app for a small chain of retail stores. The app will need a backend database to maintain customer information. While designing the app, you're conducting a planning meeting with your client to determine the scope of the project and resolve questions she has about the project.

Client:

I$\text{'}$m trying to understand how all this will work$-$how the app and the database will work together. Where will you get the information for the database?

You:

This data is specific to your company, so it's called data. Your customers will enter their personal information when they create their accounts. Then sales transactions will continue to add data about each customer over time.

Client:

That sounds like a lot of data. Won't the database get too big to find information quickly?

You:

Good question. We can build in a$($n$)$ or two to help speed up queries. It will take up a bit more space, but will greatly increase efficiency for user interactions.

Client:

I suppose "users" include customers and employees. Will they all see the same information about each account?

You:

No$,$ we'll design separate for each type of user so the user gets exactly the needed information and nothing more. This is especially important when considering customer privacy.