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

[fatima majidi]

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

[veniz2008]

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

[Reza_Yarahmadi]

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

[veniz2008]

البته باید این رو هم در نظر گرفت که فیلدی مثل توضیحات معمولا از نوع رشته ای با حجم تقریبا زیاد در نظر گرفته میشه و وقتی توی هر جدول تعداد کمی از رکوردها ممکنه پر بشه فضای خالی زیادی بین صفحات دیتا قرار میگیره، در این مثال پیشنهاد میشه جدولی جداگانه برای توضیحات در نظر گرفته بشه.
تشکر از پاسخگویی شما ولی یه بحثی وجود داره :
جدول (یا جدول هایی) رو در نظر بگیرید که کلید ترکیبی دارن (مثلا 3 کلیده باشه). حالا همین جدول مثلا 1 میلیون رکورد داره. طبق گفته شما مبنی بر ایجاد یک جدول جدید برای توضیحات، چنین جدولی باید 4 فیلد داشته باشه (3 فیلد کلید برای مشخص شدن رکورد خاص + فیلد توضیحات).
این یعنی 3000000 = 1000000 * 3 فیلد تکراری بیهوده.( این فقط در مورد یک جدول بود حالا شما بقیه جداول رو هم در نظر بگیرید) در صورتیکه اگر داخل هر جدول یک فیلد توضیحات باشه چنین فضایی هدر نمیره.

[fatima majidi]

ممنون از توجه و پاسختون...
اما متوان برای رفع این مشکل یک جدول با 4 ستون ساخت(البته در پروژه ی من) که شامل دو کلید اصلی برای شناسایی توضیح مربوط به هر جدول است + یک ستون تاریخ و یکی هم برای خود توضیح,تا مشکلی که کدام توضیح برای کدام جدول است حل شود. در ضمن نکته این است که من احتیاج به بازیابی اطلاعات با سرعت بالا دارم(برای حجم زیادی از اطلاعات) برای رسیدن به این منظور طبق توضیحات شما, نمی دانم کدام بهتر است اینکه توضیحات را بلاخره در جدولی جدا بگذارم یا نه!!

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

[Reza_Yarahmadi]

تشکر از پاسخگویی شما ولی یه بحثی وجود داره :
جدول (یا جدول هایی) رو در نظر بگیرید که کلید ترکیبی دارن (مثلا 3 کلیده باشه). حالا همین جدول مثلا 1 میلیون رکورد داره. طبق گفته شما مبنی بر ایجاد یک جدول جدید برای توضیحات، چنین جدولی باید 4 فیلد داشته باشه (3 فیلد کلید برای مشخص شدن رکورد خاص + فیلد توضیحات).
این یعنی 3000000 = 1000000 * 3 فیلد تکراری بیهوده.( این فقط در مورد یک جدول بود حالا شما بقیه جداول رو هم در نظر بگیرید) در صورتیکه اگر داخل هر جدول یک فیلد توضیحات باشه چنین فضایی هدر نمیره.
دوست عزیز اول اینکه استفاده از کلید ترکیبی بصورت کل پیشنهاد نمیشه ، اضافه کردن یک فیلد عددی بعنوان ID درسته که داده اضافی محسوب میشه ولی در سرعت پردازش اطلاعات بسیار تاثیر گذاره (در مثال شما)
بعدشم من عرض کردم در مورادی که رکوردهای کمی فیلد توضیحاتشون پر میشه ؛ در این حالت نیازی نیست در جدول دوم (جدول توضیحات) به ازا رکوردی که توضیحات نداره سطری وجود داشته باشه.
در حالت کلی با توجه به اینکه به ندرت پیش میاد برای همه رکورد ها توضیخاتی وجود داشته باشه جدا کردن توضیحات از نظر فضای دیسک مقرون به صرفه تر است ولی در صورتی که تعداد رکوردهایی که توضیحات دارند چشمگیر باشه ، با توجه به اینکه Join دو جدول (جدول اصلی و جدول توضیحات) سربار زیادی درست میکنه قرار دادن فیلد توضیحات درون جدول اصلی مناسب تر است.


اما متوان برای رفع این مشکل یک جدول با 4 ستون ساخت(البته در پروژه ی من) که شامل دو کلید اصلی برای شناسایی توضیح مربوط به هر جدول است + یک ستون تاریخ و یکی هم برای خود توضیح,تا مشکلی که کدام توضیح برای کدام جدول است حل شود. در ضمن نکته این است که من احتیاج به بازیابی اطلاعات با سرعت بالا دارم(برای حجم زیادی از اطلاعات) برای رسیدن به این منظور طبق توضیحات شما, نمی دانم کدام بهتر است اینکه توضیحات را بلاخره در جدولی جدا بگذارم یا نه!!

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

[veniz2008]

دوست عزیز اول اینکه استفاده از کلید ترکیبی بصورت کل پیشنهاد نمیشه ، اضافه کردن یک فیلد عددی بعنوان ID درسته که داده اضافی محسوب میشه ولی در سرعت پردازش اطلاعات بسیار تاثیر گذاره (در مثال شما)
در بعضی موارد ناچاریم که کلید ترکیبی بگیریم (در مواقعی که نمیخوایم که مقادیر یک رکورد تکرار بشن ناچارا" باید از کلید ترکیبی استفاده بشه. مثلا جدول اخذ درس رو در نظر بگیرید: کلید قاعدتا باید حداقل 4 فیلد سال تحصیلی،شماره ترم، شماره دانشجویی، کد درس رو شامل بشه. در چنین حالتی مجبوریم که کلید ترکیبی در نظر بگیریم تا از ثبت تکراری یک درس در یک سال و ترم تحصیلی توسط دانشجو جلوگیری بشه). ولی اگر بتونیم تک کلید بگیریم ( و البته از نوع int) به مراتب بهتر و کاراتر خواهد بود.

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

[Reza_Yarahmadi]

در بعضی موارد ناچاریم که کلید ترکیبی بگیریم (در مواقعی که نمیخوایم که مقادیر یک رکورد تکرار بشن ناچارا" باید از کلید ترکیبی استفاده بشه. مثلا جدول اخذ درس رو در نظر بگیرید: کلید قاعدتا باید حداقل 4 فیلد سال تحصیلی،شماره ترم، شماره دانشجویی، کد درس رو شامل بشه. در چنین حالتی مجبوریم که کلید ترکیبی در نظر بگیریم تا از ثبت تکراری یک درس در یک سال و ترم تحصیلی توسط دانشجو جلوگیری بشه).
در مثال شما نیازی به کلید ترکیبی نیست! شما میتونید 4 فیلد مورد نظرتون رو Unique کنید و از یک فیلد Identity بعنوان کلید استفاده کنید.

[baktash.n81@gmail.com]

سلام

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

[veniz2008]

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


در مثال شما نیازی به کلید ترکیبی نیست! شما میتونید 4 فیلد مورد نظرتون رو Unique کنید و از یک فیلد Identity بعنوان کلید استفاده کنید.
حق با شماست. ولی در هنگام اخذ دروس باز هم مجبوریم که از اون 4 فیلد استفاده کنیم تا درس تکراری ثبت نشه. آیا کلید بودن اون 4 فیلد با یونیک بودن اون فرقی داره؟. (تو کتاب آقای Robin Dewson خوندم که گفته بودن اگر ایندکس ها به 4 یا 5 رسید باید در اون ستون ها با شک و تردید نگاه کرد، یعنی توصیه نمیکنن که 4 یا بیشتر از 4 فیلد ایندکس( با یا بدون قابلیت یونیک) داشته باشیم). اون Identity که فرمایش کردید به چه دردی میخوره و کجا میتونه کاربرد داشته باشه؟

[Reza_Yarahmadi]

یه سوال اینجا مطرح میشه و اونم اینه که تعداد رکورد کمی که توضیحات دارند یعنی چقدر؟. آیا فرمول یا معیار خاصی برای این کار داریم؟ (مثلا در یک جدول با 1 میلیون رکورد چه میزان رکورد اگر توضیحات نداشته باشن بهتره که از روش شما استفاده بشه؟)توضیح داده شده برای یک جدول نیست ، برای چندین جدول دارای فیلد توضیحات است. معیار خاصی وجود ندارد بر اساس
- تعداد رکوردهای جدول اصلی و جدول توضیحات
- مشخصات سخت افزاری سرور
- تعداد یوزر استفاده کننده از سرور
- تعداد دفعات ارجاع بع جدول توضیحات
- ...
این موضوع مورد بررسی قرار میگیره .
برای مثال شما در صورت وجود حداقل 5 جدول با شرایط مذکور و شرایط متعادل ، تعداد توضیحات هر جدول بیشتر از 10% تعداد کل نباشه.


ولی در هنگام اخذ دروس باز هم مجبوریم که از اون 4 فیلد استفاده کنیم تا درس تکراری ثبت نشه. آیا کلید بودن اون 4 فیلد با یونیک بودن اون فرقی داره؟. (تو کتاب آقای Robin Dewson خوندم که گفته بودن اگر ایندکس ها به 4 یا 5 رسید باید در اون ستون ها با شک و تردید نگاه کرد، یعنی توصیه نمیکنن که 4 یا بیشتر از 4 فیلد ایندکس( با یا بدون قابلیت یونیک) داشته باشیم). اون Identity که فرمایش کردید به چه دردی میخوره و کجا میتونه کاربرد داشته باشه؟
وقتی شما از کلید ترکیبی استفاده میکنید یک ایندکس یونیک ترکیبی روی فیلد های مورد نظر ایجاد میشه. در مورد کلید ترکیبی هم قبلا عرض کردم توصیه نمیشه.
فیلد Identity برای ایجاد رابطه با جداول Detail (در صورت نیاز)