Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2005 Forums
 Transact-SQL (2005)
 Delete Cascade

Author  Topic 

shapper
Constraint Violating Yak Guru

450 Posts

Posted - 2009-08-03 : 09:54:38
Hello,

I have 3 tables: Posts, Tags and PostsTags.

- When a Post is deleted I need to:
Delete all PostsTags related to it.
No record in Tags should be deleted.

- When a Tag is deleted
Delete all PostsTags related to it.
No record in Posts should be deleted.

I am using Cascade Delete for this. My tables are:


create table Tags
(
ID uniqueidentifier not null rowguidcol
constraint PK_Tag primary key clustered,
[Name] nvarchar(40) not null
) -- Tags

create table Posts
(
ID uniqueidentifier not null rowguidcol
constraint PK_Post primary key clustered,
Body nvarchar(max) not null,
Created datetime not null,
Excerpt nvarchar(max) not null,
[File] varbinary(max) filestream default(0x),
IPaper bit not null default 0,
Published bit not null default 0,
Title nvarchar(200) not null,
Updated datetime not null
) -- Posts

create table PostsTags
(
PostID uniqueidentifier not null,
TagID uniqueidentifier not null,
constraint PK_PostsTags
primary key clustered (PostID, TagID),
constraint FK_PostsTags_Posts
foreign key(PostID)
references Posts(ID)
on delete cascade,
constraint FK_PostsTags_Tags
foreign key(TagID)
references Tags(ID)
on delete cascade
) -- PostsTags


Is this the correct way to implement Delete Cascade for the situation I described?

Thank You,
Miguel

TG
Master Smack Fu Yak Hacker

6065 Posts

Posted - 2009-08-03 : 11:27:44
The cascade delete seems to be implemented according to your stated requiments - Have you tested the functionality?

The one problem I do see is that you have CLUSTERED primary keys on uniqueidentifier columns. That is not recommended. I would either make them int identity or (if you need them to be uniqueidentifier) make them nonclustered and use a different column for a clustered index.

Another (maybe questionable) thing is the varbinary [file] column. Have you considered storing the file on a filesystem and just keeping some file attributes to describe the file and location in the table?

Be One with the Optimizer
TG
Go to Top of Page

shapper
Constraint Violating Yak Guru

450 Posts

Posted - 2009-08-03 : 12:40:36
quote:
Originally posted by TG

The cascade delete seems to be implemented according to your stated requiments - Have you tested the functionality?



Yes, I was just wondering if I was doing everything right or if I was missing something.

quote:
Originally posted by TG
The one problem I do see is that you have CLUSTERED primary keys on uniqueidentifier columns.



I do need to use uniqueidentifier.
I don't understand very well when using Clustered or Non Clustered.
What is the default value?

I think clustered improves joins but I am not sure when should I use it or not ... I was using it because on some MSFT code example of Microsoft they always use it.

quote:
Originally posted by TG
Another (maybe questionable) thing is the varbinary [file] column. Have you considered storing the file on a filesystem and just keeping some file attributes to describe the file and location in the table?



Yes, but in this case I really would like to store the files in the new FileSystem of SQL 2008. The maintenance of the application will be easier. And at the same time this database will never be to big.

But doesn't the new FileSystem in SQL 2008 gets the best of two worlds: The Blobs and Saving a file in a folder?

Thank You,
Miguel
Go to Top of Page

TG
Master Smack Fu Yak Hacker

6065 Posts

Posted - 2009-08-03 : 13:23:28
>>I don't understand very well when using Clustered or Non Clustered.

You should definitely read up on this subject in Books Online.
one of my pet-peeves is that sql server makes a primary key clustered by default. Some very simplistic points are: You can only have 1 clustered index per table and any table without a clustered index referred to as an unordered "heap". You can only have one primary key per table but the primary key does NOT have to also be the clustered index. non-clustered indexes will use the key of the clustered index as their row pointer. So the clustered index key shouldn't be too long if you have other indexes on the table. The clustered index is a structure that stores the data in order of the key(s). So good choices for a clustered index is a column (or columns) that will usually be selected in groups of rows. For example an [InvoiceLineitme] table will always be selected as a group of rows for the same invoice. A customer transaction table will almost always deal with all transactions for a given customer. So storing the rows order of invoiceID and customerID respectively would be most efficient. Another typical candidate is a table where you always select the data by daterange (for today, for this week, this month, etc.) So in this case the date column would be a good choice.

A uniqueidentifier is by nature a very random value. The size of the datatype along with its random-ness makes it a poor choice for the clustered index.

>>But doesn't the new FileSystem in SQL 2008 gets the best of two worlds: The Blobs and Saving a file in a folder?
Probably true. I don't have any experience yet with this. Perhaps others can confirm...

Be One with the Optimizer
TG
Go to Top of Page
   

- Advertisement -