architecture question: not representing inheritance in the data mo

Hi
You may want to read the patterns and practices recommendations at
http://msdn.microsoft.com/library/d...
Spatterns.asp
such as
http://msdn.microsoft.com/library/d...Gag
.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 ther
e
> 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 rou
te
> 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 liki
ng
> 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 lookup
s
> through all this data to find subsets. I'm in effect sidestepping the norm
al
> chore of setting up stored procedures. Actually, I use attributes to speci
fy
> 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 wly through an automated process
>
>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" <jbellnewsposts@.hotmail.com> wrote in message
news:B6CD35F3-6D60-453D-802F-906DD9F7CCE7@.microsoft.com...
> Hi
> You may want to read the patterns and practices recommendations at
> http://msdn.microsoft.com/library/d.../MSpatterns.asp
> such as
> http://msdn.microsoft.com/library/d...G
ag.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:
>