I like option #2, simply because we should force ourselves to justify every attribute that is extracted as a queryable parameter, rather than making them queryable at the start.
----- Original Message ----- > Hi Arati, > > > 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. > > Thanks > Georgy > > > On Thu, Feb 13, 2014 at 8:12 AM, Arati Mahimane < > [email protected] > wrote: > > > > Hi All, > > I have been working on defining the Language pack database schema. Here is a > link to my review which is still a WIP - > https://review.openstack.org/#/c/71132/3 . > There are a couple of different opinions on how we should be designing the > schema. > > Language pack has several complex attributes which are listed here - > https://etherpad.openstack.org/p/Solum-Language-pack-json-format > 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' > > Following are the two options that are currently being discussed for the DB > schema: > > Option 1: Having a separate table for each complex attribute, in order to > achieve normalization. The current schema follows this approach. > 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. > Option 2: We could have a predefined subset of attributes on which we would > support search queries. > 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. > 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. > > 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. > Suggestions regarding any other approaches are welcome too! > > Thanks, > Arati > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Georgy Okrokvertskhov > Architect, > OpenStack Platform Products, > Mirantis > http://www.mirantis.com > Tel. +1 650 963 9828 > Mob. +1 650 996 3284 > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
