Is primar key/foreign key evil in SQL Server?

I worked with Oracle/Sybase before, and I used PK/FK quite often, I had PK
for every table.
Since I started working in SQL Server, I saw serveral big applications (over
2000 concurrent users) don't use PK at all, they just use clustered unique
index and there's no foreign keys either, the integrities are enforced by
triggers.
Can anybody shed some light on me?It seems you've been to a lot of really bad places. :)
I've seen some pretty lousy models myself - that's database models (not
super models). They were in production and had all the problems one would
expect (and more). But I'm pretty sure the ones I've seen would be just as
bad on any other platform (if the same people were involved in designing
them).
ML
http://milambda.blogspot.com/|||Where is Joe?
This should be your favorite topic.
"Matthew" wrote:

> I worked with Oracle/Sybase before, and I used PK/FK quite often, I had PK
> for every table.
> Since I started working in SQL Server, I saw serveral big applications (ov
er
> 2000 concurrent users) don't use PK at all, they just use clustered unique
> index and there's no foreign keys either, the integrities are enforced by
> triggers.
> Can anybody shed some light on me?|||> Since I started working in SQL Server, I saw serveral big applications
> (over
> 2000 concurrent users) don't use PK at all, they just use clustered unique
> index and there's no foreign keys either, the integrities are enforced by
> triggers.
I've seen this too. Fortunately, bad design is not restricted to a single
platform. Your experiences are indicative of you confronting environments
with bad designers, not bad database platforms. This could easily have been
Oracle, DB2, Access, dBase IV, mySQL, etc.
A|||If the same developers have created an Oracle database, then I would expect
to see the same poor implementation there as well. This type of design is
typical when the database is implemented by application developers. They
consider referential integrity constraints to be too rigid and blame them
for making their applications blow up. What they are probably doing is
inserting invalid data into the system and then re-coding it later in some
batch process or at the reporting level.
"Matthew" <Matthew@.discussions.microsoft.com> wrote in message
news:FEF63455-FF98-4AA2-B2B6-C8C0D0FC82F9@.microsoft.com...
>I worked with Oracle/Sybase before, and I used PK/FK quite often, I had PK
> for every table.
> Since I started working in SQL Server, I saw serveral big applications
> (over
> 2000 concurrent users) don't use PK at all, they just use clustered unique
> index and there's no foreign keys either, the integrities are enforced by
> triggers.
> Can anybody shed some light on me?|||Yes, Aaron,
You're absolutely right. Now I know it's the problem from the designers.
I have seen three big SQL Server systems having the same problem, so I
thought it's database specific.
"Aaron Bertrand [SQL Server MVP]" wrote:

> I've seen this too. Fortunately, bad design is not restricted to a single
> platform. Your experiences are indicative of you confronting environments
> with bad designers, not bad database platforms. This could easily have be
en
> Oracle, DB2, Access, dBase IV, mySQL, etc.
> A
>
>|||One day, a law will be passed mandating that only certified database
engineers (preferably Microsoft certified) be allowed to implement a
production database. Until then, we must tolerate these shade tree DBAs.
I'll bet their butt cleavage shows when they bend over to reboot the server.
;-P
"Matthew" <Matthew@.discussions.microsoft.com> wrote in message
news:321963C4-6FE0-4D64-B183-4A75F236B16C@.microsoft.com...
> Yes, Aaron,
> You're absolutely right. Now I know it's the problem from the designers.
> I have seen three big SQL Server systems having the same problem, so I
> thought it's database specific.
> "Aaron Bertrand [SQL Server MVP]" wrote:
>|||Yeah, thanks a lot for THAT mental image.
"JT" <someone@.microsoft.com> wrote in message
news:u%23zfILSTGHA.5440@.TK2MSFTNGP10.phx.gbl...
> One day, a law will be passed mandating that only certified database
> engineers (preferably Microsoft certified) be allowed to implement a
> production database. Until then, we must tolerate these shade tree DBAs.
> I'll bet their butt cleavage shows when they bend over to reboot the
> server. ;-P|||While no longer a developer, I was one and I designed and implements
many a production database. I am proud to say, that for the most part,
if the database server could do it, I tried to make use of it and that
included maintaining referential integrity. Two reasons: 1) The DBMS
was a tried and true method for maintaining referential integrity and
2) why would I want to write a bunch of validation code when all I need
to do is setup the proper PKs, FKs and relationships, and then trap an
error message should bad data attempt to get in. I subscribe to the
theory that never letting bad data in is always better than trying to
figure how to deal with it once it got in. Not all developers are
neanderthal database designers. Its the ones who are that give the rest
of us a bad name.|||> Not all developers are
> neanderthal database designers.
I never said that. Though I do believe there is substantial value in
separating the tasks, if and when you can.
A