views:

1322

answers:

4

I'm writing a very simple blog engine for own use (since every blog engine I encountered is too complex). I want to be able to uniquely identify each post by its URL which is something like /2009/03/05/my-blog-post-slug. To accomplish it in the data tier, I want to create a compound unique constraint on (Date, Slug) where Date is only the date part (ignoring the time of day) of the composition date. I have a few ideas myself (like another column, probably calculated, to hold only the date part) but I came to SO to know what's the best practice to solve this problem.

I doubt SQL Server version matters here, but for the records, I'm on 2008 Express (I appreciate a more portable solution).

Table schema:

create table Entries (
    Identifier int not null identity,
    CompositionDate datetime not null default getdate(),
    Slug varchar(128) not null default '',
    Title nvarchar(max) not null default '',
    ShortBody nvarchar(max) not null default '',
    Body nvarchar(max) not null default '',
    FeedbackState tinyint not null default 0,
    constraint pk_Entries primary key(Identifier),

    constraint uk_Entries unique (Date, Slug) -- the subject of the question
)

Selected Solution:

I think marc's solution is more appropriate, considering this question is about 2008. However, I'll go with the integer method (but not with INSERTs, as it does not ensure the integrity of data; I'll use a precomputed integer column) since I think it's easier to work with the integer thing from the client (in the query).

Thank you guys.

create table Entries (
    Identifier int not null identity,
    CompositionDate smalldatetime not null default getdate(),
    CompositionDateStamp as cast(year(CompositionDate) * 10000 + month(CompositionDate) * 100 + day(CompositionDate) as int) persisted,
    Slug varchar(128) not null default '',
    Title nvarchar(max) not null default '',
    ShortBody nvarchar(max) not null default '',
    Body nvarchar(max) not null default '',
    FeedbackState tinyint not null default 0,
    constraint pk_Entries primary key(Identifier),
    constraint uk_Entries unique (CompositionDateStamp, Slug)
)
go
+5  A: 

Well, in SQL Server 2008, there's a new datatype called "DATE" - you could use that column and create an index on that.

You could of course also add a computed column of type "DATE" to your table and just fill the date portion of the DATETIME column into that computed column, make it PERSISTED, and index it. Should work just fine!

Something like that:

ALTER TABLE dbo.Entries
   ADD DateOnly as CAST(CompositionDate AS DATE) PERSISTED

CREATE UNIQUE INDEX UX_Entries ON Entries(DateOnly, Slug)

Marc

marc_s
Is there a more portable solution? Probably one that will work on 2005 too.
Mehrdad Afshari
Not to my knowledge, no :-) Unless you want to start writing some code to just strip out the time portion of your DATETIME column...
marc_s
Or: you could create three fields for year, month, day and fill those with the results of a call to "DATEPART(...., CompositionDate) and then create your unique index on these three columns plus "Slug".
marc_s
+1 for "PERSISTED" a new concept for me.
Sung Meister
+1  A: 

For SQL 2005, you could do essentially the same thing that marc_s recommended, just use a standard DateTime. It would look something like this (untested code here):

ALTER TABLE Entries ADD
    JustTheDate AS DATEADD(day, DATEDIFF(day, 0, CompositionDate), 0) NOT NULL PERSISTED

Then create your index on (JustTheDate, Slug)

Note: The DATEADD/DATEDIFF statement there calculates just the date of the CompositionDate .

Chris Shaffer
+1  A: 

Since you're on 2008, use the Date datatype as Marc suggests. Otherwise, an easier solution is to have a non-computed column (which means you'll have to populate it on an INSERT) which uses the date in the format YYYYMMDD. That's an integer data type and is small and easy to use.

K. Brian Kelley
This is a nice solution, however I would make that automatically computed = DATEPART(year, date) * 1000000 + DATEPART(month, date) * 100 + DATEPART(day, date)
Mehrdad Afshari
A: 

Over the years we've had a variety of problems with Computed Columns in SQL Server, so we've stopped using them.

You could use a VIEW with a column for date-only - and put a unique index on that VIEW's column.

(A possibly useful side-effect is that you can have the VIEW exclude some rows - so you could implement things like "DateColumn must be unique, but exclude WHERE DateColumn IS NULL)

The existing CompositionDate column could be split into two fields - CompositionDate and CompositionTime - and a Retrieve View that joins them back together if you need that - which would then allow a native index on the Date-only column

(This can be implemented in SQL 2005 and earlier using DateTime - although slightly extravagant for just the Date or Time, and not both)

And lastly you could have an INSERT / UPDATE trigger that enforced that no other record existed with a duplicate CompositionDate (date part only)

Kristen
While your answer might be completely valid for a large scale project, I don't want to overengineer and unnecessarily increase the complexity of such a small project. A unique index on a computed columns has perfectly suited this need.
Mehrdad Afshari
Sounds like a good plan
Kristen