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

----- Original Message ----- > 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? > IMO, the following fields will fit most providers, at least the ones we plan to support in the near future: * id * name * type * URL * requires_authentication (boolean) to support development/POC/testing... mode * username * password

> > > >> > >>> > >>>> > >>>>> > >>>>> 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 >