[Engine-devel] What type of DB inheritance to use?
Itamar Heim
iheim at redhat.com
Sun May 12 14:05:52 UTC 2013
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 at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>>
>>>>
>>
>>
More information about the Engine-devel
mailing list