Question

My website lets users record gameplay information.

The basic database unit is the play class, which holds the play date, userID, result, and battle serial number. All of these are required datapoints.

Users may also submit an after action report. The AAR class contains the AAR title, the content in markdown, the content in HTML (post-markdown), and the UID of the play it is describing.

Users submit a new play via a form, and via another menu may add an AAR to any existing play they have.

I feel very organized.

However, when viewing the site gameplay results, I almost always need to list ALL of that data together…

Battle No.
Player
Play Date
Result
AAR Title
AAR Body

so I’m sitting here looking at my two very well-organized, very meaningfully defined classes and having trouble visualizing the “missing link” that lets me unite them.

First I wrote an aarLoader that hit the database for all AARs according to a desired variable (say, played by John), and stuck them into a master array which could then be listed by another method. However, the AARs themselves don’t contain enough data – they don’t tell you who, when, which, and who won.

So it seems like I need to create some kind of “record” class to bridge my play and AAR classes. Seems logical, but when I created the file my mind just went blank.

What properties would such a class have? An array? But the array would need to hold a play and AAR pair… sometimes (some plays have no matching AARs).

Having read this far, I humbly ask that one of the OOP gurus please give me some advice on how to solve this problem.

(all of the above assumes I am correct in not squishing plays and AARs into the same class, since they are created and modified separately, and since AARs are optional…)

Answer 1

Here’s what I would do:

First, simply add the properties of what currently makes up your AAR class into the Play class:

Play
    -> Battle Number
    -> Player
    -> Play Date (Barbies included?)
    -> Result
    -> After Action Title (nullable)
    -> After Action Report (nullable)

This would match up exactly with your database table, so that the AAR fields would just be nullable fields that only get entered as an UPDATE whenever you save that AAR post-game.

Pros of this mean easy database queries, easy updates, and a very simple database schema.