اضافه کردن صفت مشتق به جدول

[veniz2008]

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

[hamidkh]

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

[m0hammad_01]

سلام
چیزی که تو کتابها نوشته:
-اگر سرعت برای شما مهم است، صفت مشتق را ذخیری کن.
-اگر حجم برای شما مهم است، صفت مشتق را ذخیره نکن.

خیلی راحت میتونی با این قانون تصمیم بگیری.مواردی مثل موردی که مثال زدین(گزارش گیری راحت میشه،...) و اینکه احتمال زیاد چنان حجم زیادی رو اضافه نخواهد کرد، ذخیره کردن صفت مشتق، سودش بیشتر از ذخیره نکردن هست.

[Arash_janusV3]

در نظر گرفتن فیلد برای مانده ها کاملا کار اشتباهی ست
حالا جدا از این که اصولی نیست
روش بسیار قدیمی و چه بسا باعث مشکلاتی هم می شود
مثلا باید همش عمل بروز رسانی رو انجام بدید
فیلدهای مانده ها و محاسباتی رو باید در View یا Stored یا کدنویسی درون محیط برنامه نویسی انجام داد
و بهتر از View استفاده کنید البته برای این مثالی که گفتید
شما در View جدول اقساط رو Group By کنید و روی مبلغ پرداختی عمل Sum رو انجام دهید و سپس آن را از کل شهریه کم کنید و مانده به دست می آید
فراموش نشود که شما باید در جدول اقساط ID رو ذخیره کنید که به جدول شهریه مرتبط است

برای مثال

SELECT SUM(TableAghsat.Pay) AS SUM, SUM(TableAghsat.Pay) - TableShahrie.Col AS Reminder
FROM TableAghsat RIGHT OUTER JOIN
TableShahrie ON TableAghsat.ID = TableShahrie.ID
GROUP BY TableShahrie.Col

[baktash.n81@gmail.com]

ببینید ممکنه در شرایط مختلف یک روش منطقی باشه یه روش دیگه غیر منطقی به نظر بیاد ...

در جواب این دوستمون که می گه نگهداری مانده ها کار اشتباهی است ... یه مثال می زنم شما در بانکی حساب دارید که ممکن است در اثر برخی اعمال کم یا زیاد بشود مثالا وقتی پول به حسابتون ریخته میشه مقدار افزایش پیدا می کنه و قتی پول بر می دارید مقدار حسابتون کم می شه ... به نظرت هر دفعه که مانده حساب می گیرید سیستم از روز اول که شما حساب باز کردید باید جمع و تفریق انجام بدهد و حاصل موجودی شما باشد یا فقط یه فیلد به عنوان مانده حساب وجود دارد ؟!؟

اینکه استادتون همچین حرفی زده ... بر اساس اصول معماری بانکهای اطلاعاتی مربوط به 30 سال پیشه ... حتی الان در بعضی موارد نرمالسازی زیر سئوال می ره ... چه برسی به فیلد مشتق شده ...

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

البته وقتی شما مانده رو نگهداری کنید کار پیاده سازی سیستم واقعا سخت می شه ... که شما در تمام موارد Update Delete Insert و ... باید حواستون به مانده باشه ... ولی نتیجه سیستم شما یه سیستم قابل اطمینانه که روند کند شدن اون چه در گزارش گیری و چه در کار با سیستم با زیاد شدن تعداد رکوردها از شیب کمتری برخورداره ...

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

[مهدی هادیان2]

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

با سلام
چرا با تغییر قسط مانده اشتباه میشه؟
این حرفتون رو که فرمودید "در کار با سیستم با تعداد شدن تعداد رکوردها از شیب کمتری برخورداره ..." کاملا قبول دارم ولی فکر میکنم ضریب اطمینان پایین بیاد
با تشکر

[baktash.n81@gmail.com]

خوب بیشتر توضیح می دم ... من 1000 تومن باید قسط بدم ... 3 تا قسط 200 تومنی پرداخت می کنم ... حالا به دلیل مبلغ یکی از قسط ها تغییر پیدا می کنه میشه 100 تومن ... بعد شما می خوای حسابتونو چک کنی ... توی حسابت 100 تومن پول اضافه داری ... چه جوری می خوای بفهمی این اشتباه از کجاست فرض کن 1000 نفر دیگه هم دارن قسط می دن ...

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

[veniz2008]

در مورد سیستم فوق فرض کنید که ما مانده رو نگهداری نمی کنیم و هر دفعه میایم اونو حساب می کنیم حالا اگه یکی از مقادیر در قسط های قبل تغییر پیدا کنه شما مانده اشتباه رو دریافت می کنید و از اونجا به بعد تراز کل سیستم بهم می ریزی و به راحتی نمی تونید بفهمید مشکل از کجاست ... ولی وقتی مانده رو نگهداری کنید می تونید بفهمید که کجا اشتباه شده

البته وقتی شما مانده رو نگهداری کنید کار پیاده سازی سیستم واقعا سخت می شه ... که شما در تمام موارد Update Delete Insert و ... باید حواستون به مانده باشه ... ولی نتیجه سیستم شما یه سیستم قابل اطمینانه که روند کند شدن اون چه در گزارش گیری و چه در کار با سیستم با زیاد شدن تعداد رکوردها از شیب کمتری برخورداره ...

ضمن تشکر از پاسخ تمامی دوستان. دوست عزیز خیلی با این دو مورد آخر موافق نیستم. مثال خودتون رو تکرار میکنم. مثلا کاربر هر قسط باید 1000 تومان پرداخت کنه و کلا 4 قسط داره. دو قسط 1000 تومانی و یک قسط 100 تومانی پرداخت میکنه. واسه من مهم نیست که مبلغ قسط رو چقدر پرداخت کرده مهم اینه که مجموع قسط های پرداخت شده رو از هزینه کل کم کنم و مقدار بدهیش رو مشخص کنم.حالا مجبوره که قسط آخر رو 1900 تومان پرداخت کنه (چون تعداد اقساط در برنامه من مشخصه). مثل کاری که الان بانک ها انجام میدن. شما وقتی میخوای قسط پرداخت کنی میگه هرچی دوس داری پرداخت کن این نیست که دقیقا باید همون مقدار پرداخت بشه.(اگر کم بریزه مشمول دیرکرد میشه). با این قسمت موافقم که اگر مانده رو نگهداری کنم کار مشکل تر میشه و باید همواره با هر تغییری مقدار رو آپدیت کنم. در مورد قابل اطمینان بودن نتیجه سیستم به نظر من اگر مانده رو نگهداری نکنم به مراتب اطمینان از نتیجه خروجی بالاتر هست( فرض کنید به هر دلیلی مثل فراموشی یا نقص در زمان ویرایش اطلاعات نتونم اطلاعات رو بروز کنم). اونوقت چطور میتونم بگم که این روند اطمینان بالاتری داره؟.
نتیجه ای که تا اینجا گرفتم به نظرم جواب Arash_janusV3 (http://barnamenevis.org/member.php?118123-Arash_janusV3) به صواب نزدیکتره. اگر به نظرتون اشتباه میاد مثال نقض بیارید.

[FastCode]

از نظر من ذخیره کردن بدهی ۱۰۰٪ اشتباهه به دلایل زیر:
۱.اگر اطلاعات قبلی ویرایش بشن باید همه بدهی ها از اول محاسبه و ذخیره بشه
مثال:تغییر قیمت کالا->تغییر بدهی معوق همه مشتریان دارای سفارش
۲.تغییر دستی دیتا
مثال:واقعاً مثال نمیخواد
۳.نوشتن حجم بسیار زیادی کد برای انجام گزینه ۱
۴.عدم اعتماد:آخرش هم همه شک دارن

[Arash_janusV3]

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

[baktash.n81@gmail.com]

ببین این دوستان که می گن که می گن نگهداری مانده کلا کاره اشتباهی هست ... معلومه دانششون در چه حدیه ... فقط می شه به من بگن بانک ها برای نگهداری مانده حساب چی کار می کنن ؟!؟ هر دفعه که شما مانده می گیری از روز اول همه رو حساب می کنه ؟!!؟ وقتی یه نفر اینجوری حرف می زنه معلومه که داره از روی احساسات با تعصب بیجا و به صورت غیر منطقی حرف می زنه ... حداقل نمی گه در 99 درصد موارد ... واقعا از این همه اعتماد به نفس آدم شکه می شه ...

شما هم اگه پست 7 رو با دقت بخونی متوجه می شی که منظورم از قسط 100 تومنی این بود که مقدارش تغییر پیدا کنه یعنی من 200 تومن پرداخت کردم بعد یه نفر می ره تو سیستم 200 تومن رو می کنه 100 تومن ... و بقیه ماجرا ...

به هر حال سیستم رو شما طراحی می کنی ... هر جور هم فکر می کنی درسته تره این کارو انجام بده ... اسراری نیست ...

[حمیدرضاصادقیان]

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


اگر کاربری بیاد یک سند رو در وسط کار اصلاح کنه و مقداری رو تغییر بده شما مجبورید کل مانده رو مجددا تغییر بدید که همین Update روی سیستم شما با حجم بالا دچار دردسر خواهد شد.
وقتی که دارید مقداری رو در وسط یک سند درج میکنید که مثلا یادتون رفته باز باید کل مقادیر رو Update کنید.
وقتی یک ردیف از مابین اسناد حذف کنید باز مانده ها تغییر میکنه و مجبور می شوید کل جدول رو Update کنید.
فرض کنید جدول شما شامل 10 میلیون سند باشه و 30 کاربر آنلاین دارند کار میکنند و داده ها دائما داره تغییر میکنه.فکر کنم بتونید به راحتی میزان Modification روی جدول و باری که روی سرور ایجاد میشه رو حدس بزنید!! اینجاست که زنگهای سیستم پشتیبانی شما به صدا درمیاد.
در بعضی از گزارشات نیازی به نمایش مانده نیست. مانند چاپ اسناد حسابداری، مانند گزارش لیست مشتریان ، فروش مشتریان و ...
با اضافه کردن یک فیلد به جدول ، باعث افزایش ذخیره جدول مورد نظر روی Page های بیشتری شده که همین امر باعث افزایش I/O روی هارد شده و در نهایت کندی سیستم رو به همراه خواهد داشت.
فرض کنید در سیستمهای شناور حساب تفصیلی به صورت شناور تعریف شده و یک حساب در چند معین مختلف داره کار میکنه و هرکدوم نیاز به نگهداری مانده شخصی همون حساب هستند. حالا شما کدوم مانده رو میخواهید برای همون یک تفصیلی نگهداری کنید.؟

حالا در مورد فیلدهای محاسباتی با فرمول:


هنگام واکشی جدول هردفعه این فیلد محاسبه میشه در صورتی که ممکنه نیازی بهش نباشه.
سربار زیادی به سیستم تحمیل میکنه.
درمورد ذخیره بیشتر روی Page و بحث I/O به مطالب بالا مراجعه کنید.

ولی شما میتوانید برای نمایش مانده به راحتی یک View نوشته و درجایی که نیاز دارید فقط اونو صدا بزنید و نیازی به اینهمه کدنویسی و درگیری برای بحث Update,Insert,Delete روی جدول متحمل نخواهید شد.

[baktash.n81@gmail.com]

شما با اینهمه تجربه باید اینو بدونید که نگهداری فیلد محاسباتی باعث بهتر شدن پرفورمنس می شه ... و از نظر پرفورمنس اصلا نمی تونید این دوتا رو مقایسه کنید ...
فقط در خصوص Integration دیتابیس می تونید این روش رو زیر سئوال ببرید که اونم اگه برنامه شما DAL داشته باشه یا حتی برای درج و حذف و به روز رسانی SP بنویسید به راحتی قابل پیاده سازی ... اما اگه مستقیم از پشت هر کلید تو برنامه یه Query می فرستین تو DataBase ... کلا این قضیه رو بیخیال بشید ...

من پیشنهاد می کنم به جای اینکه اینهمه دلیل و منطق بیارید که اینکه شما می گین درسته ... یه مقدار ذهنتون رو برای پذیرش مفاهیم جدید اماده کنید ... بله تا 10 سال پیش همه در مورد Normal کردن دیتابیس ها حرف می زدن ... اما الان می گن بعد از اینکه جداول رو نرمالسازی کردین دینرمالایزش کنین برای اینکه سرعت بهتری داشته باشید و این دینرمالایز شامل مواردی می شه که یکی از این موارد همین نگهداری مانده ها یا فیلد های محاسباتی است ... در خصوص Denormalaize یکم جستجو کنید ...

[FastCode]

شما با اینهمه تجربه باید اینو بدونید که نگهداری فیلد محاسباتی باعث بهتر شدن پرفورمنس می شه ... و از نظر پرفورمنس اصلا نمی تونید این دوتا رو مقایسه کنید ...
فقط در خصوص Integration دیتابیس می تونید این روش رو زیر سئوال ببرید که اونم اگه برنامه شما DAL داشته باشه یا حتی برای درج و حذف و به روز رسانی SP بنویسید به راحتی قابل پیاده سازی ... اما اگه مستقیم از پشت هر کلید تو برنامه یه Query می فرستین تو DataBase ... کلا این قضیه رو بیخیال بشید ...

من پیشنهاد می کنم به جای اینکه اینهمه دلیل و منطق بیارید که اینکه شما می گین درسته ... یه مقدار ذهنتون رو برای پذیرش مفاهیم جدید اماده کنید ... بله تا 10 سال پیش همه در مورد Normal کردن دیتابیس ها حرف می زدن ... اما الان می گن بعد از اینکه جداول رو نرمالسازی کردین دینرمالایزش کنین برای اینکه سرعت بهتری داشته باشید و این دینرمالایز شامل مواردی می شه که یکی از این موارد همین نگهداری مانده ها یا فیلد های محاسباتی است ... در خصوص Denormalaize یکم جستجو کنید ...

آخرین بار من یکی از برنامه های خودم رو با یک برنامه که تا حالا چند میلیارد تومان فروش داشته در حضور برنامه نویسهاش benchmark کردم با نسبت یک به دوازده outperform شدن,چون کد مدیریت این روش خیلی سنگینتره
پ.ن.من .NetSqlProvider استفاده کرده بودم اونها OLEDB ولی فکر نمیکنم توضیح کافی ای برای ۱ به دوازده باشه
EDIT
یادم رفت بنویسم
دیتابیس اونها در مدت زمان کمتر تقریباً ۷۰ برابر من حجم داشت(هفتصد مگ ناقابل)(باور کنید راست میگم)
بعد به اونها میگن Enterprise به من میگن Small business

[حمیدرضاصادقیان]

شما با اینهمه تجربه باید اینو بدونید که نگهداری فیلد محاسباتی باعث بهتر شدن پرفورمنس می شهمن شخصا این صحبت شما رو قبول ندارم. هیچ الگوی خاصی وجود نداره که بفرمائید نگهداری فیلدی که دائم محتوای اون دستخوش تغییرات هست باعث افزایش Performance میشه.
پیشنهاد میکنم به کتاب Inside T-sql Querying 2008 فصل 4 مراجعه کنید و یک مطالعه داشته باشید.

اما الان می گن بعد از اینکه جداول رو نرمالسازی کردین دینرمالایزش کنین برای اینکه سرعت بهتری داشته باشید و این دینرمالایز شامل مواردی می شه که یکی از این موارد همین نگهداری مانده ها یا فیلد های محاسباتی استبامباحث Denormalization کاملا آشنایی دارم و هیچ وقت برای بهینه شدن سرعت حتما نمیان جداول رو Denormalization کنند. یکی از دلایل اینکار برای گرفتن گزارشاتی هست که نیاز به محاسبات پیچیده داره که حرف شما اینجا منطقیه که مثلا بیان در یک جدول ثانی مقدار فیلد محاسباتی رو نگهداری کنند.البته اونهم برای گزارشگیری.وگرنه در جداول اصلی اینکارو نمیکنند.
اگر دلیلی برای اینکار دارید برای مثال نقضی که در مورد مشتریان زدم راه حلی ارائه بدید.
اگر کامل با مباحث Tuning آشنایی داشتید هیچوقت نمیگفتید که الان میان از حالت نرمال خارج میکنند تا سرعت بهتری داشته باشند.
درمورد Page ها در تالار T-SQL مطالبی نوشتم که بد نیست نگاهی بهش بندازید. اگر شما باید کامل با ساختار data page ها آشنایی داشته باشید و بدونید به چه شکلی کار میکنه بهتر میتونید در این باره تصمیم گیری کنید.یکی از اصول Tuning این هست که شما تعداد فیلدهای اضافی جدول رو کاهش بدید یا به جداول دیگه تقسیم بندی کنید که میزان I/O کمتری صرف بشه.
در مورد انواع Wait ها نیز در همون تالار توضیح دادم که با یک تحقیقات ساده و گرفتن نتیجه از dm_os_wait_status میتونید تصمیم گیری دقیقتری کنید.
برای نمونه شخصا روی دیتابیس یک بیمارستان کار کردم که 30 گیگابایت حجم دیتابیس بود و 200 نفر Online کار میکردن که در بعضی موارد کند بود.با کاهش فیلدهای بعضی از جداول و ایجاد ایندکس های مناسب و بازنویسی بعضی از دستورات مشکل حل شد.در صورتی که فیلدهای محاسباتی نیز زیاد داشتند.

[baktash.n81@gmail.com]

سایت آموزون رو فرض کنید شما می رید چند کتاب رو به سبد خرید اضافه می کنید ... به نظر شما هر دفعه که یه نفر می خواد لیست خریدشو نگاه کنه ... میره رکورد های سبد شما رو با جدول کتابها Join می کنه که قیمت ها رو به دست بیاره بعد قیمت ها رو با هم جمع می کنه ... ؟!؟! فکر نمی کنید اینجوری یکم با زیاد شدن تعداد کتابها و مشتریها سرعت سایت بیآد پایین ... و سرور Down بشه !؟

از اینکه بگذریم برگردیم سر سئوال اول این تاپیک که باز پرداخت وام بود ... به نظر شما مقادیر پرداختی وامها بیشتر Update می شه یا بیشتر مشاهده می شه !؟! فرض کنید 10000 تا دانشجو موقع انتخاب واحد می آن و میخوان وضعیت مالیشون رو چک کنن ! چه اتفاقی می افته ... اتفاقی که الان معمولا می افته به خاطر پیاده سازی روش پیشنهادی شما سرور دان می شه یا سرعتش میآد پایین ... اما زیاد مهم نیست ... برای اینکه هنوزم تو دانشگاه همینو درس می دن ... امثال ماهم روی روشهامون پا فشاری می کنیم ...

من یه مثال در مورد مانده حساب بانکها زدم شما جوابی براش دارید ؟!

[حمیدرضاصادقیان]

بسیار خوب.
بریم سر مطلب اول سایت آمازون که فرمودید.

شما می رید چند کتاب رو به سبد خرید اضافه می کنید

در مورد قیمت کتابها خیر ، زیرا یک فیلد برای قیمت کتابها در همون جدول دارند که همونو جمع میکنند و نیازی به Join با جدول کتابها نیست.
این بحثش با مانده که یک روش محاسباتی هست کاملا تفاوت میکنه.قیمت یک کالا ثابته مگر اینکه دستخوش تغییرات بشه که با یک Update ساده یا Trigger اینکار صورت میگیره تازه فقط در جدول انبار عوض میشه زیرا ممکنه کالا الان به یک قیمت فروخته بشه فردا به یک قیمت دیگه و نیازی به تغییر قیمتها نیست.

من خودم برای فاکتورهای فروش در ریز کالا قیمت کالا رو نگهداری میکنم ، چون هرکالایی قیمت خاص خودش رو داره و برای گزارشاتی مثل کاردکس شما به قیمتهای مختلف فروش یک کالا نیاز دارید.


به نظر شما مقادیر پرداختی وامها بیشتر Update می شه یا بیشتر مشاهده می شه !
درمورد مقادیر وامها ببینید شما یک جدول دارید که ID وام گیرنده و کد وام هست و مبلغ پرداختی.البته باز اینجا هم میتونه برای راحتی کار مانده وام هم باشه.زیرا ممکن نیست مبلغ وام تغییر پیدا کنه همیشه یک مبلغ ثابتی هست.


فرض کنید 10000 تا دانشجو موقع انتخاب واحد می آن و میخوان وضعیت مالیشون رو چک کنن
خوب حالا در این مورد ، اولین اشکال اینجا ظاهر میشه که اسم دانشجو به صورت شناور باشه. و در چند جا مانند وامها ، شهریه ، اسم این دانشجو باشه. شما مانده این دانشجو رو کجا نگهداری میکنید؟
ایا میاید برای هر حساب معین مانند وام یک جدول ایجاد میکنید که اسم دانشجو باشه بعد یک فیلد مانده داشته باشه؟
یک دانشجو مگر چندتا تراکنش داره که سیستم بخواد کند بشه یا Down بشه.
نهایتا برای شهریه بیش از 7-8 رکورد که نمیخواد گزارش گیری بکنه. پس کل رکوردهای دانشجو میشه نهایتا 10 رکورد.پس مانده گیری از اون هیچ زمانی نمیگیره و در کسری از ثانیه باید انجام بشه.
اگر سیستمهای دانشگاه ما الان مشکل دارند به خاطر مسائل دیگه مانند عدم رعایت Index گذاری مناسب یا استفاده از دستورات بهینه تر ممکنه باشه.


من یه مثال در مورد مانده حساب بانکها زدم شما جوابی براش دارید ؟!
خوب حالا بریم سر این مثال. شما ابتدای کار بفرمائید مثلا آقای x در بانک 4 تا حساب جاری داره ، 3 تا قرض الحسنه ، 2تا پس انداز و 3تا کوتاه مدت.
شما اینارو چطوری تعریف میکنید.؟
من نیازی ندارم مانده همه حسابهامو جمع کنه یک جا بهم بده.؟
من میخوام مانده تک تک حسابهامو داشته باشم.
اینو برای من شرح بدید.

باتشکر از اینکه در بحث شرکت میکنید.

[veniz2008]

بسیار خوب.
بریم سر مطلب اول سایت آمازون که فرمودید.


در مورد قیمت کتابها خیر ، زیرا یک فیلد برای قیمت کتابها در همون جدول دارند که همونو جمع میکنند و نیازی به Join با جدول کتابها نیست.
این بحثش با مانده که یک روش محاسباتی هست کاملا تفاوت میکنه.قیمت یک کالا ثابته مگر اینکه دستخوش تغییرات بشه که با یک Update ساده یا Trigger اینکار صورت میگیره تازه فقط در جدول انبار عوض میشه زیرا ممکنه کالا الان به یک قیمت فروخته بشه فردا به یک قیمت دیگه و نیازی به تغییر قیمتها نیست.

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

[FastCode]

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

مگر شما کار دیگه ای میکنید؟
اگر بخواهید یک کالا رو با یک قیمت دیگه به کسی بفروشید چکار میکنید؟
در ضمن وقتی یک کالا فروخته شده پولش رو هم گرفتیم نوش جان کردیم دیگه نمیتونیم قیمتش رو در فاکتور تغییر بدیم ولی میتونیم در خود مشخصات کالا تغییر بدیم تا از این نقطه به بعد با قیمت جدید فروخته بشه
این مثال شما کلاً join نیاز نداره ولی باشه

این بهترین counter-sample ای بود که میتونستید بیارید که ثابت بشه نظریتون اشتباهه
امیدوارم اشتباه محاسباتی نداشته باشم:
Prod_Count: P
Sale_Count: S
S>P
With Join:
Reverse Lookup CPU Usage:P*log(S)//not used, just in case for reference
normal Lookup CPU Usage S *Log(P)
Sort Memory P*(Log(P)-2) // -2 is for specific optimizations microsoft and many others DBMSs do, not exactly -2, but will do
Complete lookup Cost:
Memory: (S) + (P) + (P*(Log(P)-2))--not too many bytes, steel many
CPU: S*Log(P)

No Join:
Complete lookup Cost:
Memory: S
CPU: S

[veniz2008]

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

[FastCode]

تو سیستم مکانیزه به نظر من اصلا کار درستی نیست که بخوایم برای یک کالای مشخص برای دو مشتری دو قیمت متفاوت داشته باشیم. میتونیم در جدول خرید یک فیلد با عنوان درصد تخفیف داشته باشیم و برای اشخاص عادی درصد تخفیف صفر باشه. من با جوابی که دادید قانع نشدم. من فرض رو بر 2 جدول گرفتم شما فرض کن جداول بیشتری داشته باشیم که اگه قرار باشه در همه این جداول مبلغ کالا رو هم ثبت کنیم با هر تغییر مبلغ در مبدا، باید تمامی جداول وابسته هم مقدارشون تغییر کنه که این کار امنیت برنامه و خروجی رو کم میکنه. در مورد کدها و فرمول هایی که نوشتید چیزی متوجه نشدم اگه ممکنه لطف کنید و کدها رو توضیح بدید.(اینکه اینا رو چطوری محاسبه کردید). ممنون.
برنامه ی اتوماسیون فروش از نظر استفاده کننده وقتی برنامه خوبیه که بتونه case های مختلف رو پشتیبانی کنه
الان من باید ثابت کنم که به ازای چه مقدار تغییر چقدر FPU در روش شما بی دلیل مشغول میشه و اگر یک int رو جدا ذخیره کنیم به نفعمونه (یادتون باشه که این int به معنی ذخیره داده پردازشی نیست,چون خودش مرجع محاسبست.)
CPU FLOP =
S*درصد تغییرات ه که از این به بعد با DS یعنی S*DS نشان میدیم
این مقدار به اعداد پست قبلی اضافه میشه


Prod_Count: P
Sale_Count: S
S>P
این ها فرض مسئلست که تعداد ها رو داریم و میدونیم تعداد فروش ها از تعداد کالا ها بیشتره

With Join:
Reverse Lookup CPU Usage:P*log(S)//not used, just in case for reference
normal Lookup CPU Usage S *Log(P)
Sort Memory P*(Log(P)-2) // -2 is for specific optimizations microsoft and many others DBMSs do, not exactly -2, but will do
این ها هم هزینه lookup هستند که fact هستند
تعداد جست و جو های مورد نیاز ضرب در log ه اندازه dataset ه مورد جست و جو
در ضمن dataset باید sort شده باشه که یک P Log P هم اضافه میشه که عدد کمیه(تاثیر نداره)
در مورد memory به نفع شما حساب شده چون تقریباً هیچ کس -2 رو در نظر نمیگیره و همه تقلب حسابش میکنن,خب من نکردم

Complete lookup Cost:
Memory: (S) + (P) + (P*(Log(P)-2))--not too many bytes, steel many
CPU: S*Log(P)
این هم جمع اطلاعات ه حسابشده در بالا شامل کپی هر دو جدول به اضافه ی هزینه سورت(مموری)
و هزینه جست و جو(CPU)

No Join:
Complete lookup Cost:
Memory: S
CPU: Sاین هم روش من که فقط شامل کپی جدول میشه

[baktash.n81@gmail.com]

در خصوص سبد خرید در واقع نه تنها از نظر پرفورمنس بهتره که من قیمت رو Fetch کنم و بیارم توی جدول سبد خریدم ... بلکه مجبورم اینکارو بکنم ... چون مشتری توی سایت یه کتاب رو با قیمت 20 دلار انتخاب کرده و هنوز خریدش تموم نشده مدیر سایت قیمت هارو Update می کنه ... میشه 22 دلار ... ؟! حالا مشتری باید کدومو پرداخت کنه ؟!

حالا تصور کنید سبد خرید من دوتا جدول مستر دیتیلی هست ... به نشر شما بهتر نیست ... مجوع قیمت هر فاکتور رو بیارم بزارم تو جدول مستر ... یعنی بدون اینکه نیاز باشه من برم سراغ جدول دیتیل و جمع و ضرب کنم مجموع قیمت ها رو تو جدول مستر داشته باشم ؟!؟

[baktash.n81@gmail.com]

در خصوص وام دانجشجویان هم ما یه جدول داریم برای وامهای پرداختی و مبلغ اونها و سایر اطلاعات ما می تونیم مانده وام رو هم تو این جدول نگهداری کنیم ... برای اینکه وقتی می خوایم مثلا میزان بدهی یه دانشجو رو حساب کنیم نریم درگیر جدول های زیرین وام بشیم ... ؟!!

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

[FastCode]

در خصوص سبد خرید در واقع نه تنها از نظر پرفورمنس بهتره که من قیمت رو Fetch کنم و بیارم توی جدول سبد خریدم ... بلکه مجبورم اینکارو بکنم ... چون مشتری توی سایت یه کتاب رو با قیمت 20 دلار انتخاب کرده و هنوز خریدش تموم نشده مدیر سایت قیمت هارو Update می کنه ... میشه 22 دلار ... ؟! حالا مشتری باید کدومو پرداخت کنه ؟!

حالا تصور کنید سبد خرید من دوتا جدول مستر دیتیلی هست ... به نشر شما بهتر نیست ... مجوع قیمت هر فاکتور رو بیارم بزارم تو جدول مستر ... یعنی بدون اینکه نیاز باشه من برم سراغ جدول دیتیل و جمع و ضرب کنم مجموع قیمت ها رو تو جدول مستر داشته باشم ؟!؟
دارین موضوعات رو قاطی میکنین
خب میتونید سفارشات رو در یک table ه جدا ذخیره کنید
و اگر در نظر بگیریم که runtime ه database ده سال باشه و هر خرید به طور متوسط ۲۴ ساعت طول بکشه داریم
تعداد سفارشات تایید نشده به کل اطلاعات =~ 1/1500 که نتیجه میدهد
اگر اطلاعات سفارش رو در یک table ه جدا دخیره کنیم و قیمت رو با join به دست بیاریم تاثیری در performance نخواهد داشت

به نشر شما بهتر نیست ... مجوع قیمت هر فاکتور رو بیارم بزارم تو جدول مسترخیر
دلائلش در بالا توضیح داده شده.به دو پست آقای صادقیان مراجعه کنید

EDIT

در خصوص سبد خرید در واقع نه تنها از نظر پرفورمنس بهتره که من قیمت رو Fetch کنم و بیارم توی جدول سبد خریدم
اینو ندیدم
یعنی محاسبات من کشک؟

[FastCode]

من الان خودم هم دارم گیج میشم.
شما این ساختار رو چطوری تعریف میکنید؟
Account:
ID
Name

Transaction:
ID
SourceAccountID
DestinationAccountID
Amount
Date

Loan:
ID
AccountID
Amount
PayDate
InterestRate:float
DueInterestRate:float
PaybackInterval

Cheque:
ID
AccountID
Amount
IssueDate
status:Cleared:Dishonoured:...

[baktash.n81@gmail.com]

شما اصلا می خونی چیزایی رو که من می نویسم ... ؟!؟! شما خودتم داری می گی فیلد قیمت رو میاری توی فاکتور ! منم می گم باید بیاریم به 2 دلیل چون پرفورمنس بهتر می شه ... و تغییر قیمت ... چون اون کاربر کتاب رو 20 دلار خرید نه 22 ...

در مورد اینکه جمع فاکتور رو بیارم توی جدول مستر ... !! مگه اطلاعات فاکتور تغییر می کنه ! به قول شما پولشم گرفتیم ... پس چرا هر وقت که به خوایم مبلغ یه فاکتور رو ببینیم بریم سراغ دیتیلش ... ! اینجوری هم IO کمتری داریم هم CPU کمتری مصرف می کنیم ... فقط موقعی که خرید قطعی شد یه فیلد رو Update می کنیم ...

خوب حداقل یه توضیح بده سیستم قراره چیکار کنه چی می خوای از سیستم ...

[FastCode]

فکر میکنم شما منظور من رو متوجه نشدی
اگر جمع رو ذخیره کنیم و فاکتور تغییر کنه درستی و صحت اطلاعات از بین میره
ولی اگر مبلغ رو ذخیره کنیم و تغییر کنه چیزی رو از دست ندادیم
چرا اینقدر حرف زدن با شما سخته؟

چرا میریم سراغ detail ؟
چون ۱۲ بار گفتیم مجبوریم
چون یه چیزی برامون مهمه یه اسم اطمینان از درستی محاسبات

[veniz2008]

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

[baktash.n81@gmail.com]

شما اصلا متوجه حرفهای من نشدی ...

شما فاکتور رو ثبت کردی ... پولش رفته توی حسابت ... ! اگه یکی از Detail ها تغییر کنه جمع کل فاکتور هم تغییر می کنه ... شما a تومن پول گرفتی ... اما الان جمع فاکتورت شده b ... مقدار a رو هم هیجا نگه نداشتی چون همیشه از روی Detail حسابش می کنی ... آخر ماه می خوای حساباتو جمع کنی از کجا می فهمی کدوم فاکتور مقدار دستکاری شده ؟!؟ حالا کدوم مدل اطمینانش بیشتره ؟!؟

شما یه فریم ورک درست نوشتی و اگه Detail ها از طریق برنامه تغییر کنه مدیریتشون می کنی که جمع رو هم Update کنن ... اگه به صورت غیر از برنامه هم تغییر پیدا کنه که حداقل می تونی بفهمی کجا مقدار حمع با مقدار ثبت شده نمی خونه ...

این دلیل واسه اطمیناننننننننننننننننننن نننن که انقدر مهمه براتون ... از نظر سرعت هم که این روش بهتره (به شرطی که میزان تغییرات کم باشه) ... اما تولید برنامه هایی که واقعا این تغییرات رو درست مدیریت کنن خیلی سخت و زمان بره ...

[baktash.n81@gmail.com]

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

کاربر وقتی رو جنسی کلیک کرد و اونو به سبد خرید اضافه کرد قیمتش 20 دلار بود ... سیستم هم این جنس رو با قیمت 20 دلار یه سبد خرید اضافه می کنه ... وقتی هم که خریدش کامل شد همون 20 دلار رو می پردازه ... چون ما کالا رو با قیمتش به جدول خرید اضافه کردیم ! حتی اگه بین افزودن کالا به سبد و ثیت فاکتور قیمت جنس به روز بشه برای مشتری فرقی نمی کنه ...

ولی اگه قرار بود قیمت کالا رو به سبد خرید اضافه نکنیم و هر دفعه اونو با جدول کالا Join کنیم ممکن این اتفاق که شما می گی بی افته ....

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

مثالا در مورد فاکتور ... ببین اون قدیما که تو دفتر می نوشتن ... چرا قیمت کالا رو هم ذکر می کردن مثالا 2 تا x فروختم هر کدوم 5 تومن .جمع 10 تومن ... می تونستن قیمت ها رو روی یه کاغذ دیگه بنویسن که هر دفعه مجبور نباشن قیمت رو توی صفحه بنویسن ...

در هر صورت من سعی خودمو کردم که شما حداقل در خصوص بعضی موارد فکر کنید ... امیدوارم نتیجه ای هم داشته باشه ... هر چند که بعید می دونم اصلا این مطالب رو بخونید

[FastCode]

شما اصلا متوجه حرفهای من نشدی ...

شما فاکتور رو ثبت کردی ... پولش رفته توی حسابت ... ! اگه یکی از Detail ها تغییر کنه جمع کل فاکتور هم تغییر می کنه ... شما a تومن پول گرفتی ... اما الان جمع فاکتورت شده b ... مقدار a رو هم هیجا نگه نداشتی چون همیشه از روی Detail حسابش می کنی ... آخر ماه می خوای حساباتو جمع کنی از کجا می فهمی کدوم فاکتور مقدار دستکاری شده ؟!؟ حالا کدوم مدل اطمینانش بیشتره ؟!؟

شما یه فریم ورک درست نوشتی و اگه Detail ها از طریق برنامه تغییر کنه مدیریتشون می کنی که جمع رو هم Update کنن ... اگه به صورت غیر از برنامه هم تغییر پیدا کنه که حداقل می تونی بفهمی کجا مقدار حمع با مقدار ثبت شده نمی خونه ...

این دلیل واسه اطمیناننننننننننننننننننن نننن که انقدر مهمه براتون ... از نظر سرعت هم که این روش بهتره (به شرطی که میزان تغییرات کم باشه) ... اما تولید برنامه هایی که واقعا این تغییرات رو درست مدیریت کنن خیلی سخت و زمان بره ...
دقیقاً همینطوره
باید اختلاف حساب داشته باشیم
چون فاکتور قطعی رو کاربر نباید تغییر بده

اگر کاربر قیمت کالا رو در جدول فاکتور تغییر بده و جمعش تغییر نکنه(خطای پیشبینی شده برنامه) در گزارش جمع کالاهای فروخته شده با جمع فاکتورهای فروخته شده اختلاف خواهیم داشت

اگر قیمت کالا رو در جدول فاکتور تغییر بده ولی جایی مبلغ کل فاکتور رو ذخیره نکرده باشیم اختلافی هم نخواهیم داشتن

اگر قیمت کالا رو در جدول کالا تغییر بدیم و در جدول فاکتور قیمت جداگانه داشته باشیم هیچ اختلافی نخواهیم داشت

اگر قیمت کالا رو در جدول کالا تغییر بدیم و در جدول فاکتور قیمت جداگانه نداشته باشیم همه ی فاکتور ها دچار اختلاف میشن

پس بهتره که یک جدول فاکتور با قیمت کالا داشته باشیم بدون جمع فاکتور و برای سفارشات هم یک جدول ه موقت تا بتونیم سفارشات رو تا زمانی که تایید نشدن بدون مبلغ درش نگهداری کنیم

EDIT:


شما یه فریم ورک درست نوشتی و اگه Detail ها از طریق برنامه تغییر کنه مدیریتشون می کنی که جمع رو هم Update کنن ... اگه به صورت غیر از برنامه هم تغییر پیدا کنه که حداقل می تونی بفهمی کجا مقدار حمع با مقدار ثبت شده نمی خونه ...

اینو ندیده بودم

یعنی برنامه هر بار که اجرا شد همه ی database رو scan کنه؟
خیلی خوبه
توی سیستم های بزرگ ممکن ه چند ساعت طول بکشه,مثل بانک
یعنی هر کلاینت مثلاً همه ی سود های همه ی مشتریان شعبه رو چک کنه که درست باشن
به جای اینکه هردفعه که مشتری حسابش رو poll میکنه براش محاسبات رو انجام بده
این یعنی فاجعه

در ضمن میدونستید روش شما در دیتابیس های توزیع شده شبیه اونی که توی امضای من ه اصلاً کار نمیکنه؟

[veniz2008]

کاربر وقتی رو جنسی کلیک کرد و اونو به سبد خرید اضافه کرد قیمتش 20 دلار بود ... سیستم هم این جنس رو با قیمت 20 دلار یه سبد خرید اضافه می کنه ... وقتی هم که خریدش کامل شد همون 20 دلار رو می پردازه ... چون ما کالا رو با قیمتش به جدول خرید اضافه کردیم ! حتی اگه بین افزودن کالا به سبد و ثیت فاکتور قیمت جنس به روز بشه برای مشتری فرقی نمی کنه ...

ولی اگه قرار بود قیمت کالا رو به سبد خرید اضافه نکنیم و هر دفعه اونو با جدول کالا Join کنیم ممکن این اتفاق که شما می گی بی افته ....

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

مثالا در مورد فاکتور ... ببین اون قدیما که تو دفتر می نوشتن ... چرا قیمت کالا رو هم ذکر می کردن مثالا 2 تا x فروختم هر کدوم 5 تومن .جمع 10 تومن ... می تونستن قیمت ها رو روی یه کاغذ دیگه بنویسن که هر دفعه مجبور نباشن قیمت رو توی صفحه بنویسن ...

در هر صورت من سعی خودمو کردم که شما حداقل در خصوص بعضی موارد فکر کنید ... امیدوارم نتیجه ای هم داشته باشه ... هر چند که بعید می دونم اصلا این مطالب رو بخونید
مطمئن باشید که میخونم. خوب مشکل من دقیقا همین جاست. فروشنده به هر دلیلی اشتباها 20 دلار ثبت کرده، مشتری میاد کالا رو با مبلغ 20 دلار انتخاب میکنه. قبل از اینکه مبلغ رو بپردازه ،فروشنده مبلغ صحیح رو یعنی 22 دلار رو برای کالا وارد میکنه. من حرفم اینه : چرا باید فروشنده که داره از نرم افزار استفاده میکنه 2 دلار ضرر کنه؟.من نمیگم حتما حرف من درسته،شاید این وسط یه ریزه کاری وجود داره که از چشم من به دور مونده.

[FastCode]

مطمئن باشید که میخونم. خوب مشکل من دقیقا همین جاست. فروشنده به هر دلیلی اشتباها 20 دلار ثبت کرده، مشتری میاد کالا رو با مبلغ 20 دلار انتخاب میکنه. قبل از اینکه مبلغ رو بپردازه ،فروشنده مبلغ صحیح رو یعنی 22 دلار رو برای کالا وارد میکنه. من حرفم اینه : چرا باید فروشنده که داره از نرم افزار استفاده میکنه 2 دلار ضرر کنه؟.من نمیگم حتما حرف من درسته،شاید این وسط یه ریزه کاری وجود داره که از چشم من به دور مونده.
این رو خوندید؟

پس بهتره که یک جدول فاکتور با قیمت کالا داشته باشیم بدون جمع فاکتور و برای سفارشات هم یک جدول ه موقت تا بتونیم سفارشات رو تا زمانی که تایید نشدن بدون مبلغ درش نگهداری کنیم

[veniz2008]

این رو خوندید؟
نه الان خوندمش. :خجالت:
من از حرف های شما اینطور برداشت کردم: قیمت نهایی که مشتری پرداخت میکنه از روی جدول کالا محاسبه میشه نه از روی قیمت موجود در جدول خرید(جدول فاکتور). درسته؟

[FastCode]

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

ببخشید نصفه دستم خورد روی ارسال
داشتم میگفتم
وقتی که سفارش قطعی میشه برنامه باید اطلاعات جدول بدون قیمت رو کپی کنه توی جدول قیمت دار و مبلغ رو از جدول کالا کپی کنه
این امکان به ما داده میشه که بتونیم به مشتریان خاص قیمت های خاص بدیم
در ضمن همه ی برنامه های پخش مویرگی مثل خودم که نمیتونم اسم برنامم رو اینجا بیارم(قوانین سایت) از این روش استفاده میکنند چون در صنعت هایی مثل پخش مواد غذایی استثناء در قیمت زیاده.
سایت شما نمیدونم چیه ولی اگر این رو پیاده سازی کنید ضرر نمیکنید.جواب داده.

[veniz2008]

وقتی که سفارش قطعی میشه
این حرف کاملا منطقیه. فقط یه سوال: پس چرا مبلغ رو درون فاکتور میاریم زمانیکه عملا ازش استفاده نمیکنیم؟(چون طبق پست قبلی ما برای محاسبه قیمت رو از جدول کالا میگیریم نه از جدول فاکتور).

[FastCode]

این حرف کاملا منطقیه. فقط یه سوال: پس چرا مبلغ رو درون فاکتور میاریم زمانیکه عملا ازش استفاده نمیکنیم؟(چون طبق پست قبلی ما برای محاسبه قیمت رو از جدول کالا میگیریم نه از جدول فاکتور).
ازش استفاده میکنیم
ما این کار رو میکنیم که اگر قیمت رو تغییر دادیم فاکتورهای قبلی به هم نریزه
و بتونیم برای فاکتور قیمت دستی هم بدیم
در واقع تنها کاربرد ه مبلغ در جدول کالا همون کپی ه پست ه قبل ه

[FastCode]

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

[veniz2008]

@همه
حواستون به تفاوت کاربرد ه دو کلمه ی سفارش و فاکتور در نوشته های من هست؟
لطف میکنید و فیلدهای هر سه جدول کالا، فاکتور و سفارش رو بگید. یه مختصر هم درباره جدول سفارش و فرقش با جدول فاکتور بگید.

[FastCode]

Product:
ID
Name
Price

Sale:
ID
CustomerID

SaleDetail:
ID
SaleID
ProductID
Price
Amount

Order:
ID
CustomerID


OrderDetail:
ID
OrderID
ProductID
Amount
Product که فقط یک قیمت پیشفرض داره که کاربر میتونه تغییر یده
Sale هم فقط header ه فاکتور ه که field های اضافش مثل تاریخ رو نیاوردم
SaleDetail هم کالاهای فاکتور ه که قیمتش رو وقتی میگیره که یک OrderDetail تبدیل به یک SaleDetail میشه از Product میگیره
Order هم header ه سفارش ه
OrderDetail هم جزئیات سفارش که وقتی کاربر مشاهدشون میکنه همراه مبلغی که از جدول ه کالا میاد نمایش داده میشه ولی در واقع مبلغی نداره

در ضمن در این طراحی میشه از خاصیت inheritance که در dbms هایی مثل postgresql وجود داره هم استفاده کرد

[baktash.n81@gmail.com]

دقیقاً همینطوره
باید اختلاف حساب داشته باشیم
چون فاکتور قطعی رو کاربر نباید تغییر بده

اگر کاربر قیمت کالا رو در جدول فاکتور تغییر بده و جمعش تغییر نکنه(خطای پیشبینی شده برنامه) در گزارش جمع کالاهای فروخته شده با جمع فاکتورهای فروخته شده اختلاف خواهیم داشت


از کجا می فهمید کدوم فاکتور تغییر کرده ؟!

[baktash.n81@gmail.com]

دقیقاً همینطوره
یعنی برنامه هر بار که اجرا شد همه ی database رو scan کنه؟
خیلی خوبه
توی سیستم های بزرگ ممکن ه چند ساعت طول بکشه,مثل بانک
یعنی هر کلاینت مثلاً همه ی سود های همه ی مشتریان شعبه رو چک کنه که درست باشن
به جای اینکه هردفعه که مشتری حسابش رو poll میکنه براش محاسبات رو انجام بده
این یعنی فاجعه

در ضمن میدونستید روش شما در دیتابیس های توزیع شده شبیه اونی که توی امضای من ه اصلاً کار نمیکنه؟

یعنی شما همینقدر متوجه شدی ؟!؟ تاحالا برای Update از SP استفاده کردید .. ؟!؟ من می گم اگه کسی از طریق برنامه مقدار Detail رو تغییر داد به جای اینکه من فقط مقدار همون Detail رو تغییر بدم مقدار جمع رو برای جدول مستر Update می کنم این چه ربطی به Scan کل جدول و ... اینا داره ...

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

بازم می گم دینرمالایز کردن جداول به شرطی که درست انجام بشه سرعت کار رو بالاتر می بره ... می تونید یه سرچ هم بکنید اگه البته تعصب اجازه داد ...

[baktash.n81@gmail.com]

92453


جسارتا اگه Adventure Work رو به عنوان یه مثال آموزشی معتبر قبول دارید می تونید یه نگاهی به جداولش بندازید ...

[FastCode]

یعنی شما همینقدر متوجه شدی ؟!؟ تاحالا برای Update از SP استفاده کردید .. ؟!؟ من می گم اگه کسی از طریق برنامه مقدار Detail رو تغییر داد به جای اینکه من فقط مقدار همون Detail رو تغییر بدم مقدار جمع رو برای جدول مستر Update می کنم این چه ربطی به Scan کل جدول و ... اینا داره ...

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

بازم می گم دینرمالایز کردن جداول به شرطی که درست انجام بشه سرعت کار رو بالاتر می بره ... می تونید یه سرچ هم بکنید اگه البته تعصب اجازه داد ...

من از هر روشی که بگی استفاده کردم//sp trigger view temp-table client-cache-with-sqlite
و هر نوی ORM ای هم که بگی تا الان نوشتم.//map cache lazy offfline online ..... فقط p2p هنوز ننوشتم که project ه فعلیم شاملش میشه
مشکلات ه SP:
۱.اگر کاربر یا admin یخواد دستی اطلاعات رو تغییر بده به مشکل میخوریم.
۲.میخوام یک کار قشنگ بکنم.اگر این ایراد رو بنویسم قبول نمیکنی.شما اول یک SP بنویس بعد من اینجا رو پر میکنم.

من ۲ روز ه دارم میگم که تغییر از طریق ه datbase رو هم باید در نظر گرفت.

اگر جدول رو admin تغییر داده باشه,برنامه شما چطوری میفهمه؟

بازم میگم,هر چیزی که توی کتابها هست برای همه سیستمها نیست.
one doesn't suit all

[baktash.n81@gmail.com]

شما که دیگه سمپل مایکروسافت رو که کلی کتاب به عنوان سمپل ازش استفاده کردن رو قبول نداری من چی بگم ... !!! بر حسب اتفاق این جداول که گذاشتم مربوط به فاکتور هست ... پس کاملا مرتبت با بحثه ...


واقعا دیگه نمی دونم شما چه جوری قانع می شی ... کی بهت بگه قبول می کنی ؟؟ ... شما روش قانع شدنت رو مشخص کن من از همون روش استفاده کنم ... !

[FastCode]

Adventure Work
UnitPrice رو میبینی؟

بعد دقت کردی یه چیزی اون بالا هست به اسم RevisionNumber؟
یعنی هر تغییری که میدیم فاکتور از اول ثبت میشه.تا نسخه قبلی رو داشته باشیم برای مقایسه
چقدر من این counter-sample هایی رو که میاری دوست دارم

[baktash.n81@gmail.com]

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

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

اصلا شما راست می گی ...

اینجا کسه دیگه ای نیست به این آدم توضیح بده ... شاید فهمید .... !

[FastCode]

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

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

اصلا شما راست می گی ...

اینجا کسه دیگه ای نیست به این آدم توضیح بده ... شاید فهمید .... !

ما که با هم دعوا نداریم
هر طرف دلائل خودش رو میاره برای این که ثابت کنه کدوم روش بهتره و چه مزایا و معایبی داره.تا به یک نتیجه واحد برسیم

توی این روش کار درستیه
چوت در adventureworks,هر فاکتوری که تغییر میکنه دوباره از اول ذخیره میشه


از نظر من adventureworks چون از این ساختار استفاده میکنه اصلاً case ه مناسبی برای مثال شما نیست
از اون یکی sample ه مایکروسافت استفاده کنید(اسمشو یادم نیست)