PDA

View Full Version : سوالی در طراحی پایگاه داده - جامعیت یا عدم جامعیت ؟



bad_boy_2007
یک شنبه 13 آبان 1386, 17:21 عصر
سلام دوستان
من یک مشکل دارم
برنامه ای دارم که یکسری فاکتور صادر میکنه و دریافت و پرداخت داره حالا برای اینکه مانده حساب مشتری رو نگه دارم مشکل دارم .
مشکل من اینه که نمیدونم دقیقا کدوم راه بهتره ؟
1- مانده حساب رو از طریق یک دید روی جداول نشون بدم
2- فیلدی داشته باشم که پس از هر تغییر مانده حساب رو متناسب بالا یا پایین کنه
3- بنا به پیشنهاد استادم فیلدی داشته باشم که اعتبار سطر رو تعیین میکنه و زمانی که اون سطر تغییر کرد اون فیلد نا معتبر بشه و در زمان آزاد سیستم مجددا اون فیلد رو معتبر کنم

در مورد راه سوم یکم فکر کردم دیدم چندان جذاب نیست میمونه روش 1 و 2 که با توجه به قواعد جامعیت و راحتی کد نویسی روش 1 ارجع تره ولی نمیدونم مثلا اگر هر مشتری بیش از 500 رکورد داشته باشه و بیش از 500 مشتری داشته باشیم یا حتی شاید بیشتر از این حرفا ، برنامه با روش 1 مشکلی نخواهد داشت ؟

لازم به ذکره که بگم من از SQLServerExpress2005 استفاده میکنم
یک مورد دیگه هم که لازمه بگم اینه که سیستمی که من برنامه ام رو روش نصب میکنم CPU 800 داره شاید روی سیستمهای پایین تر هم لازم شد نصب کنم.
ممنون میشم راهنماییم کنید

bad_boy_2007
دوشنبه 14 آبان 1386, 22:34 عصر
ممنون از راهنماییتون !!!!!!!!

shervinrv
دوشنبه 14 آبان 1386, 22:51 عصر
به نظر من روش 2 بهتره
چون یک بار که تغییر رو ثبت کردید تا وقتی که تغییری نداشته باشید فق ط با یک سلکت ساده میتونید ببینید مانده حساب چقدره
ولی در روش یک هر دفعه باید حساب کنه و همه فیلدارو بخونه و محاسبات رو انجام بده

یادمه منم یه سیستم مالی مینوشتم برای مانده از روش 2 استفاده کردم

SYNDROME
دوشنبه 14 آبان 1386, 23:37 عصر
1- مانده حساب رو از طریق یک دید روی جداول نشون بدم
2- فیلدی داشته باشم که پس از هر تغییر مانده حساب رو متناسب بالا یا پایین کنه

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

ممنون از راهنماییتون !!!!!!!!
؟؟؟؟؟
موفق باشید

shervinrv
سه شنبه 15 آبان 1386, 00:02 صبح
در روش اول امکان خطا کمتر است ولی هر بار باید حساب شود.
روش دوم خیلی ذخیره است ولی اگر رکوردی حذف شود و در فیلد اعمال نشود گزارشات شما اشتباه می شود.
حالا انتخاب با خودتان است سرعت ملاک است یا دقت؟

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

bad_boy_2007
سه شنبه 15 آبان 1386, 06:53 صبح
ممنون از راهنمایی همه دوستان

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

؟؟؟؟؟
موفق باشید

دقت ، اهمیت بیشتری داره ولی اگه افت سرعت به صورت ملموس باشه برنامه دیگه ارزشی نداره ! حالا میخوام بدونم اگر از روش 1 استفاده کنم با افت سرعت تا چه حدی مواجه میشم ؟
کسی برنامه بزرگی نوشته مثلا در حد 1000000 (یک ملیون) رکورد که روی سیستم نه چندان بالا سرعت برنامش رو تست کرده باشه ؟
بیشتر از این جهت در استفاده از روش 1 شک دارم که میترسم سرعت به شکل بدی افت داشته باشه ، برای اینکه یه چیزی حدود 20 تا جدول اصلی دارم که روشون 5 تا View اصلی تعریف شده و هر View باید حدودا 5 تا 10 جدول رو با هم ادغام کنه و میترسم اگه رکوردهام رو 400 یا 500 هزار بره به مشکل بخورم.

SYNDROME
سه شنبه 15 آبان 1386, 07:22 صبح
خیلی راحت بعد از هر تغییر تغییرات را اعمال میکنه
دلیلی برای اشتباه و اعمال نشدن وجود نداره
کافیه هواسش باشه
1-اگر یک رکورد به صورت دستی را از بانک حذف کنند آن وقت همه گزارشات غلط می شود.
2-زمانی که برنامه کوچک باشد شکی نیست اشتباه کم می شود ولی اگر تعداد جاهایی که باید این تغییرات اعمال شود زیاد بشود ممکن است خطا رخ دهد و همچنین باید از TransAction ها هم استفاده شود تا در صورتی که کاری انجام نشد و خطا رخ داد عملیات قابل برگشت باشد.


دقت ، اهمیت بیشتری داره ولی اگه افت سرعت به صورت ملموس باشه برنامه دیگه ارزشی نداره ! حالا میخوام بدونم اگر از روش 1 استفاده کنم با افت سرعت تا چه حدی مواجه میشم
افت سرعت اگر بانک شما طراحی درست داشته باشد چندان نخواهد بود.
خود بنده یک گزارش دارم که برای نتیجه دادن باشد حداقل 5 دقیقه صبر کنید وای نتیجه اینقدر برای کاربر مهم است که زمان را در نظر نمی گیرد.


کسی برنامه بزرگی نوشته مثلا در حد 1000000 (یک ملیون) رکورد که روی سیستم نه چندان بالا سرعت برنامش رو تست کرده باشه ؟

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

shervinrv
سه شنبه 15 آبان 1386, 15:06 عصر
بله 100% در مورد 1 حق با شماست
دیگه خب بستگی به خودشونم داره دیگه
در مورد افت سرعت هم در مورد 2 نه افت سرعتی نخواهید داشت دوست عزیزمون به طراحی شما خیلی بستگی داره
همین الان من یه برنامه نوشتم که از فایل اطلاعاتو میخونه و کلی کار روش انجام میده و برای هر فایل حدود 5 عمل روی دیتا بیس انجام میده
ولی چون سعی کردم طراحی اصولی باشه
الان یه فولدر شامل 1000 فایل بهش میدم حدود 10 ثانیه 1000 فایل رو میخونه و همه کاراشو میکنه و 5000 عمل روی دیتا بیس انجام میده

SYNDROME
سه شنبه 15 آبان 1386, 21:18 عصر
الان یه فولدر شامل 1000 فایل بهش میدم حدود 10 ثانیه 1000 فایل رو میخونه و همه کاراشو میکنه و 5000 عمل روی دیتا بیس انجام میده
این زمان برای شما است با توجه به تغییر سیستم و تابعی که دوستمان می نویسد این زمان تغییر می کند.
در بعضی از موارد حتی کاربر را می توان تا 5 دقیقه نگه داشت چون نوع گزارش خیلی کم استفاده می شود ولی زمانی که کاربر مدام به یک گزارش کار می کند حتی 1 ثانیه تحمل کردن هم برای کاربر سخت است.
ولی همه گفته ها بستگی به نگرش شما دارد.
موفق باشید

AminSobati
سه شنبه 15 آبان 1386, 21:20 عصر
دوست عزیزم،
سبک سنگین کردن و انتخاب یک روش برای این موضوع کار ساده ای نیست. چرا که نحوه انجام محاسبات و قابلیت Queryها برای بهینه شدن خیلی مهم هستند تا بشه روش اول رو انتخاب کرد. از طرفی، این رو در نظر بگیرید که در روش دوم، ورود هر رکورد، شروع یک محاسبه رو در بر خواهد داشت که کار Insert و هر گونه ویرایش رو کمی کندتر میکنه.
من جای شما باشم با یک سری اطلاعات Pilot حتما تست انجام میدم.
با توجه به اینکه Express Edition استفاده میکنید، امکان داشتن Job برای به روز رسانی اطلاعات منتفی هست.

bad_boy_2007
چهارشنبه 16 آبان 1386, 06:18 صبح
با تشکر از همه دوستان خوبم بابت راهنمایی هایی که کردید بخصوص جناب ثباتی عزیز که همیشه راهنماییم میکنید .
فکر میکنم با این اطلاعات کمی که در SQLServer دارم در فعلا روش 1 رو محتاتانه انتخاب کنم بهتره درصورتی که بعدا با افت سرعت محسوس مواجه شدم یا از Job که جناب ثباتی راهنمایی فرموردند استفاده کنم فکر کنم بتونم از روش 2 هم با استفاده از تریگر استفاده کنم که هم تنزل سرعت در حد محسوس نداشته باشم و هم جامعیت داده ها حفظ بشه ولی در حال حاظر به خاطر وقت کم همون View رو استفاده میکنم.

AminSobati
چهارشنبه 16 آبان 1386, 12:54 عصر
دوست عزیزم حتما از وجود ایندکسهای مناسب اطمینان حاصل کنید تا Queryهای شما سرعت ایده آلی داشته باشند