architecture question: not representing inheritance in the data model

[PJ6]

First up, I know I'll get some good answers here, but in general, are there
any newsgroups devoted to overall application architecture?

Second, sorry for cross-posting but in this case I think it's appropriate, I
want to hear answers from both sides.

Instead of representing inheritance in the data model, in the particular
project I'm working on now I've decided to do it in OO to keep it looser;
each class gets its own table, because the details vary, but implements an
interface. Each class serves a static collection of itself which it loads
from the database. I get a master list of these items by putting all the
collections together into one of the common interface type.

Obtaining a master list in this way is a great simplification over the route
I would have normally chosen - I otherwise would have had a "base" table
containing the properties of the common interface, and requiring that all
"inheritor" tables have a foreign key to it. I already know that this is a
little iffy since 1 to 1 relationships aren't exactly a good thing. Of
course, I could have thrown everything into one table containing all the
fields in every class, which poses its own problems and ugliness. Not liking
either of these options, I decided to dump representing inheritance at all
in the database. And this led me in a new direction...

Partially through the convenience of generics, I've noticed that since I'm
caching everything locally already, it's easy to just do dictionary lookups
through all this data to find subsets. I'm in effect sidestepping the normal
chore of setting up stored procedures. Actually, I use attributes to specify
table names and fields to populate in each class, so I have no pre-written
SQL at all in the entire application. I sort of like it, but this is
something new for me - I normally push a lot of stuff as far as I can down
into the data model; now I'm just using the database as a "dumb" container.

So to those other architects out there, what is your take on this approach?

Thanks,
Paul

P.S. - some additional information
1. yes, in this case, the user will often need access to all the data at
once since there will be several different global analysis views
2. the data will change only weekly through an automated process

[John Bell]

Hi

You may want to read the patterns and practices recommendations at
http://msdn.microsoft.com/library/de...MSpatterns.asp
such as
http://msdn.microsoft.com/library/de...tml/BOAGag.asp

If you are using user input to generate you SQL make sure you code against
SQL injection techniques. Also look at using sp_executesql to run the code
you generate.

John

"PJ6" wrote:

First up, I know I'll get some good answers here, but in general, are there
any newsgroups devoted to overall application architecture?

Second, sorry for cross-posting but in this case I think it's appropriate, I
want to hear answers from both sides.

Instead of representing inheritance in the data model, in the particular
project I'm working on now I've decided to do it in OO to keep it looser;
each class gets its own table, because the details vary, but implements an
interface. Each class serves a static collection of itself which it loads
from the database. I get a master list of these items by putting all the
collections together into one of the common interface type.

Obtaining a master list in this way is a great simplification over the route
I would have normally chosen - I otherwise would have had a "base" table
containing the properties of the common interface, and requiring that all
"inheritor" tables have a foreign key to it. I already know that this is a
little iffy since 1 to 1 relationships aren't exactly a good thing. Of
course, I could have thrown everything into one table containing all the
fields in every class, which poses its own problems and ugliness. Not liking
either of these options, I decided to dump representing inheritance at all
in the database. And this led me in a new direction...

Partially through the convenience of generics, I've noticed that since I'm
caching everything locally already, it's easy to just do dictionary lookups
through all this data to find subsets. I'm in effect sidestepping the normal
chore of setting up stored procedures. Actually, I use attributes to specify
table names and fields to populate in each class, so I have no pre-written
SQL at all in the entire application. I sort of like it, but this is
something new for me - I normally push a lot of stuff as far as I can down
into the data model; now I'm just using the database as a "dumb" container.

So to those other architects out there, what is your take on this approach?

Thanks,
Paul

P.S. - some additional information
1. yes, in this case, the user will often need access to all the data at
once since there will be several different global analysis views
2. the data will change only weekly through an automated process

[PJ6]

I've disagreed pretty sharply with MS on the subject of data access... but I
guess that's mostly just because of their examples of implementation. The
second article is interesting; thanks for making me take a another look.

Paul

"John Bell" <jb************ @hotmail.com> wrote in message
news:B6******** *************** ***********@mic rosoft.com...

Hi

You may want to read the patterns and practices recommendations at
http://msdn.microsoft.com/library/de...MSpatterns.asp
such as
http://msdn.microsoft.com/library/de...tml/BOAGag.asp

If you are using user input to generate you SQL make sure you code against
SQL injection techniques. Also look at using sp_executesql to run the code
you generate.

John

"PJ6" wrote:

First up, I know I'll get some good answers here, but in general, are
there
any newsgroups devoted to overall application architecture?

Second, sorry for cross-posting but in this case I think it's
appropriate, I
want to hear answers from both sides.

Instead of representing inheritance in the data model, in the particular
project I'm working on now I've decided to do it in OO to keep it looser;
each class gets its own table, because the details vary, but implements
an
interface. Each class serves a static collection of itself which it loads
from the database. I get a master list of these items by putting all the
collections together into one of the common interface type.

Obtaining a master list in this way is a great simplification over the
route
I would have normally chosen - I otherwise would have had a "base" table
containing the properties of the common interface, and requiring that all
"inheritor" tables have a foreign key to it. I already know that this is
a
little iffy since 1 to 1 relationships aren't exactly a good thing. Of
course, I could have thrown everything into one table containing all the
fields in every class, which poses its own problems and ugliness. Not
liking
either of these options, I decided to dump representing inheritance at
all
in the database. And this led me in a new direction...

Partially through the convenience of generics, I've noticed that since
I'm
caching everything locally already, it's easy to just do dictionary
lookups
through all this data to find subsets. I'm in effect sidestepping the
normal
chore of setting up stored procedures. Actually, I use attributes to
specify
table names and fields to populate in each class, so I have no
pre-written
SQL at all in the entire application. I sort of like it, but this is
something new for me - I normally push a lot of stuff as far as I can
down
into the data model; now I'm just using the database as a "dumb"
container.

So to those other architects out there, what is your take on this
approach?

Thanks,
Paul

P.S. - some additional information
1. yes, in this case, the user will often need access to all the data at
once since there will be several different global analysis views
2. the data will change only weekly through an automated process

[Larry Lard]

PJ6 wrote:

First up, I know I'll get some good answers here, but in general, are there
any newsgroups devoted to overall application architecture?

Not that I know of, but don't let that stop you. I've snipped your post
but it sounded mostly sound. I just thought you might find this page
(and the whole site it's on in fact) interesting. It's sometimes useful
to be reminded that generally nothing we do in software development
requires new or original thought :)

<http://www.agiledata.o rg/essays/mappingObjects. html>

--
Larry Lard
Replies to group please