مشکل در طراحی دیتا بیس (حرفه ای ها بیان)

[didaaa]

سلام:
دوستان من در حال طراحی یک table هستم ولی یک مشکل اساسی بر خوردم اگه میشه خواهشا کمکم کنید!
من داخل جدولم فیلدی دارم که اگه کاربر بخواد داخلش رو پر کنه لاجرم چند مقدارو میبایست وارد کنه.
مثلا: اگر فیلد مورد نظر به این صورت باشه!

1-نام پدر در قید حیات است؟
بله!
1-2درصورت زنده بودن مشخصات پدر:
نام:
سن:
.....
1-3 نو شغل: کارمند،کارگر،کاسب.....
فکر کنم با تصویر زیر براتون قابل فهم باشه
یک بار دیگه میگم به نظر شما من باید چیکار کنم؟ زمانی که میخوام داخل یک فیلد چند مقدار قرار بدم میدونم که نمیشه ولی میخوام بدونم ایاتید در چنین مواقعی چیکار می کنند.

[ASKaffash]

سلام
میخواهی این کنترلها در لایه بانک اطلاعاتی اتفاق بیافتد ؟ یا در لایه برنامه کاربردی خودتان ؟

[didaaa]

ببین دوست من فقط میخوام یه طرح خوب از این خواستم پیاده کنم، میخوام بدونم چطور داخل فیلدی که هم میتونه یک مقدار بگیره (یعنی خیر) و هم چند مقدار(که در اینصورت Multi select میشه) بگیره طراحی کنم؟ ایا باید اطلاعات جدول اصلی داخل چند جدول ذخیره بشه؟(اگه اره چطور) راستش بهتر از این سوالمو نمیتونم بپرسم.

[sia_2007]

این تو Application خیلی راحت تر پیاده سازی میشه تا تو بانک

[ASKaffash]

سلام
خوب به نظر من برای انجام اینکار نیاز به حداقل دو جدول دارید :
جدول اول شامل سایر فیلدهای مورد نظر و فیلد حالت وضعیت شرطی( اینجا قید حیات بودن) به همراه یک کلید
جدول دوم FK به همراه سایر فیلدها مثل نوع شغل و ....
ولی اگر میخواهید در لایه بانک مواظب حالت وضعیت باشد سه راه دارید :
- کنترل در لایه برنامه کاربردی
- کنترل در لایه بانک با قید Check
- کنترل در لایه بانک بوسیله trigger

[Hamid.Kad]

اگر من جای شما باشم 3 تا جدول طراحی میکنم:
1- جدول اصلی که در حقیقت توی شکلتون در بالای همه قرار داشت. اسم این جدول رو میذارم MainTable

2- جدول اطلاعات پدر افراد که شامل فیلدهای "کد پرسنل" (در جدول MainTable هم وجود داشت)، نام ، تحصیلات، سن باشه. اسم این جدول رو FatherName میذاریم

3- البته من درست متوجه نشدم که آیا پدر میتونه همزمان چندتا شغل داشته باشه یا اینکه فقط یکی از مشاغلی رو که در شکل نشون دادید میتونه داشته باشه. اگر حالت دوم درسته میتونید به جدول FatherName یک فیلد شغل هم اضافه کنید. اگر میتونه همزمان چند تا شغل داشته باشه یه جدول دیگه طراحی میکنید که شامل فبلدهای "کد پرسنل"، و "شغل" باشه. مجموع این دو تا فیلد کلید اصلی این جدول رو تشکیل می دهند
راههای چک کردن رو هم که جناب کفاش توضیح داده اند...

مشکل در طراحی دیتا بیس (حرفه ای ها بیان)
دوست عزیز، استفاده از این ادبیات برای طرح سوال چندان مناسب نیست.

[bad_boy_2007]

نظرات جناب Hamid.Kad تایید میشه ولی همیشه من بر یک نکته بسیار تاکید دارم ، کدهایی مشابه با کد پرسنلی حتی الامکان به عنوان کلید اصلی جداول انتخاب نشوند.



یه جدول دیگه طراحی میکنید که شامل فبلدهای "کد پرسنل"، و "شغل" باشه. مجموع این دو تا فیلد کلید اصلی این جدول رو تشکیل می دهند


دلیل گفته فوق را بدین شکل مطرح میکنم که :

1- اینگونه کدها عموما طولانی هستند و منجر به :

الف ) افزونگی در داده های : جداول مرتبط با این جدول میشوند (مثلا اگر کد پرسنلی کاربر صادر کننده فاکتور از نوع NChar(10) باشد این کد 20 بایت ولی اگر از کلید کاندید از نوع Smallit استفاده کنیم فقط 2 بایت فضا اشغال میکنه ، حالا فکرشو بکنید که قراره این کاربر تعداد زیادی فاکتور بزنه)

ب ) کم شدن سرعت الحاق (Join) : همانگونه که میدانید در الحاق جداول (که تقریبا برنامه را نمیتوان یافت که عملیات الحاق را انجام ندهد) الحاق جداول با کلید های رابطه ای کوتاه تر سریع تر از الحاق همان جداول با کلید خارجی طولانی است
2- انعطاف پذیری داده های ذخیره شده را کاهش میدهد

فرض کنید ارگان شما بنا به دلایلی نیاز میبیند که کدهای پرسنلی را تغییر دهد ، مثلا رئیس شرکت تصمیم میگیرد کدها را با ساختاری اصلاح کند که کدهایی که با 1 شروع میشوند فروشنده ها ، کدهایی که با 2 شروع میشوند مدیران ارشد و ....
با این شیوه کد گذاری فقط با استفاده از تغییرات Cascading این کار امکان پذیر است که این روش به هیچ عنوان توصیه نمیشود ، جدای از مشکلات احتمالی که این تغییرات ممکن است در داده ها ایجاد کنند . مثلا یکی از این مشکلات میتواند این باشد که فراموش کرده باشید که ارتباط از طریق کلید خارجی این جدول را با یکی از جداول پایگاه داده ایجاد کرده باشید ، به این شکل کد های کاربری در این جدول غیر قابل اعتبار میشوند .
پیشنهاد من ایجاد ایندکس Unique بر روی کد پرسنلی و استفاده از کلید اصلی نوع Int (4 بایتی یعنی تا حدود چند میلیون) یا Smallint (2 بایتی تا حدود 30 هزار) بر روی این جداول است ، میتوانید این فیلد را AutoNumber کنید .

[Marzieh_A]

از دو تا جدول استفاده کن.
جدول اول که همون جدولی هست که فیلد نام پدر رو داره (که به احتمال زیاد جدول اطلاعات کاربری هست).
و جدول دوم رو جدول مشخصات پدر قرار بده.
جدول دوم باید به تعداد مشخصاتی که می خوای برای پدر در نظر بگیری بعلاوۀ یک (که همون کلید اصلی ما هست و کلید خارجیش رو در جدوا اول قرار میدی) ستون داشته باشه. که این ستون ها جز کلید اصلی و حالت در قید حیات بودن می تونن null باشن.
بعد از طریق برنامه ای که داری می نویسی مقداری که می خوای به این جدول وارد کنی رو تحت کنترل می گیری.
مثلا تو فرمی که برای ورود اطلاعات کاربر قرار دادی، وارد کردن نام پدر و حالت در قید حیات بودن رو اجباری می کنی.
بعد اگر برای حالت در قید حیات، خیر رو انتخاب کرد بقیۀ قسمتهای فرم که مربوط به اطلاعات پدر هست رو غیرفعال می کنی و در جدول مربوط به اطلاعات پدر فقط حالت در قید حیات بودن رو خیر قرار می دی و بقیۀ فیلد ها رو null قرار می دی.
اگر هم برای حالت در قید حیات بودن، بلی رو انتخاب کرد ورود بقیۀ اطلاعات پدر رو اجباری می کنی و بعد هم در جدول قرار میدی.
در مورد کلید اصلی هم بهتره که یه id قرار بدی که AutoNumber یا AutoIncrement باشه.
که برای اولی از نوع AutoNumber استفاده می کنی و برای دومی از نوع int استفاده می کنی و identity specification رو اونجوری که می خوای تنظیم می کنی.

[Hamid.Kad]

کدهایی مشابه با کد پرسنلی حتی الامکان به عنوان کلید اصلی جداول انتخاب نشوند.
با اینکه من هم موافقم ولی دلایل شما برای این موضوع اشتباهه. بخاطر موارد زیر:

الف ) افزونگی در داده های : جداول
دوست عزیز.اون فیلدهایی که توی جدول قرار داده شده اند در هر صورت باید باشند و انتخاب یک فیلد دیگه بعنوان کلید باعث نمیشه که این فیلدها حذف بشوند. در نتیجه افزونگی داده ها بیشتر خواهد شد که صد البته این افزونگی از نوع تکنیکی و قابل تحمل است

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

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

یکی از این مشکلات میتواند این باشد که فراموش کرده باشید که ارتباط از طریق کلید خارجی این جدول را با یکی از جداول پایگاه داده ایجاد کرده باشید ، به این شکل کد های کاربری در این جدول غیر قابل اعتبار میشوند
اینجا قراره که ایشون رو برای یک طراحی مناسب راهنمایی کنیم. پس نمیتونیم بگیم که کاربر فراموش کرده و ...
مثل این میمونه که بگیم استفاده از یک تریگر برای عمل log کردن مناسب نیست و مثلاً Insert دستی بهتره. چون ممکنه کاربر فراموش کرده باشه یا بلد نباشه و ...