مزایا و معایب رابطه 1-1

[Exception]

با توجه به پیاده سازی جداول از روی دیاگرام کلاس (Class Diagram) گاهی بین بعضی جداول، رابطه های یک به یک (1-1) ایجاد می شود. طبیعتا این جداول قابل ادغام هستند.
در نتیجه در دو حالت می توان این جداول را پیاده سازی کرد:

دو جدول با رابطه 1-1
یک جدول ادغام شدهدر مورد مزایا و معایب هر روش، چیزی که به نظر خودم رسیده این بود:
در حالت اول:
مزایا: چون منطبق بر دیاگرام کلاس طراحی شده، هنگام برنامه نویسی، آبجکتهای معادل هر جدول به صورت منطقی از هم جدا می شوند و ظاهرا مفهوم تر خواهد بود.
معایب: نیاز به Join های بیشتر هنگام Query گرفتن و در نتیجه کاهش سرعت و همچنین پیچیده شدن Insert ها و Delete ها.

در حالت دوم:
مزایا: (حل معایب مورد قبلی)
معایب: (نقض مزیت مورد قبلی)

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

[mzjahromi]

ضمن اینکه در مورد اول تکرار داده ها و احتمال عدم همخوانی هم وجود داره

[ClaimAlireza]

حالت دوم در بعضی حالات ایجاد آنومالی میکنه.

مثلا یک فیلد که برای تمایز دادن اطلاعات فارسی و انگلیسی در یک جدول قرار میگیره.

[SabaSabouhi]

با توجه به پیاده سازی جداول از روی دیاگرام کلاس (Class Diagram) گاهی بین بعضی جداول، رابطه های یک به یک (1-1) ایجاد می شود. طبیعتا این جداول قابل ادغام هستند.
در نتیجه در دو حالت می توان این جداول را پیاده سازی کرد:

دو جدول با رابطه 1-1
یک جدول ادغام شدهحالا به نظر شما مزایا و معایب هر کدام چیست و کدام حالت توصیه می شود؟ چرا؟


با سلام
به نظر من تفکیک اطلاعات یک جدول به دو جدول فقط وقتى قابل توجیه هست که تعداد سطرهاى جدول دوم کمتر از جدول اول باشه. که اگه ادغام بشن بجاى سطرهایى که در جدول دوم وجود ندارند باید فیلدهاى Null قرار بدیم. در غیر این صورت و اگر تعداد سطرهاى هر دو جدول برابر باشند با این تفکیک فقط باز اضافى به سیستم تحمیل خواهیم کرد ( به دلیل نیاز به Joinهاى اضافى )

صبا صبوحى

[حامد مصافی]

رابطه یک به یک در متدلوژی هایی معمول و رایجی چون بویس یا بویس-کاد مذمت شده هستند. فیلدهای یک سطر جدول با یددیگر رابطه یک به یک دارند این رابطه در جدا بودن جدول ها فقط بار اضافی متوجه سیستم می کنه و دیگر هیچ. موردی که شما به عنوان مزیت روش اول ذکر کردید واقعاً یک وزیت در برنامه نویسی نیست (اگر هم باشه پیچیدگیش بیشتر از میزان تساهلشه) و بالطبع این مورد ایراد مورد دوم رو از بین می بره.

[Exception]

ضمن اینکه در مورد اول تکرار داده ها و احتمال عدم همخوانی هم وجود داره
ظاهرا تنها اطلاعاتی که تکرار میشه، همون کلید هست. میشه بیشتر توضیح بدین که منظورتون چی بود؟

[Exception]

حالت دوم در بعضی حالات ایجاد آنومالی میکنه.

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

[Exception]

با سلام
به نظر من تفکیک اطلاعات یک جدول به دو جدول فقط وقتى قابل توجیه هست که تعداد سطرهاى جدول دوم کمتر از جدول اول باشه. که اگه ادغام بشن بجاى سطرهایى که در جدول دوم وجود ندارند باید فیلدهاى Null قرار بدیم. در غیر این صورت و اگر تعداد سطرهاى هر دو جدول برابر باشند با این تفکیک فقط باز اضافى به سیستم تحمیل خواهیم کرد ( به دلیل نیاز به Joinهاى اضافى )

صبا صبوحى
مطمین نیستم، ولی حدس میزنم که وجود تعداد Null زیاد، به هر حال از Join کردن های پی در پی برای DBMS کار سبکتری به حساب بیاد. هر چند این Null ها زیاد باشند. همچنین با توجه به حجم هارددیسک های امروزی هم فکر نمیکنم حجم دیتابیس اونقدرها برای کسی مهم باشه. نظر شما چیه؟

[Exception]

رابطه یک به یک در متدلوژی هایی معمول و رایجی چون بویس یا بویس-کاد مذمت شده هستند. فیلدهای یک سطر جدول با یددیگر رابطه یک به یک دارند این رابطه در جدا بودن جدول ها فقط بار اضافی متوجه سیستم می کنه و دیگر هیچ. موردی که شما به عنوان مزیت روش اول ذکر کردید واقعاً یک وزیت در برنامه نویسی نیست (اگر هم باشه پیچیدگیش بیشتر از میزان تساهلشه) و بالطبع این مورد ایراد مورد دوم رو از بین می بره.
حرف شما کاملا منطقی به نظر میاد. آیا در مورد این که گفتید این رابطه ها در متدولوژی هایی مثل بویس-کاد مذمت شده اند، منبعی هم دارین؟

[SYNDROME]

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

[Exception]

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

حدس میزنم که وجود تعداد Null زیاد، به هر حال از Join کردن های پی در پی برای DBMS کار سبکتری به حساب بیاد.

[mhadvi_mahmaood]

مطمین نیستم، ولی حدس میزنم که وجود تعداد Null زیاد، به هر حال از Join کردن های پی در پی برای DBMS کار سبکتری به حساب بیاد. هر چند این Null ها زیاد باشند. همچنین با توجه به حجم هارددیسک های امروزی هم فکر نمیکنم حجم دیتابیس اونقدرها برای کسی مهم باشه. نظر شما چیه؟
فیلدهای Null حجم بسیار بسیار کمی نزدیک به صفر رو اشغال میکنند. پس نگران وجود فیلدهای Null در دیتابیستون نباشید.
در ضمن اگر ما میخواستیم اینقدر به حجم دیتابیس هامون اهمیت بدیم و پرفرمنس رو فدای حجم کنیم آنگاه هیچ وقت نباید ایندکس میساختیم.
در دنیای واقعی شاید رابطه های یک به یک نه تنها حجم دیتابیس رو کم نمی کنند بلکه به دلیل اینکه یک فیلد کلید اصلی هم در جدول دوم ذخیره بشه حجم بیشتری اشغال خواهد کرد.

[mzjahromi]

حالت دوم در بعضی حالات ایجاد آنومالی میکنه.

مثلا یک فیلد که برای تمایز دادن اطلاعات فارسی و انگلیسی در یک جدول قرار میگیره.
اتفاقا شکستن جدول در حالت 1-1 ممکنه عدم همخوانی ایجاد کنه


ظاهرا تنها اطلاعاتی که تکرار میشه، همون کلید هست. میشه بیشتر توضیح بدین که منظورتون چی بود؟
همون کلید

[SabaSabouhi]

مطمین نیستم، ولی حدس میزنم که وجود تعداد Null زیاد، به هر حال از Join کردن های پی در پی برای DBMS کار سبکتری به حساب بیاد. هر چند این Null ها زیاد باشند. همچنین با توجه به حجم هارددیسک های امروزی هم فکر نمیکنم حجم دیتابیس اونقدرها برای کسی مهم باشه. نظر شما چیه؟

با سلام
از این دیدگاه حق با شماست، اما برخى اوقات امکان داره که بخواهیم از این یکى نبودن تعداد سطرها استفاده کنیم.
مثلاً تصور کنید که جدول A1 جدول اصلى ما باشه و جدول A2 رو از اون جدا کرده باشیم که فقط حاوى سطرهاى غیر NULL ما هست. حالا امکان داره که بنا به شرایط نیاز داشته باشیم که جدول B رو با جدول A2 ارتباط بدیم.
و یا این که Trigger روى جدول A2 داشته باشیم.

در مواردى این‌چنین جدا کردن جدول از نظر من توجیه داره.

صبا صبوحى

[SabaSabouhi]

مطمین نیستم، ولی حدس میزنم که وجود تعداد Null زیاد، به هر حال از Join کردن های پی در پی برای DBMS کار سبکتری به حساب بیاد. هر چند این Null ها زیاد باشند. همچنین با توجه به حجم هارددیسک های امروزی هم فکر نمیکنم حجم دیتابیس اونقدرها برای کسی مهم باشه. نظر شما چیه؟

با سلام
از این دیدگاه حق با شماست، اما برخى اوقات امکان داره که بخواهیم از این یکى نبودن تعداد سطرها استفاده کنیم.
مثلاً تصور کنید که جدول A1 جدول اصلى ما باشه و جدول A2 رو از اون جدا کرده باشیم که فقط حاوى سطرهاى غیر NULL ما هست. حالا امکان داره که بنا به شرایط نیاز داشته باشیم که جدول B رو با جدول A2 ارتباط بدیم.
و یا این که Trigger روى جدول A2 داشته باشیم.

در مواردى این‌چنین جدا کردن جدول از نظر من توجیه داره.

صبا صبوحى

[Exception]

ضمن تشکر از همه دوستان، اگر میتونید در مورد صحبتها منبعی هم معرفی کنید، ممنون میشم.

مخصوصا در این موارد:

رابطه یک به یک در متدلوژی هایی معمول و رایجی چون بویس یا بویس-کاد مذمت شده هستند.

فیلدهای Null حجم بسیار بسیار کمی نزدیک به صفر رو اشغال میکنند.

شکستن جدول در حالت 1-1 ممکنه عدم همخوانی ایجاد کنه

باز هم از کمک همه تشکر میکنم.

[AminSobati]

- تفکیک دو جدول فقط موقع Query گرفتن نیست که برای شما یک پردازش اضافی به نام Join به همراه داره، بلکه هنگام ویراش اطلاعات هم نکات خاصش رو باید مد نظر قرار داد. بعنوان نمونه، وقتی قصد دارید یکی از فیلدهایی که در جدول دوم (یا جدول Null ها!) قرار داره رو Update کنید، تنها دستور Update برای شما کفایت نمیکنه و قبلش باید چک کنید آیا رکورد اصلی، در این جدول براش رکورد متناظری وجود داره یا خیر. اگر نه، باید براش Insert بشه و اگر بله، حالا Update قابل انجامه.
- بله Nullها فضای ناچیزی اشغال میکنند و درد سرهای ناشی از دو جدول، ارزشی ندارند. مگر اینکه واقعا موردی خاص باشه که تا به حال من تجربه نکردم.
- اجتناب از Null جزو قوائد نرمال سازی نیست. به عبارت دیگه مراحل نرمال سازی برای کم کردن Nullها در دیتابیس ارائه نشده اند. بلکه شما رو به سمت یک دیتابیس صحیح بر طبق معیارهای Relational Database سوق میده. اگر میبینید توصیه میشه از Null اجتناب کنید، به خاطر برطرف کردن بعضی کارهای اضافی مثل نیاز به استفاده از تابع IsNull و امثالهم هست. اما این هم یک قائده "همیشه درست" تلقی نمیشه. فرضا در بعضی سیستمهای مالی، به خاطر نوع محاسبات مجبور میشیم که از مفهوم Null حتما استفاده کنیم که هیچ مقدار دیگه ای نمیتونه جایگزین اون بشه.