title: Column oriented database vs row oriented database
body: <p>I have used row oriented database design for long time and except for datawarehouse projects and Big data samples, I have not used column oriented database design for OLTP app.</p>
  
  <p>My row oriented table looks like </p>
  
  <pre><code>ID, Make, Model, Month, Miles, Cost
  1   BMW   Z3     12     12000  100
  </code></pre>
  
  <p>Some people in our team advocating column oriented database design. 
  They suggest that all the column names should be property names in a Property table.
  Then another table Quote will have two columns PropertyName and PropertyValue.</p>
  
  <p>In the .net code, we read each key and compare and convert to strongly typed object. The code is really getting messy.</p>
  
  <pre><code>if (qwi.DomainCode == typeof(CoreBO.Base.iQQConstants.MBPCollateralInfo).Name)
       {
          if (qwi.RefCode == iQQConstants.MBPCollateralInfo.ENGINETYPE)
          {
             Aspiration = qwi.Value;
          }
          else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.FUELTYPE)
          {
             FuelType = qwi.Value;
          }
          else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.MAKE)
          {
             Make = qwi.Value;
          }
          else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.MILEAGE)
          {
             int reading = 0;
             bool success = int.TryParse(qwi.Value, out reading);
             if (success)
             {
                OdometerReading = reading;
             }
  }
  }
  </code></pre>
  
  <p>The arguement for this column oriented design is that we won't have to change table schema and the stored proc(we are still using stored proc instead of Entity Framework).</p>
  
  <p>Seems like we are heading into real problem. Is Column oriented design well accepted in the industry.</p>