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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
