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

From: "Itamar Heim" <iheim(a)redhat.com&gt; To: "Mike Kolesnik" <mkolesni(a)redhat.com&gt; Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; Sent: Sunday, May 12, 2013 5:05:52 PM Subject: Re: [Engine-devel] What type of DB inheritance to use? 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?

> >> >>> >>>> >>>>> >>>>> 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 >>>>> >>>> >>>> >> >> _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel