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