Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>For the last part of your question, you're asking how to do a <a href="http://en.wikipedia.org/wiki/Cross_tabulation" rel="nofollow noreferrer">cross-tabulation</a> query against an EAV schema. Some databases support this via extensions to the SQL standard, others don't support it at all. For portability you have to do it in your app. PostgreSQL offers the <a href="http://www.postgresql.org/docs/current/static/tablefunc.html" rel="nofollow noreferrer">crosstab function in the tablefunc extension</a> for this.</p> <p>If you go down the <a href="http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model" rel="nofollow noreferrer">EAV</a> path you will sooner or later regret it. It's useful in certain limited circumstances, but it's a bad fit for the relational model and causes lots of pain and problems, not the least of which is awful performance.</p> <p>Consider instead:</p> <ul> <li><p>If at all possible, re-design so you don't need dynamic schema. Probably not possible in your case since your express requirement is a user-editable schema for a web-based database app, but in most cases this is the right choice.</p></li> <li><p>Dynamically create/drop schema with <code>ALTER TABLE</code>, <code>CREATE TABLE</code>, etc. Some databases are much better at this than others. PostgreSQL's transactional DDL can help a lot. Caution is required to avoid this becoming a performance and maintenance nightmare, but it's probably the sanest option if you're trying to model a relational database with dynamic structure.</p></li> <li><p>Key/value stores that are optimised for EAV-like querying; see <a href="http://en.wikipedia.org/wiki/NoSQL#Key-value_store" rel="nofollow noreferrer">Key/Value stores</a>. Be careful, many of these systems don't offer full ACID semantics and may have limited query languages, so you can land up doing lots more work in the application.</p></li> <li><p>Storing XML or JSON in the database. You can do that with a relational DB, but you're likely to be better off with a document database. Same caveats as for K/V stores apply. This approach works ok if you're doing all the querying logic in your app and your data sizes aren't too big.</p></li> <li><p>Using database-specific features like PostgreSQL's <code>hstore</code> to support arbitrary key/value storage where required, and use standard relational design where k/v isn't required. If you want relations as output it's still a major PITA that involves inefficient crosstab queries and joining.</p></li> </ul> <p><a href="https://stackoverflow.com/users/571563/chris-shain">Chris</a> makes a good point: your whole design is very dubious. See: <a href="http://en.wikipedia.org/wiki/Inner-platform_effect" rel="nofollow noreferrer">The inner platform effect</a> and <a href="http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx" rel="nofollow noreferrer">TDWTF's take on it</a>. Seriously, don't go there.</p>
    singulars
    1. This table or related slice is empty.
    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. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

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