Re: [Engine-devel] What type of DB inheritance to use?

On 05/13/2013 08:33 AM, Mike Kolesnik wrote: > ----- Original Message ----- >> On 05/12/2013 04:31 PM, Mike Kolesnik wrote: >>> >>> ----- Original Message ----- >>>> On 05/12/2013 03:16 PM, Mike Kolesnik wrote: >>>>> ----- Original Message ----- >>>>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> I would like to have your opinions on which inheritance type to use >>>>>>> in >>>>>>> the DB. >>>>>>> We are adding an "external provider" entity to the system which will >>>>>>> be >>>>>>> able to provide various resources (networks, hosts, etc). >>>>>>> >>>>>>> These providers will be distinguishable by "type". >>>>>>> The basic definition of a provider contains: >>>>>>> >>>>>>> * name >>>>>>> * description >>>>>>> * url >>>>>>> * type >>>>>>> >>>>>>> Some providers might need additional properties such as: >>>>>>> >>>>>>> * user >>>>>>> * password >>>>>> >>>>>> what type of provider won't require authentication? >>>>> >>>>> Quantum provider in the 1st implementation will not require these >>>>> fields. >>>>> It will eventually require some sort of authentication, but not >>>>> necessarily >>>>> these fields, or only these fields. >>>> >>>> I'm not talking about a POC. >>>> unless we pass through credentials of users for some actions, how do you >>>> use a provider without user/password (or client cert, etc. - i.e., all >>>> authentication methods are usually similar on the info you need to >>>> persist)? >>> >>> I did not say that we will use Quantum without auth, only that these >>> fields >>> may or >>> may not necessarily be in the Quantum provider entity. >>> >>> I think this is regardless of the main discussion here of inheritance, >>> which I >>> think will happen regardless of how Quantum provider is implemented. If >>> you >>> wish >>> to discuss these details I'll be happy do it on a new thread, so that >>> this >>> one >>> can stay focused on the subject of DB inheritance. >> >> how many discrepancies do we expect between the various providers, to be >> actually defined at provider level rather than consumption level? > > I expect at least a few, there has to be some divergence. > > For instance, if we model Glance as a provider then it may require a > "tenant name" > field which is not something Quantum provider requires. actually, since these are both openstack services, why would one need a tenant name and the other wouldn't?

> Both these providers will be probably linked to a keystone entity, while a > host > provider (such as Foreman) will not be since it doesn't work with keystone. > > We can't expect all providers to be the same, some divergence is bound to > occur. true, but keystone is one of the few authentication aspects which are going to be common to multiple providers, hence don't make sense to be provider specific.

> >> >>> >>>> >>>>> >>>>>> >>>>>>> >>>>>>> In Java this is easily represented by inheritance. >>>>>>> >>>>>>> In the DB however, there are 3 approaches that we can take: >>>>>>> >>>>>>> 1. No inheritance. >>>>>>> This means that each type will wit in his own table, with no >>>>>>> relation or re-use. >>>>>>> 2. Single table inheritance. >>>>>>> All types sit in a single table, and each has his >>>>>>> corresponding >>>>>>> columns. >>>>>>> 3. Multiple table inheritance. >>>>>>> Each type sists in his own table, where the PK is FK for the >>>>>>> most >>>>>>> basic table (providers). >>>>>>> >>>>>>> >>>>>>> Pros for each approach: >>>>>>> >>>>>>> 1. None that I can think of. >>>>>>> 2. No joins: >>>>>>> Better performance >>>>>>> Easier for developer to see the DB info >>>>>>> Facilitate column reuse >>>>>>> 3. Constraints can be set on each column >>>>>>> >>>>>>> Cons for each approach: >>>>>>> >>>>>>> 1. No reuse of DB entities + no compliance for column types >>>>>>> Most cumbersome to query all providers >>>>>>> 2. Can't put some constraints on non-base columns (esp. not null) >>>>>>> 3. Joins are needed - opposite of the pros of 2. >>>>>>> >>>>>>> From personal experience, I find #2 to be better and easier to >>>>>>> work >>>>>>> with & maintain. >>>>>>> >>>>>>> What are your thoughts? >>>>>>> >>>>>>> Regards, >>>>>>> Mike >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >>