راهنمایی در مورد تعداد جداول

[Bahar_HS]

با سلام
برای دیتابیس یه شرکت خرید و فروش ، اطلاعات خرید یک مشتری باید به این صورت باشه:

(به طور مثال)

تاریخ شماره فاکتور ردیف خرید نام کالا قیمت تعداد قیمت کل پرداختی بدهکاری
---------------------------------------------------------------------------------------------------------

1/15 20 1 کیس --- 3
1/15 20 2 موس --- 10
1/15 20 3 کارت گرافیک --- 5
1/20 21 1 کیبرد ----- 10
1/20 21 2 موس ------ 10
1/20 21 3 مودم ------- 5
1/20 21 4 مانیتور ------- 5

وبه همین ترتیب،
این شرکت کالاهای خیلی متنوعی داره و واز قبل هم لیست کالاهاش مشخص نیست
به همین دلیل براش جدول جداگانه در نظر نگرفتیم،
با فرض ثابت بودن مشتری ها یه جدول برای مشخصات مشتری در نظر گرفتیم و با ID که به مشتری تخصیص داده میشه با جداول دیگه ارتباط پیدا می کنه،
من این جدول رو به دو جدول شکستم، این طوری:
کد کدمشتری تاریخ فاکتور /// و بقیه ستون ها هم در جدول خرید،

مسئول گروه برای راهنمایی به من گفتند که میشه جدول رو به 3 جدول شکست و یکی از این جداول فاکتور و ردیف رو با هم به عنوان کلید در نظر می گیریم وبه این وسیله با جدول خرید
ارتبط برقرار میشه،
می خواستم راهنمایی م کنیم که کدوم مدل شکستن جدول بهتره؟ یا چطوری میتونه بهتر باشه؟ :متفکر:

[pezhvakco]

درود :

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


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


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

فکر خوش .

[Bahar_HS]

سلام
ممنون از راهنمایی تون،

جدول مشتری با توجه به ثابت بودن مشتری ها شامل:
کد مشتری (که SQL خودکار تخصیص میده)،نام،نام خانوادگی،شماره ی همراه،شماره محل کار،ونشانی محل کار
(من فکر می کنم که یه ستون بدهکاری اینجا در نظر بگیریم بهتره)

این از جدول مشخصات مشتری و در جداول دیگه با کد مشتری کار می کنیم،این تا اینجا،

برای کالاها کدی در نظر نمی گیریم و مثلا کارمند شرکت موقعی که مشتری میاد ازش خرید کنه،همون موقع دستی نام کالا و قیمتشو وارد می کنه،

من هم ،همون طور که شما گفتید ، 2تا جدول در نظر گرفتم،
(این که می گم درسته؟برای این که مسائل بهینگی و کاهش افزونگی رعایت بشه باید داده های ثابت رو از جدول بیرون بکشیم و باID که بهشون تخصیص می دیم کار کنیم :متفکر:)

جدول 1:
کد مشتری،تاریخ خرید،شماره ی فاکتور خرید و ID این رکورد که میشه کلید اصلی این جدول

جدول2:
id جدول بالا ،ردیف(که تعداد کالاهای خریداری شده در هر بار خریدرو نشون میده)،قیمت کالا،
تعداد خریداری شده از این کالا ،قیمت کل که به عنوان ستون محاسباتی در نظر می گیریم،پرداختی مشتری،و بدهکاری که باز به عنوان یه مقدار محاسباتی از روی قیمت کل و پرداختی حسابش می کنیم،
(یعنی حساب کتاب هر بار خرید مشتری مشخص باشه ، من فکر می کنم یه ستون پرداختی یا بدهکاری کل باید در جدول مشتری در نظر بگیریم، ولی نمی دونم که لازمه یا نه وباید ستون فیزیکی باشه یا محاسباتی)

(این طرح ذهنی مه که نمی دونم درسته یا نه و هنوز پیاده سازی نشده)

بازهم ممنون از راهنمایی تون
:تشویق::تشویق::تشویق:

[pezhvakco]

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


برای کالاها کدی در نظر نمی گیریم و مثلا کارمند شرکت موقعی که مشتری میاد ازش خرید کنه،همون موقع دستی نام کالا و قیمتشو وارد می کنه،
این کار زیاد خوب نیست، چون برای ذخیره اطلاعات و گزارش گیری ها لازمه یه جدول انبار داشته باشی .

در حالت کلی به نظر من بهتره مقادیر محاسباتی (جمع فاکتور، بدهکاری، بستانکاری و ...) رو به عنوان ستون در جدول نیاری و در لحظه نیاز محاسبه کنی .

فکر خوش .

[Bahar_HS]

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

می شه کمی در این مورد توضیح بدید؟
در حالت کلی به نظر من بهتره مقادیر محاسباتی (جمع فاکتور، بدهکاری، بستانکاری و ...) رو به عنوان ستون در جدول نیاری و در لحظه نیاز محاسبه کنی .

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

و اما یکی از مهمترین گزارش گیری های مورد نیاز گزارش خرید یه مشتریه ،
که به ازای هر خریدش باید تاریخ خرید و شماره ی فاکتور خرید آورده شود،
دستور SELECT با JOIN بیاد حله؟

[pezhvakco]

جدول هام درست بود دیگه؟ مشکل افزونگی یا بهینه بودن که ندارن؟
تا جایی که از توضیحات شما فهمیدم و با اون تغییرات که گفتن، احتمالا درسته !

[QUOTEدستور SELECT با JOIN بیاد حله؟ [/QUOTE]
آره " حله " ...

فکر خوش .

[Bahar_HS]

سلام
یه سوال دیگه،

چون قراره که شماره ی فاکتورها رو خود SQL بده و در هر جدول فقط میشه یه ستون با خاصیت Identity تعریف کرد چطور میشه "ID مشتری،تاریخ و شماره ی فاکتور" رو با هم به عنوان کلید در نظر گرفت؟ :متفکر: