title: Collaborative Filtering: Non-Personalized item-to-item similarity
body: <p>I'm trying to compute item-to-item similarity along the lines of Amazon's "Customers who viewed/purchased X have also viewed/purchased Y and Z".  All of the examples and references I've seen are for either computing item similarity for ranked items, for finding user-user similarity, or for finding recommended items based on the current users' history.  I'd like to start off with a non-targeted approach before factoring in the current users' preferences.</p>
  
  <p>Looking at the <a href="http://www.cs.umd.edu/~samir/498/Amazon-Recommendations.pdf" rel="nofollow noreferrer">Amazon.com recommendations white paper</a>, they use the following logic for offline item-item similarity:</p>
  
  <pre><code>For each item in product catalog, I1 
    For each customer C who purchased I1
      For each item I2 purchased by customer C
         Record that a customer purchased I1 and I2
    For each item I2 
      Compute the similarity between I1 and I2
  </code></pre>
  
  <p>If I understand correctly, by the time we're at "Compute similiarty between I1 and I2", I have a list of items(I2) purchased in conjunction with a single value I1(the outer loop).</p>
  
  <p>How is this calculation performed?</p>
  
  <p>Another idea is that I'm overthinking this and making it more difficult than I need to - Would it be enough to do a top-n query on the count of I2 bought in conjunction with I1?  </p>
  
  <p>I also appreciate suggestions on whether or not this approach is a correct one.  My product database has about 150k items at any time.  Since the bulk of the reading material I've seen shows user-item similarity or even user-user similarity, should I be looking to go that route instead.</p>
  
  <p>I've worked with similarity algorithms in the past but they've always involved a rank or a score.  I think the only way this would work would be to build a customer-product matrix scoring 0/1 for not purchased/purchased.  Given the purchase history and the item size, this could get really large.</p>
  
  <p>edit: although i listed python as a tag, i'd prefer to keep the logic inside of a db, preferably using Oracle PL/SQL.</p>