I'm also a +1 for #2. However as discussed on IRC, we should clearly spell out that the JSON blob should never be treated in a SQL-like manner. The moment somebody says 'I want to make that item in the json searchable' is the time to discuss adding it as part of the SQL schema.
On 2/13/14 4:39 PM, "Clayton Coleman" <[email protected]> wrote: >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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
