----- Original Message ----- > > > ----- Original Message ----- > > From: "Itamar Heim" <[email protected]> > > To: "Mike Kolesnik" <[email protected]> > > Cc: "engine-devel" <[email protected]> > > 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
Sounds good to me > > > > > > >> > > >>> > > >>>> > > >>>>> > > >>>>> 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 > > >>>>> [email protected] > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >>>>> > > >>>> > > >>>> > > >> > > >> > > > > _______________________________________________ > > Engine-devel mailing list > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
