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

[Payman62]

سلام.

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

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

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

[Galawij]

سلام.

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

فرض کنید چندین میلیون رکورد ذخیره خواهد شد. مگه کلا چند تا اسم داریم؟ 500 تا که بیشتر نیست. خوب میشه این 500 اسم رو در یه تیبل دیگه ذخیره کرد و به تیبل اصلی وصل کرد. به نظرتون منطقیه این کار؟
مگر برای هر شخصی، اطلاعات خاص خودش(تاریخ تولد و شهر تولد و موبایل و آدرس) را ندارید. پس فکر نمی کنم رکورد تکراری در جدول داشته باشید. مگر اینکه ساختار جداول شما فرق داشته باشه!

در مورد فیلد تاریخ تولد چطور؟ این فیلد اعدادی بین 1300 تا 1400 میگیره. 100 تا عدد هم کمتر حتی. منطقی هست براش یه تیبل دیگه طراحی کنیم؟
معمولاً تاریخ را با ساختار سال و ماه و روز ذخیره می کنند. شما فقط سال را نگهداری می کنید که به نظر من جدول دیگری نمی خواهد چون همان نوع داده ای را که به عنوان کلید خارجی وارد این جدول می کنید، می تونید به جای کلید خارجی همان نوع داده را داشته باشد بدون جدول اضافه.

[Payman62]

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


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



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

دوستان دیگه هم لطفا نظر بدن.

[Galawij]

در تیبل info نام افراد میتونه تکراری باشه و حجم رو بالا میبره
پس تحلیل جداولتون اشتباه است.

[Payman62]

پس تحلیل جداولتون اشتباه است.

سلام.
متوجه منظورتون نشدم.

[Galawij]

شما اگر یک جدول برای مشخصات اشخاص دارید پس چرا تکرار رخ می دهد مگر برای هر شخصی مشخصات خاص خودش (تاریخ تولد و شهر تولد و موبایل و آدرس) را ندارید؟

[Payman62]

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

دوستان دیگر هم لطفا نظر بدین.

[Galawij]

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

[Payman62]

سلام.
اسامی اشخاص ثابت نیست؟ مگه کلا چند تا اسم داریم؟ بالا که توضیح دادم.
برای نهایتا 500 تا اسم 1 فیلد ثابت در چندین میلیون رکورد در نظر بگیریم؟ در تعداد بالا حجم دیتابیس رو میبره بالا.

ضمنا لزومی نداره کاربر به فرم جدا برای وارد کردن نام رجوع کنه. میتونیم تو لایه business چک کنیم اگه نام موجود نبود اول نام رو در تیبل دیگه ثبت کنه و بعد رکورد اصلی در تیبل info ثبت بشه.

[یوسف زالی]

سلام.
من جواب این پست رو دادم اما نمی دونم چرا نیست!
در مورد اینکه برای اسامی یک جدول جداگانه در نظر بگیرید اشکالی که وجود داره اینه که معمولا این داده باید در تمام گزارشات مربوط به این جدول join شه و همین یعنی کندتر.
من به شخصه ترجیح می دم از این روش استفاده نکنم.
حجم یک دیتابیس چقدر برای شما مهمه؟ آیا به قیمت کارایی کمتر - کدنویسی بیشتر - نگهداری سخت تر؟
برای یک insert باید درگیر یک جدول اضافی شد. برای سایر دستکاری ها همچنین.

در مورد دوم هم درسته که 100 سال در بازه وجود داره اما هر سال هم 365 روز داره که میشه 36500 روز تولد متفاوت نه 100 تا.
اگر قرار باشه یک جدول مجزا براش در نظر بگیرید و تاریخ ها رو به فرم عدد ذخیره کنید باز هم نیاز به یک ستون برای نگهداری این ارتباط دارید که اون هم عدده. یعنی نه فقط یک جدول اضافی میشه بلکه حجم بیشتری هم خواهید داشت. در مورد اینکه ذخیره تاریخ ها به فرم عددی نباشه هم به روش مشابه میشه همین رو گفت. مقدار کمی ممکنه ذخیره فضا داشته باشید اما باز هم مستر - دیتیل..

به صرف اینکه بتونید نام رو ثابت در نظر بگیرید دلیل بر طراحی اشتباه شما نمی شه.

امبدوارم تونسته باشم کمک کرده باشم.

[Payman62]

سلام.

در مورد نام سوال من همینه که فرمودی. آیا صرفه جویی در فضایی که به دست میاریم به کند تر شدن برنامه و کد نویسی مشکل تر میرزه یا نه؟
شاید برنامه خیلی کند تر نشه. اما فضایی زیادی به دست بیاریم.

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

[یوسف زالی]

سلام.
در رابطه با تاریخ با شرایط شما قطعا فقط باعث اضافه بار بدون رسیدن به هیچ دستاوردی خواهد شد.
و در مورد اسامی هم هر کسی بسته به نیازش دو دو تا می کنه .
تا به حال برای من حجم کم اولویت بالاتری به بقیه نداشته.
مثلا برای یک میلیون رکورد با نام هایی به طول 20 کاراکتر 20 مگابایت اصلا رقمی در دنیای دیتابیس محسوب نمی شه. (یونیکد باشه 40 مگ)
اون هم برای دیتابیسی با این همه رکورد.
اما اگر اصرار به این کار دارید هیچ اشکالی نداره. در کل من ندیدم که کسی این روش رو انتخاب کنه.

[Payman62]

سلام.
نه اصراری نیست.
دارم سوال میپرسم تا دوستان نظر بدن و مساله کارشناسی بشه و در آینده دیتابیس ها رو به بهترین شکل طراحی کنیم.

خوب من بعضی مواقع دیدم که افرادی روی کاهش حجم تاکید زیادی دارن.

در مورد کند شدن در اثر استفاده از این روش تا چه حد تاثیر گذار هست؟ قابل ملاحظه هست؟

[یوسف زالی]

نه. کندی پیش میاد اما تقریبا محسوس نخواهد بود.
مشکل سر دردسرش هست.
کد نویسی ها ، تریگر ها ، کنترل ها ، گزارش ها...