فیلد محاسباتی رو بهتره چه جاهایی استفاده کنیم؟

[tst835]

سلام.
من درباره محل استفاده از فیلد محاسباتی ابهام دارم.
ببینید من یک جدول فروش محصول با چند قابلیت دارم : 1. نوع نخفیف (میتونه درصدی یا قیمت معین باشه) 2. محاسبه سود بازاریاب
حالا سوال من اینه :
آیا در چنین جاهایی بهتر نیست از فیلد محاسباتی استفاده بشه؟ چون اگه بخوایم خودمون این کار رو انجام بدیم وارد نوشتن کوئری هایی میشیم که دارای پیچیدگی هستند.
گرچه در تعداد رکورد کم شاید تفاوتی در سرعت اجرای این دو روش وجود نداشته باشه ولی من به چند میلیون رکورد و مبالغ سنگین فکر میکنم.
سوال دیگه اینکه فیلد محاسباتی رو تو کتاب ها اصطلاحا بهش میگفتن صفت مشتق (صفتی که مقدارش از روی صفات دیگه محاسبه میشه) و اونجا میگفتن که صفت مشتق رو نباید به عنوان یک فیلد در جدول آورد و در موقع نیاز باید اونو محاسبه و برگشت داد. اگر نباید باشه چرا مایکروسافت چنین قابلیتی رو در SQL قرار داده؟ این تناقض رو چطور میشه توضیح داد؟
تشکر

[SabaSabouhi]

سلام.
من درباره محل استفاده از فیلد محاسباتی ابهام دارم.
ببینید من یک جدول فروش محصول با چند قابلیت دارم : 1. نوع نخفیف (میتونه درصدی یا قیمت معین باشه) 2. محاسبه سود بازاریاب
حالا سوال من اینه :
آیا در چنین جاهایی بهتر نیست از فیلد محاسباتی استفاده بشه؟ چون اگه بخوایم خودمون این کار رو انجام بدیم وارد نوشتن کوئری هایی میشیم که دارای پیچیدگی هستند.
گرچه در تعداد رکورد کم شاید تفاوتی در سرعت اجرای این دو روش وجود نداشته باشه ولی من به چند میلیون رکورد و مبالغ سنگین فکر میکنم.
سوال دیگه اینکه فیلد محاسباتی رو تو کتاب ها اصطلاحا بهش میگفتن صفت مشتق (صفتی که مقدارش از روی صفات دیگه محاسبه میشه) و اونجا میگفتن که صفت مشتق رو نباید به عنوان یک فیلد در جدول آورد و در موقع نیاز باید اونو محاسبه و برگشت داد. اگر نباید باشه چرا مایکروسافت چنین قابلیتی رو در SQL قرار داده؟ این تناقض رو چطور میشه توضیح داد؟
تشکر

سلام
من اگه جای شما باشم، برای این اقلام از فیلد‌های محاسباتی استفاده نمی‌کنم.
حداقل تو کشور ما چیزی به عنوان قانون تغییر ناپذیر وجود نداره. به هر دلیلی کارفرمای شما بدون اعلام قبلی تصمیم می‌گیره
که این مقدار رو برای یک نفر تغییر بده.
به نظر من هر کاری که می‌خواهی انجام بدی، انجامش بده و مقدار نهایی رو تو دیتابیس ثبت کن.

این نتیجه‌ی تجربه‌ی سال‌ها کار تو این کشور با کارفرماهای متفاوت هست.
این نوع کار کردن ( استفاده از فیلد محاسباتی برای کارمزد بازاریاب یا تخفیف ) به درد کشور ما نمی‌خوره و برای دیگر کشورها احتمالاً
کاربرد داره.

صبا صبوحی

[tst835]

سلام
من اگه جای شما باشم، برای این اقلام از فیلد‌های محاسباتی استفاده نمی‌کنم.
حداقل تو کشور ما چیزی به عنوان قانون تغییر ناپذیر وجود نداره. به هر دلیلی کارفرمای شما بدون اعلام قبلی تصمیم می‌گیره
که این مقدار رو برای یک نفر تغییر بده.
به نظر من هر کاری که می‌خواهی انجام بدی، انجامش بده و مقدار نهایی رو تو دیتابیس ثبت کن.

این نتیجه‌ی تجربه‌ی سال‌ها کار تو این کشور با کارفرماهای متفاوت هست.
این نوع کار کردن ( استفاده از فیلد محاسباتی برای کارمزد بازاریاب یا تخفیف ) به درد کشور ما نمی‌خوره و برای دیگر کشورها احتمالاً
کاربرد داره.

صبا صبوحی
ممنون دوست عزیز.
من خوب توضیح ندادم. منظورم محاسبه سود بازاریاب یا محاسبه درصد تخفیف بصورت فیلد محاسباتی نیست. این موارد (نوع تخفیف، میزان تخفیف، سود بازاریاب) توسط کاربر مشخص و در دیتابیس ثبت میشن (به قول شما ممکنه مشتری بخواد بخاطر سود زیاد یک فروش یا ... درصد سود بیشتری رو برای یک بازاریاب و برای یک فروش خاص در نظر بگیره). منظور من محاسبه دو مفهوم "کل فروش" و "خالص فروش" (مخصوصا این دومی یعنی "خالص فروش") بصورت یک فیلد محاسباتی هست. یعنی به جای اینکه توی گزارش گیری بیام این دو مورد رو محاسبه کنم (با فرمول مشخص) این دو مورد رو بعنوان فیلدهای محاسباتی در زمان درج هر رکورد (ثبت هر فروش) حساب کنم(با همون فرمول مشخص) و حالا ازشون در گزارش گیری استفاده کنم.
هر دو روش از یک فرمول مشخص برای محاسبه "کل فروش" و "خالص فروش" استفاده میکنن. تنها تفاوت اینه که فیلد محاسباتی همون لحظه که فروش ثبت میشه همون لحظه به ازای اون تک رکورد این مقادیر رو محاسبه و ثبت میکنه ولی روش دوم میاد داخل گزارش گیری به ازای تمامی فروش ها این مقادیر رو محاسبه میکنه. فیلد محاسباتی یه جورایی لحاظ نکردن صفت مشتق در جدول رو نقض میکنه ولی قطعا کاربردهای خاص خودش رو داره که این ویژگی در SQL وجود داره.
من فکر میکنم سرعت گزارش گیری در حالتیکه فیلد محاسباتی داشته باشیم بیشتر باشه(چون محاسبات از قبل انجام شدن) ولی از اون ور هم ما دو فیلد اضافی ( و البته شاید مفید) به جدول اضافه کردیم که فضا اشغال میکنن.
با این توضیحات نظر دوستان چیه؟
خوشحال میشم همه اساتید در بحث ها شرکت کنن. به خدا این مفاهیم به درد خیلی ها میخورن که توی هیچ کتابی نمیشه پیداشون کرد. من میتونم بصورت پیام خصوصی از اساتید سایت سوالام رو بپرسم ولی عمومی مطرح میکنم که همه بچه ها استفاده کنن.
تشکر از همه دوستان که زحمت میکشن و نظر کارشناسی میدن.

[SabaSabouhi]

ممنون دوست عزیز.
من خوب توضیح ندادم. منظورم محاسبه سود بازاریاب یا محاسبه درصد تخفیف بصورت فیلد محاسباتی نیست. این موارد (نوع تخفیف، میزان تخفیف، سود بازاریاب) توسط کاربر مشخص و در دیتابیس ثبت میشن (به قول شما ممکنه مشتری بخواد بخاطر سود زیاد یک فروش یا ... درصد سود بیشتری رو برای یک بازاریاب و برای یک فروش خاص در نظر بگیره). منظور من محاسبه دو مفهوم "کل فروش" و "خالص فروش" (مخصوصا این دومی یعنی "خالص فروش") بصورت یک فیلد محاسباتی هست. یعنی به جای اینکه توی گزارش گیری بیام این دو مورد رو محاسبه کنم (با فرمول مشخص) این دو مورد رو بعنوان فیلدهای محاسباتی در زمان درج هر رکورد (ثبت هر فروش) حساب کنم(با همون فرمول مشخص) و حالا ازشون در گزارش گیری استفاده کنم.
هر دو روش از یک فرمول مشخص برای محاسبه "کل فروش" و "خالص فروش" استفاده میکنن. تنها تفاوت اینه که فیلد محاسباتی همون لحظه که فروش ثبت میشه همون لحظه به ازای اون تک رکورد این مقادیر رو محاسبه و ثبت میکنه ولی روش دوم میاد داخل گزارش گیری به ازای تمامی فروش ها این مقادیر رو محاسبه میکنه. فیلد محاسباتی یه جورایی لحاظ نکردن صفت مشتق در جدول رو نقض میکنه ولی قطعا کاربردهای خاص خودش رو داره که این ویژگی در SQL وجود داره.
من فکر میکنم سرعت گزارش گیری در حالتیکه فیلد محاسباتی داشته باشیم بیشتر باشه(چون محاسبات از قبل انجام شدن) ولی از اون ور هم ما دو فیلد اضافی ( و البته شاید مفید) به جدول اضافه کردیم که فضا اشغال میکنن.
با این توضیحات نظر دوستان چیه؟
خوشحال میشم همه اساتید در بحث ها شرکت کنن. به خدا این مفاهیم به درد خیلی ها میخورن که توی هیچ کتابی نمیشه پیداشون کرد. من میتونم بصورت پیام خصوصی از اساتید سایت سوالام رو بپرسم ولی عمومی مطرح میکنم که همه بچه ها استفاده کنن.
تشکر از همه دوستان که زحمت میکشن و نظر کارشناسی میدن.

سلام
پیش از هر چیز یادآوری کنم که «استاد» واژه فارسی هست و مانند واژگان تازی شکسته جمع بسته نمی‌شه. بجای اساتید، از استادان استفاده کنید.

و اما در مورد پرسش شما،
نگران چند بایت اضافی برای هر سطر نباشید. این نگرانی‌ها مربوط به زمان جوانی امثال من بود که حافظه‌های جانبی در حد مگابایت بود. مثلاً یک MainFrame
در دانش‌گاه ما وجود داشت که کل حافظه‌ی اصلی‌اش 128 کیلو بایت و حافظه‌ی جانبی اون 5 مگابایت بود.
در حال حاضر حجم مصرفی نسبت به سرعت اهمیت بسیار کمتری داره. شما با قرار دادن فیلد محاسباتی در جدول، اون رو از حالت نرمال خارج می‌کنی که
به این کار denormal کردن هم می‌گن و تو طراحی دیتابیس خودش یه مرحله از کار هست. یعنی شما فیلد یا فیلدهایی رو به دیتابیس اضافه می‌کنی که
سرعت رو ( به ویژه برای گزارش‌ها ) بالا ببری.

صبا صبوحی

[golbafan]

من معمولا اینجور مواقع از view ها استفاده میکنم.
برای مثال:
یک جدول دارم که مربوط به فاکتور هست و این فاکتور شامل یک فیلدی به نام نوع فروش هست
یک جدول هم دارم برای تعریف انواع فروش

حالا مثلا فلان جنس رو با حالت فروش x میخوام بفروشم که قیمت اون جنس مثلا 1000 تومان هست
در حالت فروش x تعریف کردم که تخفیف 5% قیمت هست و پورسانت 10% قیمت

بنابر این میام از ادغام این جداول و محاسبه مبلغ نهایی بر اساس مبلغ کالا و نوع فروش view مورد نظر رو طراحی میکنم.

مثال:

جدول کالا


id کالا
سایر مشخصات
قیمت


1
نام کالا و ...
1000



جدول فاکتور


id فاکتور
تاریخ
سایر مشخصات


1
1394
خریدار و ...



نوع فروش:


id
تخفیف
پورسانت
سایر


1
%5
10%
...




جدولی هم بشکل زیر دارم برای ثبت اقلام فاکتور


id کالا
id نوع فروش
id فاکتور

تعداد

سایر



1
1
1
2

...

[tst835]

من معمولا اینجور مواقع از view ها استفاده میکنم.
برای مثال:
یک جدول دارم که مربوط به فاکتور هست و این فاکتور شامل یک فیلدی به نام نوع فروش هست
یک جدول هم دارم برای تعریف انواع فروش

حالا مثلا فلان جنس رو با حالت فروش x میخوام بفروشم که قیمت اون جنس مثلا 1000 تومان هست
در حالت فروش x تعریف کردم که تخفیف 5% قیمت هست و پورسانت 10% قیمت

بنابر این میام از ادغام این جداول و محاسبه مبلغ نهایی بر اساس مبلغ کالا و نوع فروش view مورد نظر رو طراحی میکنم.

مثال:

جدول کالا


id کالا
سایر مشخصات
قیمت


1
نام کالا و ...
1000



جدول فاکتور


id فاکتور
تاریخ
سایر مشخصات


1
1394
خریدار و ...



نوع فروش:


id
تخفیف
پورسانت
سایر


1
%5
10%
...




جدولی هم بشکل زیر دارم برای ثبت اقلام فاکتور


id کالا
id نوع فروش
id فاکتور
تعداد
سایر


1
1
1
2
...



تشکر بابت حضورتون در بحث.
یه سوال آیا باز هم کاهش سرعت رو در حالتیکه از view استفاده کنیم نسبت به فیلدهای محاسباتی نداریم؟ (به نظر میرسه همچنان این مشکل سرعت در رکوردهای زیاد وجود داشته باشه و فقط به جای قرار دادن فرمول درون گزارش، عملیات محاسبه درون view انجام و نتیجه برگشت داده میشه).
سوال بعدی اینکه : آیا فیلدهای محاسباتی رو فقط میشه روی ستون های همون جدول اعمال کرد؟ یا میشه بین جداولی که با هم در ارتباطند (از طریق کلید خارجی) هم از ستون محاسباتی استفاده کرد؟ (مثلا ضرب یک ستون از جدول1 در یک ستون از جدول2) . آیا چنین چیزی امکان داره؟

[nazanin_asadi_1]

با سلام
منم همچین مشکلی رو دارم (البته یه جوره دیگه ) در حال حاضر هر موقع که میخوام آمار رو به دست بیارم از محاسبه استفاده میکنم

من این مشکل رو دوجا دارم یکی توی گردش حساب مشتریها یکی هم توی محاسبه مقدار سود خالص و ناخالص هر روز و هر هفته و هر ماه

من فیلد محاسباتی واسه سود و گردش حسابها ایجاد نکردم ولی الان که میخوام لیست رو ببینم یه بازه زمانی (به صورت سعودی) طول میکشه تا لیست به دست بیاد با این حساب اگه تعداد گردش حساب ها و یا تعداد فروش کالا بیشتر بشه برای محاسبه جمع گردش حساب و یا محاسبه سود خالص و ناخالص به مشکل میخورم
یا باید منم سعودی سرورهامو آبدیت کنم از هاست به سرور مجازی از سرور مجازی به سرور و ...
یا روش دیگه ای پیاده سازی کنم

بحث خوبی هستش امیدوارم دوستان دیگه ای هم شرکت کنند تا نظرهای اونها رو هم بدونیم

[golbafan]

تشکر بابت حضورتون در بحث.
یه سوال آیا باز هم کاهش سرعت رو در حالتیکه از view استفاده کنیم نسبت به فیلدهای محاسباتی نداریم؟ (به نظر میرسه همچنان این مشکل سرعت در رکوردهای زیاد وجود داشته باشه و فقط به جای قرار دادن فرمول درون گزارش، عملیات محاسبه درون view انجام و نتیجه برگشت داده میشه).
سوال بعدی اینکه : آیا فیلدهای محاسباتی رو فقط میشه روی ستون های همون جدول اعمال کرد؟ یا میشه بین جداولی که با هم در ارتباطند (از طریق کلید خارجی) هم از ستون محاسباتی استفاده کرد؟ (مثلا ضرب یک ستون از جدول1 در یک ستون از جدول2) . آیا چنین چیزی امکان داره؟

بهینه ترین روش برای دیتابیس های رابطه ای، استفاده از view هست
برای کم نشدن سرعت هم باید از ایندکس گذاری مناسب استفاده کنید

فیلد محاسبه گر که شما میفرمایید بسیار بسیار کند تر از view عمل میکنه!

[tst835]

فیلد محاسبه گر که شما میفرمایید بسیار بسیار کند تر از view عمل میکنه!
دوست عزیز چطور چنین چیزی امکان پذیره؟
شما کوئری رو در هر دو حالت ازش Execution Plan بگیر تا تفاوت Cost این دو کوئری مشخص بشه.
محاسبه ای که از قبل انجام شده (فیلد محاسباتی) چطور با محاسبه ای که اون لحظه به ازای تک تک رکوردها انجام میشه دارای performance کمتر است؟

[golbafan]

دوست عزیز چطور چنین چیزی امکان پذیره؟
شما کوئری رو در هر دو حالت ازش Execution Plan بگیر تا تفاوت Cost این دو کوئری مشخص بشه.
محاسبه ای که از قبل انجام شده (فیلد محاسباتی) چطور با محاسبه ای که اون لحظه به ازای تک تک رکوردها انجام میشه دارای performance کمتر است؟

راست میگی ها !!!
من با محاسبه همزمان در نرم افزار اشتباه گرفتم

درسته اگر قبلا محاسبه و ثبت در دیتا شده که دیگه سرعتش بالاست.
میتونی از تریگر برای انجام محاسبات هر رکورد استفاده کنی
هم از داخل خود جدول و هم سایر جداول میتونی فراخونی کنی و نیازی نیست که حتما foregen هم باشن

مثال:

new.totalcost = (select cost from goods where new.goodid=goods.id)*new.goodcount;


همونطور که میدونی new در تریگر نشون دهنده همون رکوردی هست که داره ویرایش میشه یا شده