ارتباط یک به یک

[rostamedastan]

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

[AminSobati]

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

[whitehat]

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

[rostamedastan]

هنگام درست کردن جدول پرسنلی مشخصاتی که از آنها بعدا گزارش می گیرم (اطلاعات اصلی) را در یک جدول و سایر اطلاعات (اطلاعات فرعی که معمولا در گزارشات نمی آید) را در جدول دیگه ثبت می کنم تا درصورتی که لازم شد با این جدول Join کنم
یعنی بین دو جدول ارتباطی برقرار نمی کنید؟

2- من دو جدول دارم که یکی اطلاعات مربوط به تشکیل پرونده سربازان است و دیگری اطلاعات مربوط به کارت پایان خدمت است در جدول اول نام خانوادگی و شماره شناسنامه کلید اصلی است و در جدول دوم شماره کارت اما چون هر سرباز بعد از تشکیل پرونده تنها یکبار کارت در یافت می کند ارتباط آنها یک به یک است پس مجبور شدم آنها را باهم ادغام کنم ولی مشکل دیگری که دارم شماره کارت نباید تکرار شود ولی هنگامیکه ادغام کردم چون باید نام خانوادگی و شماره شناسنامه را به عنوان کلید اصلی در نظر بگیرم پس امکان تکرار شماره کارت وجود دارد. چه بکنم؟

[zerobit-ltd]

چرا کلید اصلی رو ترکیبی گرفتید؟

[rostamedastan]

غیر از این کلید دیگری نداریم مگر کد پرسنلی که آن را هم نمی توان گذاشت چون کدی وجود ندارد.

[zerobit-ltd]

غیر از این کلید دیگری نداریم مگر کد پرسنلی که آن را هم نمی توان گذاشت چون کدی وجود ندارد.
خوب چرا یه فیلد identity نمی گیرید و موقع ثبت اطلاعات نام و نام خانوادگی و شماره شناسنامه رو چک نمی کنید که تکراری نباشن؟

[AminSobati]

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

[whitehat]

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

یعنی بین دو جدول ارتباطی برقرار نمی کنید؟

مگه میشه ارتباطی نباشه ، بالاخره Join بر اساس کلیدی باید انجام بشه

غیر از این کلید دیگری نداریم مگر کد پرسنلی که آن را هم نمی توان گذاشت چون کدی وجود ندارد.
شما نمی توانید از کد ملی به عنوان کلید استفاده کنید، در پروژه ای که انجام دادیم مجبور شدیم از این روش استفاده کنیم

[SabaSabouhi]

با سلام
پیش‌نهاد مى‌کنم که کلید رو از فیلدهاى اطلاعاتى نگیرید یک کلید به صورت Identity بگیرید و اطلاعاتى رو که مطمئن هستید تکرار نخواهند شد رو به صورت یک Index Unique تعریف کنید.
حتا کد ملى هم مى‌تونه تکرارى باشه (با کمال شرمندگى براى طراحان سیستم ... این مورد هم مثل تکرارى در آمدن پلاک ملى دیده شده)
در مورد یکى کردن جدول‌ها هم به نظر من اگه جدول دوم از نظر تعدد سطر با جدول اول یکى نیست لزومى نداره.
یعنى اگه فقط به ازاى برخى از سطرهاى جدول اول در جدول دوم اطلاعات دارید به‌تره که دو جدول رو یکى نکنید و از همون Join استفاده کنید، چون در غیر این صورت باید ستون‌هاى مربوط به جدول دوم رو Null بگیرید.

صبا صبوحى

[whitehat]

حتا کد ملى هم مى‌تونه تکرارى باشه (با کمال شرمندگى براى طراحان سیستم ... این مورد هم مثل تکرارى در آمدن پلاک ملى دیده شده)
شما با این مسئله برخورد کردید؟ با این حساب باید حتما از یک فیلد Identity استفاده کرد ، اما جستجوی رکورد تکراری در هنگام درج رکورد جدید بسیار سخت خواهد شد :(