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

[Oved Ourfalli]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Mike Kolesnik" <mkolesni at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> 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 at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>>>
> >>>>
> >>
> >>
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>