<div class="gmail_quote">On Fri, Jun 1, 2012 at 12:41 PM, Rodrigo Souza <span dir="ltr">&lt;<a href="mailto:rodrigo@hostplan.com.br" target="_blank">rodrigo@hostplan.com.br</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font><font face="verdana,sans-serif">I found the idea excellent! But we have to analyze the situation better for not having a table with many records, impacting on the performance of the database. Let me give an example of a client of mine:</font></font></blockquote>
<div><br></div><div>This is a good point, as consolidating addresses into a single table is the opposite of sharding, but I think the vtiger_crmentity table is a worse example of this.  A compromise might be to create a single table for each type of address.  For example, <span style>vtiger_quotesshipads and </span><span style>vtiger_accountshipads could be consolidated into a single vtiger_shippingaddress table used by both Accounts and Quotes modules, much like vtiger_inventoryproductrel is already used by both Quotes and Sales Orders modules.</span></div>
<div><br></div><div>One problem I&#39;ve thought of with the related record approach is that the list views do not currently support searches on related modules, and searching on address is very useful.</div></div>