12:42 p.m.
------=_Part_165720_1428728257.1368351734157
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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
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
------=_Part_165720_1428728257.1368351734157
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"font-family: times new roman, new york,
times, se=
rif; font-size: 12pt; color: #000000"><div>Hi
All,<br></div><div><br></div>=
<div>I would like to have your opinions on which inheritance type to use in=
the DB.<br></div><div>We are adding an "external provider"
entity to the s=
ystem which will be able to provide various resources (networks, hosts, etc=
).<br></div><div><br></div><div>These providers will
be distinguishable by =
"type".<br></div><div>The basic definition of a provider
contains:</div><di=
v><ul><li>
name</li><li>description</li><li>url</li><li>type</li></ul><div>=
Some providers might need additional properties such
as:<br></div><div><ul>=
<li>user<br></li><li>password<br></li></ul><div>In
Java this is easily repr=
esented by
inheritance.<br></div><div><br></div><div>In the DB
however, the=
re are 3 approaches that we can
take:<br></div><div><ol><li>No inheritance.=
<br>This means that each type will wit in his own table, with no relation o=
r re-use.<br></li><li>Single table inheritance.<br>All types sit
in a singl=
e table, and each has his corresponding columns.<br></li><li>Multiple
table=
inheritance.<br>Each type sists in his own table, where the PK is FK for t=
he most basic table
(providers).<br></li></ol><div><br></div><div>Pros
for =
each approach:<br></div><div><ol><li>None that I can think
of.<br></li><li>=
No joins:<br> Better
performance<br> &nbs=
p; Easier for developer to see the DB
info<br> =
Facilitate column reuse<br></li><li>Constraints can be set on each
column<b=
r></li></ol></div></div></div></div><div>Cons
for each approach:<br></div><=
div><ol><li>No reuse of DB entities + no compliance for column
types<br>Mos=
t cumbersome to query all providers<br></li><li>Can't put some
constraints =
on non-base columns (esp. not null)<br></li><li>Joins are needed -
opposite=
of the pros of 2.<br></li></ol><div>From personal experience, I
find #2 to=
be better and easier to work with &
maintain.<br></div><div><br></div>=
<div>What are your
thoughts?<br></div></div><div><br></div><div><span
name=
=3D"x"></span>Regards,<br>Mike<span
name=3D"x"></span><br></div><div><br></=
div></div></body></html>
------=_Part_165720_1428728257.1368351734157--