PDA

View Full Version : ایجاد Relation تا چند سطح به صرفه است؟



haamidd
شنبه 09 اسفند 1393, 08:23 صبح
سلام و خسته نباشید.
ببخشید میخواستم بدونم در طراحی بانک اطلاعاتی تا چند سطح Relation زدن به صرفه است؟ تصویر زیر رو نگاه کنید.
من میخوام بدونم که من باید id جدول buinlings رو هم بزارم تو جدول user و این دوتا رو Relation بزنم یا نه؟ یا اینکه الان من میتونم با relation زدم جداول user و builingPeople و unit و building میتونم این رابطه رو بدست بیارم!!!

128941

golbafan
شنبه 09 اسفند 1393, 08:29 صبح
سلام

این تصویر دید دقیقی نمیده اما من ترجیح میدم building رو با BuildingPeoples متصل کنم. نه با یوزر و نه با یونیت

SabaSabouhi
شنبه 09 اسفند 1393, 08:43 صبح
سلام
بجای این که یه سوال رو جواب بدم ( هر چند که به قول دوستمون golbafan صورت مساله شفاف نیست و نمی‌شه بهش جواب داد )
توصیه می‌کنم شما مبحث نرمال‌سازی رو یه مطالعه کوچیک بکنی، بعد جدول‌هات رو نرمال ( حداقل سطح 3 ) طراحی کنی.
بعد اگه به نظرت می‌رسه که مراحل joinهای زیادی وجود داره و ممکنه سرعتت رو کم کنه، denormal کن و لینک‌های
اضافی قرار بده تا سرعت بالا بره.

صبا صبوحی

haamidd
شنبه 09 اسفند 1393, 15:21 عصر
ممنون.
یعنی میزان join های مناسب تا 3 سطح است؟ (به طور معمول)


(اتفاقا من اومدم نرمال سازی کردم و یوزر هامو به دودسته ی BuildingPersonel و BuildingPleople تقسیم کردم، در جدول user اطلاعات عمومی و مشترک رو میگیرم و در دو جدول دیگه اطلاعات مخصوص به هر دسته رو میگیرم)

SabaSabouhi
شنبه 09 اسفند 1393, 22:00 عصر
ممنون.
یعنی میزان join های مناسب تا 3 سطح است؟ (به طور معمول)


(اتفاقا من اومدم نرمال سازی کردم و یوزر هامو به دودسته ی BuildingPersonel و BuildingPleople تقسیم کردم، در جدول user اطلاعات عمومی و مشترک رو میگیرم و در دو جدول دیگه اطلاعات مخصوص به هر دسته رو میگیرم)

سلام
1. شما اگه دوست داری تو این سایت ( و احتمالاً تو بقیه‌ی سایت‌ها ) برای پرسش خودت پاسخ مناسب و درست بگیری، باید پرسش خودت رو خوب مطرح کنی.
دوستم golbafan گفت که «تصویر دقیقی نمی‌ده» من که گفتم صورت مساله شفاف نیست. اما شما از پاسخی که ما به شما ندادیم چطور برداشت کردی که joinهای مناسب 3 تا هست؟
2. من بدون این صورت مساله رو بدونم ( چون هنوز هم نمی‌دونم ) یه جواب کلی به شما دادم.
3. خیلی صریح و شفاف می‌گم. چیزی به نام تعداد join مناسب وجود نداره، نرمال کردن database یک مبحث جدی هست که باید مطالعه کنی و جدول‌ها رو
با منطقی که اونجا مطرح شده طراحی کنی. حتا همین نرمال‌سازی هم سطوح زیادی داره که لازم نیست همه‌ی اون‌ها رو انجام بدی. تو نرمال سازی شما می‌تونی
مثلاً تا سطح 5 نرمان کنی یا سطح 4، ولی معمولاً سطح 3 رو کافی می‌دونن یا bcnf رو.
باز هم اضافه می‌کنم که حتا دیتابیس نرمال شده رو می‌تونی با تشخیص خودت ( اگه تجربه‌ی کافی داری ) از حالت نرمال خارج کنی برای بالا بردن performance.

اگه لازم بود، 10 تا join بزن. مطمئن باش اگه لازم باشه، کسی به 10 تا join شما اعتراضی نمی‌کنه. فقط یه چیز خیلی مهمه، تو ذهنت باشه که
تا جایی که می‌تونی از فیلدهای Nullabe و left outer join دوری کن که سرعت محاسبه query رو خیلی پایین میاره. بخصوص تو حجم‌های خیلی بالا.
هر چند که نصف مزه‌ی query نوشتن به left outer joinهاش هست.

صبا صبوحی

haamidd
یک شنبه 10 اسفند 1393, 17:40 عصر
از فیلدهای نال دوری کن یعنی تو دیتابیسم نزارم که فیلدی خالی بمونه؟ اخه اگه نال بمونه که بهتره؟!!! اخه حجمی استفاده نمیشه! ها؟ ممنون میشم به توضیحی بدی. مرسی

golbafan
یک شنبه 10 اسفند 1393, 18:58 عصر
از فیلدهای نال دوری کن یعنی تو دیتابیسم نزارم که فیلدی خالی بمونه؟ اخه اگه نال بمونه که بهتره؟!!! اخه حجمی استفاده نمیشه! ها؟ ممنون میشم به توضیحی بدی. مرسی

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

SabaSabouhi
دوشنبه 11 اسفند 1393, 06:24 صبح
از فیلدهای نال دوری کن یعنی تو دیتابیسم نزارم که فیلدی خالی بمونه؟ اخه اگه نال بمونه که بهتره؟!!! اخه حجمی استفاده نمیشه! ها؟ ممنون میشم به توضیحی بدی. مرسی

سلام
منظور من این نیست که اصلاً نداشته باشی، گاهی لازم هست فیلدها امکان خالی بودن رو داشته باشن. اما هر چی کمتر باشه بهتره.
همونطور که دوستمون gobafan گفته، باعث کندی queryهای سنگین می‌شه.

صبا صبوحی