"Erland Sommarskog" <esquel@[EMAIL PROTECTED]
> wrote in message
news:Xns9AD16642DF5B0Yazorman@[EMAIL PROTECTED]
SNIP ]
> You seem to be concerned with indexing, and it cannot be denied that
> there might be a problem. Then again, if you build the index once,
> and new data is added in such a way that there is little fragmentation,
> it's not an issue at all. We would need to know more how the table looks
> like, and how it's loaded to give more specific advice.
I've been reading this thread with interest. I have never had to deal with
monster databases, for some suitable definition of "monster" (you'll know
one when you see one, I guess). I started doing some research, which is
ongoing: for an intermediate-level guy like myself these were helpful:
http://www.sqljunkies.com/article/f4920050-6c63-4109-93ff-c2b7eb0a5835.scuk
and
http://msdn.microsoft.com/en-us/library/aa964133.aspx
were very useful. Several questions I have related to indexing are:
1) I saw that MySQL has a delayed insert feature, that is, inserts wait
until the table is not in use by any other thread, plus inserts get
written
as a block. I can see this being useful if there are lots of selects, and
an
insert can take a fair bit of time. Does SQL Server have anything like
this?
2) If the new data is being delivered in batches (large batches) it seems
to
me that scheduling a drop index - bulk insert - create index would be
better, at least in many cases, since the index would get rebuilt from
scratch. Is this correct?
AHS
|
