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

[Mike Kolesnik]

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

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