PDA

View Full Version : راهنمایی در مورد طراحی یک سیستم فروش در قالب یک مثال واقعی



Navid7h
چهارشنبه 02 شهریور 1384, 17:19 عصر
با سلام خدمت دوستان محترم
من میخواستم یک سری سوال در مورد طراحی Database برای Application ها رو در قالب یک مثال بپرسم .
فرض کنید یک سیستم خرید و فروش داریم یا مثلا یک سیستم فروش برای رستوران
در ابتدا سیستم را خیلی پیچیده نمی کنم .

فرض کنیم سیستم ما باید فروش انواع غذا را ثبت کند
یک Tabel داریم برای لیست غذا (MENU) و یک TABEL هم داریم برای سفارشات Orders


1) اگر انواع غذا با یک PK از جدول MENU انتخاب شود یعنی در جدول Order ها fk باشد اگر یک غذا از لیست MENU حذف شود
تمام رکوردهای مربوط به آن از Orders حذف می شوند.
آیا بهتر است برای وجود داشتن یا نداشتن غذا از یک Field که bool است استفاده کنیم ؟


2) قیمت واحد هر غذا باید در Order ها هم بیاید .چون اگر Price از جدول Menu به صورت FK در Order باشد با دستکاری MEnu فاکتورها هم عوض میشوند !
مثلا 6 ماه دیگر همبرگر 300 تومان گران شود تمام فاکتورهای قبلی هم با توجه به قیمت فعلی محاسبه میشوند !
آیا این Normalization را نقض نمیکند ؟ (فکر نکنم !)


3) با توجه به اینکه هر سفارش میتواند شامل چندین غذا باشد راه اول و کلاسیک (تا آنجایی که من میدانم !) این است که یک جدول Orders داشته باشیم
و یک جدول OrdersDetail برای فراهم کردن یک رابطه One To Many .
ایا راه دیگری هم هست ؟

و سوال آخر !
4) در صورت داشتن دو جدول Orders و OrdersDeTail آیا بهتر است جمع کل اقلام در Orders در یک فیلد مجزا بیاید
یا با Join کردن 2 جدول نتیجه را در هنگام گرفتن Query محاسبه کنیم !؟
منظور این است که بعضی وقتها De-normalization باعث بالا رفتن سرعت می شود. اما آیا Data Integrity در این مثال نقض نمیشود ؟!

Navid7h
جمعه 04 شهریور 1384, 00:46 صبح
چرا کسی هیچ جوابی نمیده ؟ :(

AminSobati
دوشنبه 07 شهریور 1384, 22:23 عصر
دوست عزیزم،

1) برای اینکه با حذف Parent، مجبور به حذف Childها نشین، میبایست اول مقدار FK برای Childها رو به NULL تغییر بدین و بعد PK رو حذف کنین

2) در جدولی که اطلاعات فاکتور رو ذخیره میکنید، باید قیمت فروخته شده رو هم داشته باشید تا با تغییر قیمت محصولات، فاکتورهای شما معتبر باقی بمونن

3) این بهترین راهه

4) اگر دسترسی به مقدار جمع یک فاکتور، بسیار زیاد هستش و احساس میکنید Denormalize بهتره، این کار رو انجام بدین. ولی به یاد داشته باشید که با ویرایش یک فاکتور، میبایست این عدد رو هم به روز کنید.
چرا فکر میکنید این کار به Data Integrity آسیب میرسونه؟!

Navid7h
چهارشنبه 09 شهریور 1384, 00:17 صبح
جناب آقای امین خان ثباتی
اولا مرسی که تو این بحث شرکت کردین و جواب سوال من رو دادین :تشویق:
ثانیا :
در مورد جواب شما به قسمت اولا آیا منظورتون این بود که اصلا Relation بین دو جدول تعریف نکنم ؟ اگر این نبود میشه توضیح بدین !

در مورد قسمت آخر فکر کنم اگر اطلاعات یکسان در مکانهای مختلف در DB وجود داشته باشه جامعیت اطلاعات DATA Integrity پایین میائ چون برای هر Update باید یکسری کار رو چند جدول انجام بدیم . آیا اشتباه فکر میکنم ؟

AminSobati
چهارشنبه 09 شهریور 1384, 22:36 عصر
در مورد ثانیا:
اتفاقا این روش برای زمانی هستش که رابطه رو تعریف کردین. چون اگر رابطه وجود نداشته باشه که اصلا الزامی به تغییر به NULL نیست.

در مورد قسمت آخر:
Denormalize به معنی نادیده گرفتن Data Integrity نیست. اگر خیلی کلاسیک به موضوع نگاه کنیم، زمانی Integrity آسیب میبینه که شما اطلاعات رو مغایر با قوانین بانک اطلاعاتی نگه دارید.
با تعریف شما، پس هیچ وقت نباید یک رکورد Parent رو حذف کرد، چون Childهای اون Orphan (یتیم) میشن. ولی شما حذف رو انجام میدین و متعاقبا، Childها رو هم ممکنه حذف کنین.
دقیقا هم موضوع در مورد Denormalize صادقه. شما یک قیمت رو در فاکتور تغییر میدین ولی بلافاصله جمع کل رو مجددا محاسبه میکنین.
پس اطلاعاتی مغایر قوانین بانک اطلاعاتی شما ذخیره نشده..