Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase ««12

Best Practices in an Adhoc Environment Expand / Collapse
Posted Monday, December 22, 2003 2:06 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 10:20 AM
Points: 3,409, Visits: 3,032
TRUNCATE also fails if you use foreign key constraints, regardless of whether they are violated.

I fully agree that people should not be allowed to create datbases willy-nilly.

If developers go creating databases then

  • who is going to put the databases onto a backup schedule.
  • Who is going to ensure that the correct database options are set.
  • Who is going to check server capacity i.e. Mr Developer decides he needs a 10Gb database.

He was not wholly unware of the potential lack of insignificance.

LinkedIn Profile

Newbie on
Post #89672
Posted Friday, December 17, 2004 7:56 AM


Group: General Forum Members
Last Login: Tuesday, September 6, 2005 10:53 AM
Points: 107, Visits: 1

About primary keys:

Are they still a good idea no matter how complex they become or how irrelevant they are?

Example:  I have this calculation table (when used with joins and group by it does wonders )

ComputedID as int,
SrcID as int,
scale as float,
offset as float

I could make a PK field, but why except maybe for making it slightly easier to make an editor)?

I also have a table that is something like

CustID int,
BudID int,
AcctID int,
BldgID int,
SrcID int,
Dt DateTime,
Reading float,
ReliabilityID int

The PK would be (CustID, BudID, AcctID,  BldgID, SrcID, DT)... but does it make sense to make a PK that complex, esp since I don't plan to pull things out in that order (mostly, select Dt,Reading,Reliability order by DT where xxxx)?


Post #151616
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse