Hi Rod,

We store documents with paragraph granularity with some exceptions: tables and lists are stored each in a single record. In the future, tables and lists will be stored with cell and item granularity respectively. That's basically our evolution plan for data, which must synch with separate input, output, and archive processes.

Currently the table has nearly 800,000 records, and this will increase drastically as more authoring projects come online, as entire books are translated, as country-specific sections are added, and so on.

A clustered index would certainly help queries. The problem is this is a transactional database where inserts and updates are killer, way more painful than nonclustered index queries.


**--** Steve




>Steve,
> I do have a question about this table you are talking about.
>
> How many records will this table have ? From what I read I think you said it could have millions (chapter records I believe) If the table has only a hundred or so records, you will probably never benefit from an index(As a diciplined practice I always would though)
>
>Second: do you every query this table. If it does have millions of records I cannot see how a clustered index would not benefit you. For instance: in a hierarchy table like you describe I always store the highest level node in all subsequent nodes. That way I can query and say give me all the contents for this entity without calling a rercursive algorithm.
>
>
>Thanks
>Rodman