Databases
StackOverflow2013
Postsdbo
POImplementing Review flags in Databases; best practices
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POImplementing Review flags in Databases; best practices
    primarykey
    data
    text
    <p>I need store some review flags that relate to some entities. Each review flag can only related to a single entity property group. For example table <code>Parents</code> has a <code>ParentsStatus</code> flag and table <code>Children</code> has a set of <code>ChildrenStatus</code> flags. </p> <p>In the current design proposal I have three tables:</p> <ul> <li><code>ReviewTypes</code>: stores the flags and the properties they relate to.</li> <li><code>ReviewPositions</code>: stores the values the flags can have.</li> <li><code>Reviews</code>: stores the transaction data, the actual reviews. It is like UsersToFlags: <a href="https://stackoverflow.com/questions/124844/flags-in-a-database-rows-best-practices">Flags in a database rows, best practices</a>. </li> </ul> <p>The problem is I am getting push back that there is no need to have the <code>Reviews</code> table and it would be better to just store this actual review data on each entity. For example add an extra column to <code>Parents</code> to hold <code>ParentsStatus</code>. They feel it is a simpler solution and separating the data out is just “overkill” for out scenario.</p> <p>I don’t like this idea as this means that every time we want to add a new review flag we need to update the core entity table to hold that flag. </p> <p>Space is not a problem.</p> <p>Do people have any strong opinions?</p> <p>Edit:</p> <p>This comment applies to the three answers. The consensus is the relational approach is best but I think I need to read up a little more on the EAV model as from some very basic reading <a href="https://stackoverflow.com/questions/494158/best-beginner-resources-for-understanding-the-eav-database-model">Best beginner resources for understanding the EAV database model?</a> and its related links it does not appear to be super straightforward and I don't want to dig myself a hole. Thanks to wildplasser. I'll loop back once I read up a bit more. </p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USMichael Hollywood
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POImplementing Review flags in Databases; best practices
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POImplementing Review flags in Databases; best practices
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI'm not sure I understand your narrative - could you provide some example data of what you'd expect to see in each table (hopefully under both layouts that are being considered - showing the same data modelled each way).
      singulars
      1. POImplementing Review flags in Databases; best practices
      1. USDamien_The_Unbeliever
    2. COI don't see the problem. What you are proposing (as I understand it) is basically an EAV data nodel, except for the flags coming from a special enumeration-like domain (the ReviewPosistions table)
      singulars
      1. POImplementing Review flags in Databases; best practices
      1. USwildplasser
    3. CO@Damien_The_Unbeliver: I can do up some example data if that helps. Take me a few mins.
      singulars
      1. POImplementing Review flags in Databases; best practices
      1. USMichael Hollywood
 

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