Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I will begin with your side question, since the terminology is the first important part when speaking about OOP:</p> <ul> <li>Your classes <code>person</code>, <code>player</code> and <code>coach</code> are the Model. The intention of the Model is to project the important part of reality into a program, so that you (as a programmer) can intuitively work with the terms regarding the business domain.</li> <li>A View is not a standard OOP term, sometimes it is an abstraction inside a DB, so that you work with a View about one or more tables instead of the tables directly. Sometimes it is a GUI for a model.</li> </ul> <p>Your classes <code>personModel</code> and <code>playerModel</code> are less a model than a persistence controller or, as you said, a factory. If you would like to learn OOP and the possibilities to load/save a Model from/into a relational DB, you can easily write your own code, similar to your SQL code. A class <code>DBManagement</code> could do the trick with operations like <code>loadPersons()</code>. That operation queries the DB, builds all person objects and returns them. Similarly the saving can work with <code>updatePerson(person $person)</code>.</p> <p>Later you can use some kind of ORM (Object Relational Mapper) persistence framework (I don't have experience with PHP myself, but <a href="http://www.doctrine-project.org/projects/orm.html" rel="nofollow">doctrine ORM</a> could be interesing. In Java or .Net often <a href="http://www.hibernate.org/" rel="nofollow">Hibernate</a> is used).</p> <p>Addionally I would suggest that you design your model in another way. Indeed you had the right idea to let <code>player</code> and <code>coach</code> inherit from <code>person</code>, so that you can share common attributes like the <code>firstName</code>. But in this case, that model is not flexible enough to allow what you mentioned in your last sentence, that some users fall in all categories. A special case is when a Person, which is actually a Player, will become a Coach. For example, if Martin is a player but shall become a coach now, you have to swap one Martin object for another. That means that Martin is not the same Person as before, just because he becomes a coach, and that sounds strange, doesn't it?</p> <p>Instead you can define, that every user is <strong>always</strong> a <code>person</code>. Some users are <code>coach</code>es, some others are <code>player</code>s, some are both and some are none. But always a <code>person</code>.</p> <p>Some pseudo code for illustration:</p> <pre><code>class Person { string firstName; string lastName; List&lt;PersonRole&gt; roles; } abstract class PersonRole {} class Coach extends PersonRole {} class Player extends PersonRole { int position; string jersey; } </code></pre> <p>This way every user (=Person) can have none to every role. If a user has a role then in that role object you can save specific role attributes for that user. Of course, a person's role list can change over time, according to what role(s) the person actually has.</p> <p>A neat sideeffect is that this model is more in line with your database schema, so that you should have no trouble to translate the relational DB schema into a model instance and vice versa.</p>
    singulars
    1. This table or related slice is empty.
    1. POPHP mySQL constructing parent data from child class
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USDesty
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POPHP mySQL constructing parent data from child class
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload