|
|
Posted by Dan Guzman on 09/25/12 11:25
> But, having a
> compond clustered index seems like a good idea if you constantly want
> to find all books by a given author. The books will then be returned
> in bookid order.
Although it is likely that data will be returned in sequence by bookid, the
order is guaranteed only when bookid is specified in an ORDER BY clause. A
clustered index including bookid will facilitate efficient ordering in this
case.
--
Hope this helps.
Dan Guzman
SQL Server MVP
<eric.nave@gmail.com> wrote in message
news:1125527844.570677.118750@z14g2000cwz.googlegroups.com...
> Erland Sommarskog wrote:
>> That looks a little funny. Since bookid is unique, why add authorid
>> to the PK?
>
> Only for the purpose of having the clustered index that way. I think
> my example would have been better if I'd made it a case of, "should I
> have a simple or a compond index" and left the key out of it. My
> mistake.
>
>> Then again, PK of a books table should probably be the ISBN, as that
>> is a natural key.
>
> Well, this is just an example off the top of my head. Books and
> authors is just the first think I came up with.
>
>> And there should probably be a relation table, as a book can more than
>> one author.
>
> Same response as above.
>
>> Having the clustered index on authorid is probably better than clustering
>> on ISBN, yes. But there not really any reason to add it to the PK of
>> books.
>
> I concede that there's no reason to have it in the PK. But, having a
> compond clustered index seems like a good idea if you constantly want
> to find all books by a given author. The books will then be returned
> in bookid order.
>
Navigation:
[Reply to this message]
|