Why make Objects when you can just use a MySQL database?

Question

So I am a little confused on the object oriented part of PHP. Right away I will apologize for the fact I know very little about PHP and databases.

My question is when your making per say a database to hold users in it, why would you want to make a class/object for that user when you can just pull info from the database.

Also if you were to make a object/class where is the data for the objects stored? Like a class with a username and email, and I make that object, were does it get stored.

Thanks for taking your time to help a learning noob!

Answer 1

My question is when your making per say a database to hold users in it, why would you want to make a class/object for that user when you can just pull info from the database.

You make objects to abstract away specific functionality. What happens if you move to, say, Microsoft SQL Server (hypothetically speaking)? Rather than update your entire site, you just edit the implementation of the object.

Also if you were to make a object/class where is the data for the objects stored? Like a class with a username and email, and I make that object, were does it get stored.

The same place as any other variable.

Answer 2

Additionally, this question might be somewhat informative.

Answer 3

Databases store data in a tabular fashion which is designed to be speedy. Objects are so much more flexible; they can be trees, they can be lists, they can be widgets, or anything else out of a million things. They can represent presentation, data, or structure. And sometimes they are even faster (when it's easier to calculate a value on the fly rather than retrieve it from a database). Databases are very powerful and important but are only appropriate for a small subset of the tasks that a web application performs. The rest are made easier by objects.

Answer 4

There are a LOT of reasons why you want to use some abstraction on top of just raw database access in any reasonably large software system. If you're looking at an Object Oriented approach you should consider that one of the core ideas of the Object Oriented paradigm is that an object encapsulates both data and logic that acts on that data.

Let's take a concrete example. Say that a part of your application (the UI) needs to display user information, including a nicely formatted user name. In an OO world you could have a User object which would store a local copy of the data in the database, and expose methods like getFormattedName(), or something similar. Now the rest of your application can use that code without needing to know about the database, or even how the name is formatted. On the other hand if you were just pulling data directly from the database then the UI part of the application (which doesn't really care about databases) still has to know itself how to get information about the user from the database, and how to format the users name nicely.

Answer 5

To put it simply, there are logic not captured in a database table but related to the entry. The database only stores the raw data. How the data is used and how it interacts with the rest of your application should be captured in your object methods.

Answer 6

You're missing a fundamental of object-oriented design. Ignoring inheritence entirely, Objects combine information/data and functions/procedures/operations into a single unit called an object. This object performs operations (methods/behaviors/functions/procedures) and has attributes. A database will not have the entire set of operational/procedural information. By design, a database will only contain data, and know nothing of how the data can be used or what the data does.