<div dir="ltr">Hi Arati,<div><br></div><div><br></div><div>I would vote for Option #2 as a short term solution. Probably later we can consider using NoSQL DB or MariaDB which has Column_JSON type to store complex types.</div>
<div><br></div><div>Thanks</div><div>Georgy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 8:12 AM, Arati Mahimane <span dir="ltr"><<a href="mailto:arati.mahimane@rackspace.com" target="_blank">arati.mahimane@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>
<div>Hi All,</div>
<div><br>
</div>
<div>I have been working on defining the Language pack database schema. Here is a link to my review which is still a WIP - <a href="https://review.openstack.org/#/c/71132/3" target="_blank">https://review.openstack.org/#/c/71132/3</a>.</div>

<div>There are a couple of different opinions on how we should be designing the schema.</div>
<div><br>
</div>
<div>Language pack has several complex attributes which are listed here - <a href="https://etherpad.openstack.org/p/Solum-Language-pack-json-format" target="_blank">https://etherpad.openstack.org/p/Solum-Language-pack-json-format</a></div>

<div>We need to support search queries on language packs based on various criteria. One example could be 'find a language pack where type='java' and version>1.4'</div>
<div><br>
</div>
<div>Following are the two options that are currently being discussed for the DB schema:</div>
<div><br>
</div>
<div><b>Option 1:</b> Having a separate table for each complex attribute, in order to achieve normalization. The current schema follows this approach.</div>
<div>                   However, this design has certain drawbacks. It will result in a lot of complex DB queries and each new attribute will require a code change.</div>
<div><b>Option 2:</b> We could have a predefined subset of attributes on which we would support search queries. </div>
<div>                    In this case, we would define columns (separate tables in case of complex attributes) only for this subset of attributes and all other attributes will be a part of a json blob.</div>
<div>                    With this option, we will have to go through a schema change in case we decide to support search queries on other attributes at a later stage.</div>
<div><br>
</div>
<div>I would like to know everyone's thoughts on these two approaches so that we can take a final decision and go ahead with one approach.</div>
<div>Suggestions regarding any other approaches are welcome too!</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Arati</div>
</div>
<div><br>
</div>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><font color="#999999"><span style="background-color:rgb(255,255,255)">Georgy Okrokvertskhov<br>
Architect,<br><span style="font-family:arial;font-size:small">OpenStack Platform Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284</font><br></div>
</div>