New answers tagged

1

Lots of good answers already. I just want to add a rule of thumb and a worst case scenario. Rule of thumb: if an index is not used frequently by SEEK operation, it can be considered "bad", and should be revised or removed. Worst scenario: a clustered index in sql server is composed of GUID (non-sequential) column, and thus frequent inserts may cause ...


7

Well, I think you have some mixed concepts: An index improves performance of READ OPERATIONS ( those of SELECT ) while increase the processing time of INSERT/UPDATE OPERATIONS ( So they don't improve all CRUD operations, as you've heard ). As each time you insert a new row, you should update the index, if you have too much indexes you are increasing the ...


2

Trying to stay database-neutral: Reading, filtering Indexes radically speed up ordering and filtering operations on a table - often by a factor of 1000 times or more. Compared to a phone book, an index lets you look up a single person up directly, because it's alread sorted alphabetically. If the phone book were just an unordered list of a million names ...


3

Having too many indexes can indeed cause performance problems. If many indexes have very similar statistics it is possible that the optimizer cannot reliably decide on the most useful choice of indexes. (I learned this when working with a database where almost every column was indexed.) In that case, we reduced the number of indexes significantly by ...


1

Triggers are an auditing mechanism that satisfies your criteria. they are present in the ISO/ANSI standard (ISO 9075) they can be used to tracks row-level changes they can save data to tables, hence can be queried using SQL Only thing I do not understand in your question is "database agnostic" - what does it mean, precisely?



Top 50 recent answers are included