SQL Performance Tuning [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

SQL Performance Tuning [Electronic resources] - نسخه متنی

Peter Gulutzan, Trudy Pelzer

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید




Parting Shots


The temptation is always strong to store aggregate values somewhere in the databasein a summary column, a summary row, or even a summary table. In a data warehouse, this is a natural inclination and everyone realizes that it's faster to look up a calculated value than to recalculate the value. In an Online Transaction Processing (OLTP) environment, stored summaries are rarer for the following reasons: (a) updates that happen in two places are prone to error; and (b) if a specific query is really frequent, then it will be cached anyway.

The temptation is occasionally strong to calculate aggregate values on the client instead of on the server. This is possible if you have a read-only result set and you can program in a host language. (We have seen this recommended as a tip in some MySQL-related books.) In many shops, client-side aggregating is forbidden because it doesn't save enough to make up for the extra programming time and network transmission time.

The temptation should be strong to avoid GROUP BY and aggregate functions entirely. We can only hope that some of what we've said here will make them more palatable.

/ 124