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

Applying Service Packs

Are there any guidelines or best practices for deploying or testing Service Packs? What types of tests should be performed prior to upgrading or do I just trust Microsoft?I always put them on test machines first for a month or so. Enough time that some applications have had a testing cycle, anyway. If there are no major complaints, the first production guinea pig is selected, and watched for a week. If no major problems come up, then the rest of the machines get it. never trust Microsoft. They are human, too...well, half human.|||That's the way to do it. We have dev, test, and production environments. Dev gets the release 1st, and if no one screams after a couple of weeks, we apply it to test. Again, the absence of any wailing and gnashing of teeth means we move to production.

Plus, an added benefit is that you get to practice the install in case something goes horribly wrong (oh my ... would that ever happen?)|||Definitely agree with the two previous posters. In addition, read the release notes, particularly if you have a clustered environment or one where you use replication (upgrades MUST be done in a certain order when replication is involved)

Lempster|||Thank you all!! Pretty much thought so, but just wanted to see how others were handling it. :)