What's a Database?

In simple terms, a database is an organized collection of information. Common examples include a phone book, a library catalog, an employee directory, a catalog of the MP3s you own, or in the case of our Recruiting app, information about the open positions at a company, the people who are applying for those positions, and the managers at our company who are in charge of hiring each position.

Typically, you use a database to collect information about people, things, or concepts that are important to you and whatever project you're working on. In standard database language, the category of a person, thing, or concept you want to store information about is referred to as an entity, although in standard Force.com platform terminology, we refer to this as an object.

In a database, each entity is represented by a table. A database table is simply a list of information, presented with rows and columns, about the category of person, thing, or concept you want to track. So in a phone book, you might have a table to store information about residences and another table to store information about businesses; or in a library catalog, you might have one table to store information about books and another to store information about authors.

In our Recruiting app, we'll have one table to store information about open positions, another table to store information about the candidates applying for the positions, and a table to store information about hiring managers. (Our Recruiting app will have more than just this, but we'll get to that later.)

In very simplistic terms, a Force.com platform object is similar to a database table in that you'll have a separate object for each person, thing, or concept about which you want to collect information. In reality, a Force.com platform object is much more than this because the full functionality of the platform is behind each object. Each object automatically has built-in features like a user interface, a security and sharing model, workflow processes, and much more that you'll learn about in the rest of this book.

It's important to understand that a single database table, or Force.com platform object, should contain only one type of information. You don't want to lump all of your information into one table, so you wouldn't store positions, candidates, and hiring managers all in the same place. Not only is this not good database design, but it doesn't allow you to relate objects to one another. For example, if all of our data were in one table, how would we ever know which candidates were applying for which positions, or which managers were in charge of hiring for which positions?

As we define our app, it's important for us to keep this in mind and ask ourselves questions like, “What kind of information do we want to store? Can we separate our information into distinct categories so that each object holds only one type of person, thing, or concept?” The answers to these questions will guide us as we design the structure of our application.