Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>If you want all fields to be indexed all the time, try a technology like <a href="http://lucene.apache.org/solr/" rel="nofollow noreferrer">Apache Solr</a> that indexes everything. The main purpose of Solr is to be a fulltext search engine, but it's basically a document-oriented database.</p> <p>Here are comments about other options:</p> <ol> <li><p>EAV is no good, and I'm against use it. It breaks many rules of relational database design, and it won't scale. I've written about this on Stack Overflow a lot, so search for <a href="https://stackoverflow.com/search?q=user:20860%20%5Beav%5D">my answers</a> under the <code>eav</code> tag.</p></li> <li><p>You don't need just 30 indexes -- you need up to 30-factorial indexes to handle any possible combination of indexes. Keep in mind you can make multi-column indexes, and these types of indexes are important to support certain queries. Of course this is totally impractical to create so many indexes; you need to create indexes to match the queries you want to optimize for. If you don't know what fields you'll have and what queries you'll have against them, you can't optimize.</p></li> <li><p>Document-oriented databases like MongoDB/CouchDB aren't magic, no matter how much their advocates try to claim that they are. They requires that you index documents for fast searches, and that means you need to know the indexable fields of a document.</p> <p>Creating an index at runtime is a problem, because it can take a long time, depending on how much data there is to index. You'll have to find a way to run the index creation "offline" (i.e. don't make the user wait for it during a single http request) and then notify them when it's complete.</p></li> <li><p>You should read about <a href="http://backchannel.org/blog/friendfeed-schemaless-mysql" rel="nofollow noreferrer">How FriendFeed uses MySQL to store schema-less data</a>. They use a Serialized LOB, basically combine all the custom attributes together into one XML or JSON blob. So users can create any number of additional custom fields anytime they want. But before a given custom field can be made searchable, you would create a child table that references rows where that field contains a given value. Thus you get an index that is only as large as the number of instances of a given user-defined custom field. And you don't need to make <em>every</em> field searchable.</p></li> </ol>
 

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