0

I think I've understood the basic idea behind object mapping but there is one gap in my knowledge base that I hope to fill now. First let me tell you what I understand out of the whole thing.

I have my database tables alright, and for every table I have a separate class. Each instance of each class represents a row of the table, for example table users - id, name, password would be represented like

class User {
    protected $id;
    protected $name;
    protected $password;
}

Which would have methods like setName, setPassword, create, save, getById and so on. This all makes a great lot of sense to me and brings a very good look to the code as well as maintainability, it's just awesome, I've fallen in love with this model of data handling ever since I discovered it.

However, now wo the thing that is not very clear to me. If I have a table that is a connecting table, sorry don't really know what the term for that is - a table which shows connection between other tables, how do I manipulate that table? Let me give an example again because I'm not very good with explanations. Say I add a table where users can add their contacts, just plain and simple, nothing fancy for the example. In the table contacts users can add other users like bookmarks. Since that table wouldn't have a PK, or would probably have a complex PK, It doesn't really fit very well in the above method - 1 row = 1 instance, because there is just no way to set up the "contact" object in the pattern shown above. Yeah I could probably do something like

class Contact {
    protected $forUser;
    protected $contact;
}

Where forUser would be the user who's contact that is and contact would be the actual user the contact contains, but as I said it is just not looking very well and doesn't make perfect sense for me.

The method I've come up with is to have additional methods in the initial class itself that manage the "connecting" tables, something like

class User {
    ...

    public function addContact(\User $user){
        ...
    }
}

Could you give me some guidance and tell me what are good and bad practices on this matter?

  • 3
    This started out as a good question; you provided some background and your thought process, but then you just hand-waved the question: "Can you provide some tips?" Do you have a specific question? – Robert Harvey Feb 25 '15 at 20:47
  • @RobertHarvey well the question is - what is the correct approach to the problem as well as how is this done in the real world. I am still learning and I don't have enough practice to determine whether what I'm doing now will be any good in time. I mean it works for now but who knows maybe it could turn out not to be that good of a solution for some reason. – php_nub_qq Feb 25 '15 at 21:46
  • There is no single correct approach to any problem in computing. All solutions that solve the problem satisfactorily are correct. Each solution has specific tradeoffs. – Robert Harvey Feb 25 '15 at 21:51
  • @RobertHarvey I agree but as correct I refer to the solution that has proven itself in time and/or is accepted by the majority as its flaws are far less than other solutions'. – php_nub_qq Feb 25 '15 at 21:56
  • If your only concern is to follow the pack, why not use a well-known ORM like Hibernate? – Robert Harvey Feb 25 '15 at 21:58
5

The connecting table that you speak of is called a junction table.

Using the Wikipedia example, they have 3 tables defined.

User
----
User ID
User Login
User Password
User Name

Permission
----------
Permission ID
Permission Description

UserPermission
--------------
User ID
Permission ID

Now, you can map these 3 tables to PHP classes.

It would probably be more intuitive to create a class with a user and a list of permissions.

For a different application, you might create a class with a permission and a list of users.

In a relational database, you have to have junction tables for a many to many relationship. You don't have to create a PHP class for the junction table.

Not the answer you're looking for? Browse other questions tagged or ask your own question.