Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>My first question to you would be: Are you asking for help devising a proper database schema or are you asking how to handle these properties/subclasses in code?</p> <h2>Database Schema</h2> <p>Database schema isn't exactly my forte, so I'll leave that up to somebody who may know better than me.<br> I would probably just have each field as its own column in a single <em>properties</em> table though because its easy and lets you index each field properly. As you said, new fields are not going to be added often.</p> <h2>Handling it in PHP</h2> <p>Thinking of these fields as metadata is approaching it wrong, in my opinion. Each subclass has its own set of fields, meaning technically they are all separate kinds of entities.</p> <p>I'm keeping this simple for clarity, but here's something along the lines of what I would do:</p> <ol> <li><p>Make a POPO (plain ole' php object) for each property type.<br>These are simply value objects, similar to what you may find in an ORM. Like a Doctrine2 entity, they do not perform any kind of persistence.</p></li> <li><p><em>Here's where I'm simplifying the example.. this most definitely does not follow the SRP and is bad design i.m.o, but I'm writing it this way for brevity.</em><br><br> Make a factory class that's responsible for fetching and saving the data from/to the database, instatiating the appropriate POPOs and populating the data accordingly.</p></li> </ol> <p>That's really all there is to it. It's a mini-ORM. You could actually do away with #2 and use a proper ORM if you wanted...</p> <p>They key is having the separate objects for each property subclass. It's advantageous because:</p> <ul> <li>Since each property type has its own class with its own pre-defined set of properties (and getters/setters), you need not worry about populating or using data that belongs to other property types.</li> <li>It provides a clear distinction that you can use to render a template specific to each property type. (Not that you couldn't do this before... I just feel this way is cleaner.)</li> <li>Each property type class can inherit from a base to accommodate all of the fields that are common among property types.</li> </ul>
    singulars
    1. This table or related slice is empty.
    1. POHow to store metadata about the table?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USsimshaun
    1. USsimshaun
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POHow to store metadata about the table?
      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. COI'm reluctant to use different classes for different types of properties, because all the operations that can be performed with them (output into a table row, output into the page, output form for editing, save new data) are performed completely similar for each and every one of them - through iterating over the list of attributes. Using different classes for different types of data, on the other hand, might actually be a great idea. Thank you :)
      singulars
      1. PO
      1. USSeptagram
    2. COKeep in mind that the POPOs are value objects only so they don't contain any logic regarding outputting and saving. They would extend a base for common property attributes, but that's all. All of the logic that applies to properties would be in a separate service class to begin with, and abstracted out further from there.
      singulars
      1. PO
      1. USsimshaun
 

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