بررسي ساخت تيبل جداگانه براي مقادير يه فيلد خاص

[Payman62]

سلام.

يه ديتابيس نسبتا بزرگ رو در نظر بگيرید که تعداد زيادي رکورد در تيبل هاش ذخيره ميشه.
يه تيبل به نام info داريم که اطلاعات اشخاص داخلش ثبت ميشه. فيلدهايي به نام نام و فاميلي و تاريخ تولد و شهر تولد و موبايل و آدرس داخلش هست.
خوب طبيعتا براي فيلدهايي مثل آدرس و موبايل که مقادير متغير دارن يه فيلد ثابت در نظر گرفته ميشه.
ولي براي فيلدي مثل شهر تولد که مقادير تکراري داره يه تيبل جديد به نام city ايجاد مکنيم و اسم شهرها رو داخلش وارد ميکنيم و با کليد خارجي به تيبل info وصل ميکنيم.

حالا سوالم اينه آيا به نظرتون منطقيه براي فيلدي مثل نام هم همين کار رو بکنيم؟
فرض کنيد چندين ميليون رکورد ذخيره خواهد شد. مگه کلا چند تا اسم داريم؟ 500 تا که بيشتر نيست. خوب ميشه اين 500 اسم رو در يه تيبل ديگه ذخيره کرد و به تيبل اصلي وصل کرد. به نظرتون منطقيه اين کار؟

در مورد فيلد تاريخ تولد چطور؟ اين فيلد اعدادي بين 1300 تا 1400 ميگيره. 100 تا عدد هم کمتر حتي. منطقي هست براش يه تيبل ديگه طراحي کنيم؟

[far_222000]

سلام پیمان جان

ببین برای تاریخ که اصلاً منطقی نیست! شما هر بار که از دیتابیس SELECT میگیری، باید با اون کلید خارجی از یه تیبل دیگه اطلاعات رو بگیره که این کار اصلاً اصولی نیست(چون تعدادش فقط 100 تاست!)

در مورد نام هم فکر می کنم همینطور باشه! ولی نام رو مطمئن نیستم

[Payman62]

سلام.
خوب چون تعدادش پایینه میگم تیبل خارجی بذاریم. که بی دلیل حجم دیتابیس برای 100 تا رکورد بالا نره. دیتابیسی که ممکنه چند میلیون رکورد داشته باشه.

[Di Di]

به نظر من منطقی نیست چون اولا باید نه 500 تا بلکه 2000 تا اسم رو از ابتدا وارد کنید و در آخر باز هم یکی پیدا

می شه که می بینی اسمش تو لیست نیست، اونوقت باید برای این جور موارد فرمی و قسمتی هم برای ورود نام های

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

گذشته از اون انتخاب نام از یک لیست هم سختی های خاص خودش رو داره مثلا اسامی چند بخشی رو معمولا به چندین

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

لیست سخت تر از وارد کردن اونه

داخل برنامه هر جا می خوای حتی ساده ترین لیست از مشخصات افراد رو هم بیاری باید یه اینرجوین بین این دوتا جدول بزنی

که در طول برنامه ممنه صدها بار این تکه کد اضافی رو تکرار کنی و یه بار اضافه روی SQL بزاری ( هرچند خیلی کم)

حالا پی همه اینها رو هم به تنت مالیدی و کلی وقت واسه ساخت فرم های اضافی و روتین های آسون کردن انتخاب نام از

لیست و .... صرف کردی برای چی؟ برای اینکه به جای یه فیلد از نوع استرینگ با طول نهایتا 16 کاراکتر ، فیلدی عددی قرار بدی؟

به نظر خودت منطقیه؟

[Payman62]

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

اما بحث این که آیا ارزشش رو داره یا نه بحث ماست.
همون طور که گفتی کد پیچیده تر و کلی جوین و بار اضافی کد نویسی به برنامه نویس وارد میشه.

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

[Di Di]

خوب دیگه به نظر من ارزشش رو نداره، خیلی جاه های دیگه در دیتابیس هست که می شه با طراحی بهینه

برنامه در تعداد فیلدها و تیبل ها صرفه جویی کرد که باید متناسب با کارکرد برنامه باشه