Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Don't associate memcached entries with the tables, associate the entries with entities (i.e. rows).</p> <p>For example, make a memcached entry for each members, and the entry stores the list of that member's friends.</p> <p>Here's an example with PHP. I know you're using ASP.NET, so treat this as pseudocode. :-)</p> <pre><code>&lt;?php $m = new Memcached(); $m-&gt;append('Luke.Doolittle', '|Bill Karwin'); $m-&gt;append('Bill Karwin', '|Luke.Doolittle'); </code></pre> <hr> <p>Re your comments:</p> <blockquote> <p>The problem that I see is that there is no generalized pattern for placing objects in memcached then. </p> </blockquote> <p>Right. In relational databases, there <em>is</em> a formal pattern for modeling data. <a href="http://en.wikipedia.org/wiki/Database_normalization" rel="nofollow noreferrer">Normalization</a> is a well-defined method for modeling data to reduce redundancy and prevent anomalies. The optimal normalized organization is <strong>determined by the data itself,</strong> and relationships between data.</p> <p>In non-relational databases, there is no formalization of data modeling. The best way to organize non-relational data is not determined by the data, it's <strong>determined by your queries</strong> you need to run against that data. In this way, it's similar to the process of defining indexes or applying denormalization to a relational database.</p> <blockquote> <p>The logic would be different for each type of object. Does that make sense?</p> </blockquote> <p>Actually, the logic would be different for each type of <em>query</em> you need to run against that object. This is what leads us to store data redundantly in non-relational data stores. Because we might want to run a variety of queries against the same data, and that means we need to access the data differently to optimize for each type of query.</p> <blockquote> <p>How do you perform removes using this technique?</p> </blockquote> <p>Fetch the whole string from memcached, explode the values into an array, remove the element you want to remove, implode the new array, and store it back into memcached. </p> <p>My example above was pretty simple; it also doesn't enforce uniqueness.</p> <p>You might be interested in checking out <a href="http://code.google.com/p/redis/" rel="nofollow noreferrer">Redis</a>, which works like memcached but also support lists and sets natively.</p> <hr> <p>I would use SQL to store data relationally, using rules of normalization. Use non-relational methods on a case-by-case basis to improve performance for specific high-priority queries -- <em>AFTER</em> you have used profiling to measure and prove where your bottlenecks actually are (avoid premature optimizations). </p> <p>I count the following as non-relational solutions:</p> <ul> <li>Denormalization</li> <li>Indexing (did you know the SQL standard doesn't mention indexes at all?) </li> <li>Caching</li> <li>NoSQL data stores</li> </ul> <p>The more tools you have in your toolbox, the more flexible you can be in responding to performance issues.</p>
 

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