بنظر شما کدام روش ، روش بهینه تری میتواند باشد.

[mahan.2002]

با سلام

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


1- ساخت یک جدول دیگر به نام مدرک که دارای 2 فیلد کد و نام مدرک می باشد و ارتباط آنها به جدول کارمندان(کلید خارجی)

2-در جدول کارمندان فیلدی به نام مدرک قرار دهیم و برای هر کارمند نوع مدرک را به صورت رشته (دیپلم ...) ذخیره کنیم.

3.استفاده از کدهای قراردادی که عدد 1 به معنای لیسانس و عدد 2 به معنای دکترا و ... که یک فیلد در همان جدول کارمندان می باشد.

[mehran_sh_t]

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

نظر من:

شما چه تعداد کارمند دارید؟ 10000 مثلا!
برای فیلد مدرک، اگر 50 کاراکتر هم در نظر بگیرید، نهایتا 500 kb میشه! از نظر فضا، فکر نکنم زیاد باشه...

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

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

[mahan.2002]

ممنون

منظورم کلی بود شاید مثال مناسبی تری به زهنم نرسیده بود حال نه حتما مدرک به عنوان مثال شما میخواهید نام روزهای هفته ( شنبه ، یکشنبه ، ...، جمعه ) را در دیتا بیس ذخیره کنید که این دیتا بیس روزانه تعداد بالایی از رکورد که هر رکورد باید در فیلد "روز " نام روز های هفته در خود ذخیره کند.

[یوسف زالی]

سلام.
در مورد مثالتون در هر دو مورد گرفتن جدول استاندارد و بهتره.
این به فضا اصلا مرتبط نیست. بگذارید کمی حساب کتاب کنبم:

روش اول: گرفتن فیلدی با طول X بایت برای نام مدرک
----------------------------------------------------------
تعداد فیلد های اضافه شده = 1 فیلد
تعداد بایت های اضافه شده = به ازای هر ردیف حداکثر X بایت
تعداد جداول اضافه شده = 0 جدول

روش دوم: گرفتن جدول مستقل که دارای فیلدی به طول X بایت است
---------------------------------------------------------------------------
تعداد فیلد های اضافه شده به جدول اصلی = 1 فیلد از نوع عدد
تعداد بایت های اضافه شده = 2 بایت برای ارتباط جدول اصلی از نوع عدد + حداکثر X بایت در جدول مقصد + 2 بایت برای سریال جدول مقصد
تعداد جداول اضافه شده = 1 جدول

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

به ازای where , having , order by و البته ارسال پارامتر برای فیلترینگ خروجی به پردازش آرایه ای از کاراکتر ها نیاز هست که X بایته.
این در حالیه که where , having , order by و ارسال پارامتر عددی که فقط 2 بایته سریع تر عمل می کنه.

همون مدارک رو فرض بگیریم. (بی سواد - زیر دیپلم - دیپلم - کاردانی - کارشناسی - کارشناسی ارشد - دکترا - فوق تخصص)
تعداد X رو 15 بگیریم. (به فرض ست بودن Collation روی فارسی. در غیر این صورت دو برابر)
می خواهیم ببینیم چه کسانی کارشناسی دارند.

روش اول
----------
'کارشناسی' = select * from TBL where D

انتقال رشته به کوئری = 15 بایت
بدترین حالت پردازش برای تشخیص where ، تعداد 9 پردازش (برای تشخیص از کارشناسی ارشد)
بهترین حالت تعداد 1 پردازش (مثلا دکترا)

روش دوم
----------
select * from (select * from Madrak where ID = 5)A join TBL on ID = FID

انتقال عدد به کوئری = 2 بایت
بدترین حالت = 1 مقایسه (از نوع عدد هست)
بهترین حالت = 1 مقایسه

دقت کنید که جداول کوچکتر زودتر باید join شن تا سرعت بالاتر بره (این قضیه اثبات علمی داره)

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

تمام این ها به من می گه روش دوم روش اصولی و بهتری هست.

[crazy_1892]

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

نظر من:

شما چه تعداد کارمند دارید؟ 10000 مثلا!
برای فیلد مدرک، اگر 50 کاراکتر هم در نظر بگیرید، نهایتا 500 kb میشه! از نظر فضا، فکر نکنم زیاد باشه...

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

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

دوست عزیز منم این روش را پیشنهاد مکنم چون در گزارش گیری هم راحتری

[mehran_sh_t]

تمام این ها به من می گه روش دوم روش اصولی و بهتری هست.

یا من به کل اشتباه فهمیدم، یا شما اشتباه تایپی داشتید، و منظورتون روش اول بود. ؟

فکر کنم با توضیحات شما، منظورتون از روش بهینه، روش اول هستش.

[یوسف زالی]

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

نظر من دومی هست.
روش اول اصلا اصولی و صحیح نیست.
یک توصیه در اس کیو ال: هرگز سرعت را فدای سادگی نکنید.
یکی دیگه(!) : هرگز به خودتون نگید پروژه همینه و توسعه نداره. مگر پروژه های بزن در روی دانشجویی.

[mehran_sh_t]

با عرض پوزش...

من فکر کردم منظورتون از روش اول، روش اول در پست mahan.2002 هستش، نه پست شما!!!

[Galawij]

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

[baktash.n81@gmail.com]

سلام

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