دو جدول یا نال بودن کلید خارجی

[shotok]

بسم الله الرحمن الرحیم
با سلام
برنامه ای که تحلیل می کنم بدین صورت است که هم داوطلبان موسسه و هم اعضای عادی می توانند از آنجا خرید داشته باشند. که اطلاعاتی که در مورد داوطلب و اعضای عادی ثبت می شود متفاوت است. پس برای هر کدام باید جداولی جداگانه در نظر بگیرم.
سوال از اینجا شروع می شود؛
2 نوع نگاه می توان به این مسئله داشت. یا 2تا جدول فروش داشته باشیم؛ یکی برای داوطلب و دیگری برای اعضای عادی
و یا می توان 1جدول داشت و هم کلید خارجی جدول داوطلب و هم اعضای عادی در ان وجود داشته باشد و اگر داوطلب خرید داشت کلید داوطلب پر شود و کلید عضو عادی نال باشد. و بالعکس
به نظر شما کدام اصولی تر است؟
با تشکر:11:

[senaps]

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

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

[shotok]

با سلام
ممنون از پاسختون
پایگاه داده ای که با اون کار کردم SQL SERVER 2008 هست.
اگه براتون امکان داره راجع به ارث بری بیشتر توضیح بدید. و مسئله رو باز کنید
با تشکر:11:

[senaps]

منظورم از ارث بری، ارث بری تو برنامه‌نویسی بودش.... تو دیتا بیس همون حالتی که خودتون گفتین استفاده میشه....و فیلد های اضافی خالی می‌مونه...

[shotok]

منظورم از ارث بری، ارث بری تو برنامه‌نویسی بودش.... تو دیتا بیس همون حالتی که خودتون گفتین استفاده میشه....و فیلد های اضافی خالی می‌مونه...
منظورتون از اینکه گفتید فیلدهای اضافی خالی می مونه چیه؟
کدوم راه رو پیشنهاد می دید اینکه 2تا جدول بگیرم یا 1جدول با 2تا کلید خارجی؟
با تشکر

[senaps]

۱ جدول با ۲ کلید خارجی....

ببینید، شما دارین کارا رو سخت میکنین!!!
شما میخوای یه سری اطلاعات فروش رو ثبت کنی و یا بررسی کنی....
برای هر فروش، یه کد در نظر بگیر.... و همه‌ی افراد رو مشتری در نظر بگیر....ولی اطلاعاتی که از تمام افراد میخوای ثبت بشه رو استفاده میکنی... مثلا:
جدول عضو:
نام
نام خانوادگی
شماره تلفن
ادرس
کد عضویت
تاریخ عضویت

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

ولی من باشم، این دو جدول رو خلاصه میکنم:
مشتری:
کد
نام
نام خانوادگی
شماره تلفن
ادرس
کد عضویت
کد داوطلبی
تاریخ عضویت
داوطلب(بولین!)

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

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

امیدوارم که تونسته باشم منظورم رو برسونم...

[عــــلی]

بنام خدا.
سلام.


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

امیدوارم که تونسته باشم منظورم رو برسونم...
البته من زیاد کارم با دیتابیس حرفه ای نیست.
اما به نظرتون اینطوری میزان پردازش اطلاعات سخت تر و بیشتر نمیشه؟
مثلاً اگه دوتا جدول بسازیم و توی هر کدوم 10000 فیلد باشه.برای هر کدوم که بخوایم جستجو بزنیم فقط کافیه 10000 فیلد جستجو بشه.
اما اگه این دوتا جدول یکی باشن.برای جستجو نیاز هست بین 20000 فیلد جستجو بشه.یعنی دوبرابر.و هرچه تعداد جداولی که با هم ادغام شدن بیشتر باشه پردازش بالاتر میشه.
البته این برای Sql چیزی نیست.ولی اگه توی سرور باشه و هزاران کاربر در دقیقه جستجو بزنن میدونید که یک فاجعه میشه.

[senaps]

اما به نظرتون اینطوری میزان پردازش اطلاعات سخت تر و بیشتر نمیشه؟

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

برا همین، شخصا به این نتیجه رسیدم که اینجوری حالت نرمال تری هستش..... ولی به این نکته‌ای که شما فرمایش کردی علی جان فکر نکرده بودم تا حالا....
البته اینجوری برا ۱۰-۲۰ تا کلاینت مشکلی نباید داشته باشه!! فقط بحث اینه که تو استفاده‌ی مشترک سرور هنگ نکنه!!

به نظرم در این مورد باید تو استک‌اور‌فلو بپرسیم ببینیم نظر ملت بلاد کفر چیه...

[shotok]

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

[shotok]

به نظرم در این مورد باید تو استک‌اور‌فلو بپرسیم ببینیم نظر ملت بلاد کفر چیه...
با سلام
نظرشون رو جویا شدید؟:20:

[Payman_62]

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