Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I've been doing this in <code>Oracle</code>.</p> <p>I had the following tables:</p> <pre><code>t_class (id RAW(16), parent RAW(16)) -- holds class hierachy. t_property (class RAW(16), property VARCHAR) -- holds class members. t_declaration (id RAW(16), class RAW(16)) -- hold GUIDs and types of all class instances t_instance (id RAW(16), class RAW(16), property VARCHAR2(100), textvalue VARCHAR2(200), intvalue INT, doublevalue DOUBLE, datevalue DATE) -- holds 'common' properties t_class1 (id RAW(16), amount DOUBLE, source RAW(16), destination RAW(16)) -- holds 'fast' properties for class1. t_class2 (id RAW(16), comment VARCHAR2(200)) -- holds 'fast' properties for class2 --- etc. </code></pre> <p><code>RAW(16)</code> is where <code>Oracle</code> holds <code>GUID</code>s</p> <p>If you want to select all properties for an object, you issue:</p> <pre><code>SELECT i.* FROM ( SELECT id FROM t_class START WITH id = (SELECT class FROM t_declaration WHERE id = :object_id) CONNECT BY parent = PRIOR id ) c JOIN property p ON p.class = c.id LEFT JOIN t_instance i ON i.id = :object_id AND i.class = p.class AND i.property = p.property </code></pre> <p><code>t_property</code> hold stuff you normally don't search on (like, text descriptions etc.)</p> <p>Fast properties are in fact normal tables you have in the database, to make the queries efficient. They hold values only for the instances of a certain class or its descendants. This is to avoid extra joins.</p> <p>You don't have to use fast tables and limit all your data to these four tables.</p> <p>For you task it will look like this (I'll use strings in square brackets instead of GUID's for the sake of brevity):</p> <pre> t_class id parent [ClassItem] [ClassUnknown] [ClassMonitor] [ClassItem] [ClassLCD] [ClassMonitor] t_property class property [ClassItem] price [ClassItem] vendor [ClassItem] model [ClassMonitor] size [ClassLCD] matrixType t_declaration id class [1] [ClassLCD] -- Iiyama ProLite E1700 t_instance -- I'll put all values into one column, disregarding type (INT, VARCHAR etc) id class property value [1] [ClassItem] price $300 [1] [ClassItem] vendor Iiyama [1] [ClassItem] model ProLite E1700s [1] [ClassMonitor] size 17 [1] [ClassLCD] matrixType TFT </pre> <p>If you need some complex query that searches on, say, <code>size</code> AND <code>matrixType</code>, you may remove them from <code>property</code> and <code>instance</code> and create another table:</p> <pre> t_lcd (id RAW(16), size INT, matrixType VARCHAR2(200)) id size matrixType [1] 17 TFT </pre> <p>and use it to join with other properties instead of <code>t_declaration</code> in the query above.</p> <p>But this model is viable even without the fast tables.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow would you model data variables variance on common scheme? SQL
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USQuassnoi
    1. USQuassnoi
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COhm, so if I understand correctly - you did what I have described as a second solution? separate tables with extra variables for each specialization?
      singulars
      1. PO
      1. USKeyframe
    2. COSeparate table are created only when you need to improve performance (I called them fast properties). I'll update the post and describe it in more detail.
      singulars
      1. PO
      1. USQuassnoi
 

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