- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Admin
Admin
Admin
I am puting index card on detabase servers, but no preformance increase.
Admin
Admin
Admin
Admin
Filed Under: deadbeat dad
Admin
Admin
Admin
Admin
Admin
When these six elements combine, here comes... CAPTAIN PLANET!
Admin
Admin
I am a software developer and I have a pickup truck....it's a double whammy.
Admin
I just decided I don't like the term "enterprisey" for cases like this. I think we ought to switch "enterpriseismic" (EN-ter-pry-SIGHS-mic)...
...as in earthquake...
...as in disaster.
Admin
Admin
Admin
"Unless the reporting is doing some sort of joining/ selects against other tables with the temp data, which would be another WTF. "
I am not sure that is always a WTF. Frequently data gets organized into Parent-child relationships which may simply inserts of new records (where the parent ID) will be know by the software doing the insert. Lowing the cost of inserts transaction may be very important, but make reporting a pain. That can be a good trade.
Often in those cases you will produce a "flattened" temp table to report against, that might indeed join with other things.
Admin
Admin
It's disturbing that you think this is true of DBAs.. You must have had some bad experiences. I don't think, however, that your experiences are indicitive of general knowledge of a DBA. At least where I work, they know quite a bit about indexing.
Admin
But yes, I have had some bad experiences. I have worked with data warehouses (large tables, updated nightly) that had poor indexing (bad column order, for example) on some tables and no indexing on others. I've worked with databases that had no primary keys, foreign keys, etc. I have even worked with DBAs that have literally told me "I don't know much about indexes," in those exact words. I'm surprised and disturbed at how many I've encountered.
Admin
Nah, that sounds too dicey...
Admin
Ummmmmmmmmm, that's the point. Otherwise it's just a regular index. That's why you get exactly one clustered index per table, and why if you're selecting by the clustered index's field(s), it's as fast as it can possibly be.
Admin
Joo need to go back to DBA school, mang. A clustered index on an incremental field is just about the worst choice for a clustered index. You WANT to vary the insertion point so that you don't hot spot the leaf nodes. That's where the fill-factor comes in, with regard to re-ordering the physical pages. Actual usage and testing are required to figure out the optimal set up, but decent guessing based on expected transaction throughput and size can work.
Those articles you mention are no doubt written by people with absolutely no understanding of a b-tree.
The advice quoted is so unbelievably bad, it HAS to be sarcastic.