SitePoint Sponsor

User Tag List

Results 1 to 5 of 5

Thread: Oop

  1. #1
    SitePoint Addict
    Join Date
    Jul 2007
    Location
    San Jose, California
    Posts
    355
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Oop

    I have an OOP architecture, The class setup looks something like this:
    PHP Code:
    class person{
       public 
    $fName;
       public 
    $lName;
    }

    class 
    employee extends person{
       public 
    $hours;
       public 
    $rate;
    }

    class 
    janitor extends employee{
       public 
    $lockerNumber;
       public 
    $uniformSize;

    I'm using a database backend of course. Not sure how to setup the database system I've created 3 tables, person, employee, and janitor. All of them include a primary key to the affect of pid, eid, jid. Janitor and employee have another two fields including the given class attributes, these fields are employeeID and personID. The theory I have is you create employee which essential looks like this.

    uniformSize => large,
    lockerNumber => 532,
    hours => 38,
    rate => 19.00,
    fName => Brian,
    lName => Jordan

    To store this in the database I was able to create use a storage like this.

    jid, uniformSize, lockerNumber, EmployeeID => Janitor
    (1, large, 532, 15)

    eid, hours, rate, personID => Employee
    (15, 38, 19.00, 4)

    pid, fName, lName => Person
    (4, Brian, Jordan)


    So the janitor tuple links to the employee tuple which inturn links to the person tuple.

    I was just wondering if there was a different way to set the back end up? If this is confusing i'll try and explain it some more.

  2. #2
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Not sure how to setup the database system I've created 3 tables, person, employee, and janitor.
    Not sure I am following your thinking on the back-end storage. Wouldn't a rdbms schema not look something similar to this below, and wouldn't it be the job of your model to sort out how to manage the interaction between your objects and this storage?

    People
    =====
    id
    fName
    lName
    size
    locker_number

    Jobs
    ====
    jid
    title
    base_hourly_rate

    People_Jobs
    =========
    id_ref
    jid_ref
    hourly_rate
    hours_per_week

    Its a simple example inspired by your use of the word janitor, in such roles many people multi-task and can do more than one role in an organisation, and that the hourly rate for each job should have a minimum, but can be overridden.

    Are you proposing a substantially different schema to this? Maybe reflecting how you want your objects to behave?

    To store this in the database I was able to create use a storage like this.

    jid, uniformSize, lockerNumber, EmployeeID => Janitor
    (1, large, 532, 15)

  3. #3
    SitePoint Addict
    Join Date
    Jul 2007
    Location
    San Jose, California
    Posts
    355
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    well my model was an simplified version of the total model. And i see what you're doing with the joining database but I think the foreign key in each tuple is better than a whole table deveoted to foreign keys, considering that all tables are essential.

  4. #4
    SitePoint Addict
    Join Date
    Jul 2007
    Location
    San Jose, California
    Posts
    355
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think I like yours better now though. I'm still rolling it over in my head.

  5. #5
    SitePoint Zealot
    Join Date
    May 2008
    Location
    Montreal
    Posts
    155
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I feel like there is a flaw in laying the relationships out using PHP's limited single inheritance model. For example, how would you recognize an independent contractor or an unemployed person?

    This is a place where your model will be more flexible if you look at a person as having a (has-a) job instead of being an (is-a) employee.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •