گذاشتن یک جدول برای مطالب تقریبا مشابه با فیلد type یا چند جدول بهینه تره؟

[H:Shojaei]

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

[id1385]

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

[H:Shojaei]

در کل منظورتون رو نفهمیدم! نگرفتم چی شد...
ببینید منظور من وقتیه که مثلا ما یک مطلب داریم و کامنتهای مطلب، مطلب و کامنتهاش هردو یک آی دی دارن و یک متن همین الآن هم مطلب و هم کامنتها رو میشه توی یک جدول گذاشت و فقط یک فیلد parent قرار داد که اگر اون 0 بود مطلبه اگر نه که کامنته و parent هم id مطلبی هست که این کامنت واسه اونه...
از جهتی هم میشه یک جدول کامنتها داشته باشیم و یک جدول مطالب...

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

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

حالا با این تفاصیل چطور بهتره انجام بشه این کار!؟

[Mohammadsgh]

اگه رکوردهاتون زیاد هستن بهتره یک جدول جدا داشته باشید و هنگام واکشی از join استفاده کنید اگر هم کمه با یک جدول مشکلی نداره

[H:Shojaei]

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

[Master_Power]

میتونید همه را توی یه جدول بزارید و با دستورLIMIT تعداد نمایش را محدود کنید و از Pagination برای نمایش بقیه رکوردها استفاده کنید

[us1234]

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

با تجربه شخصی و کار با دیتاها بزرگ به این نتیجه رسیدم ...

[H:Shojaei]

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

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

[Unique]

به نظر من یستگی به type ی که شما تعریف میکنید داره. خودش به شخصه زمانی از مثال type شما استفاده میکنم که این type لازم نشه برای انوع مختلف توی جدول فیلد های مختلف داشته باشم ! مثلا در مورد comment و topic که گفتین فقط وقتی از یک جدول استفاده میکنم که فیلد های comment و topic با هم تفاوتی نداشته باشن نه اینکه یکسری مختص به topic یا مختص به comment باشن. مسلما استفاده از یک جدول جم و جور خیلی بهتره.

[H:Shojaei]

به نظر من یستگی به type ی که شما تعریف میکنید داره. خودش به شخصه زمانی از مثال type شما استفاده میکنم که این type لازم نشه برای انوع مختلف توی جدول فیلد های مختلف داشته باشم ! مثلا در مورد comment و topic که گفتین فقط وقتی از یک جدول استفاده میکنم که فیلد های comment و topic با هم تفاوتی نداشته باشن نه اینکه یکسری مختص به topic یا مختص به comment باشن. مسلما استفاده از یک جدول جم و جور خیلی بهتره.

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

[rezaonline.net]

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

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

درست هست که اینها صفات مشابه دارند اما میبنید این صفات ربطی به هم ندارند پس این موجودیت ها در دو جدول جداگانه باید قرار بگیرد .


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

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

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

حتی در رکوردهای بالا ، میایند یک جدول را پارتیشن بندی میکنند براساس کلید ، که تبدیل شود به چند جدول که سریعتر باشد :)


پس شما سعی کنید برای هر موجودیت یک جدول تعریف کنید ، سعی کنید از تعریف فیلدهای بیخودی پرهیز کنید .
از روش id1385 (http://barnamenevis.org/member.php?79574-id1385) برای موجودیت هایی که تعداد صفات نامشخص دارند استفاده کنید

موفق باشید

[H:Shojaei]

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

ماشالا به حافظه من خودمم یادمه تحصیلات آکادمیک رو زیر سوال بردم اما یادم نیست کی و کجا شما خوب یادتون مونده ها :D
و البته بنده این درس رو پاس کردم و مثل همه درسهای دیگه که تخصصی بود 19 20 گرفتم و میبینید الآن این سوال رو پرسیدم تحصیلات آکادمیکی که بیش از select توش نگن همین میشه دیگه نمیدونم تو چه دانشگاهی درس خوندید ولی جاهایی که من خوندم که جزء بهترین های مشهد شهر خودم هم بوده تعریفی نداشته بازم میگم آدم باید خودش بره دنبال اینطور چیزا دانشگاه....



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

درست هست که اینها صفات مشابه دارند اما میبنید این صفات ربطی به هم ندارند پس این موجودیت ها در دو جدول جداگانه باید قرار بگیرد .

در این رابطه من هم همین فکر رو میکردم الآن هم پروژه هام به این صورت انجام شده دلیل این شکم این بود که گاها توصیه میشد اطلاعاتی که به شکل هم هستن بیان توی یک جدول قرار بگیره... مثلا منو های درختی یا همون treeview که این کلاس کلا یک جدول داره البته باید همینطور باشه ولی اگر سطر های ما مثلا قرار باشه 4 سطر باشه نه بیستر و نه کمتر به نظر من جدول جدا بهتره...



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

بله کاملا درسته...


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

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

حتی در رکوردهای بالا ، میایند یک جدول را پارتیشن بندی میکنند براساس کلید ، که تبدیل شود به چند جدول که سریعتر باشد :)

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


پس شما سعی کنید برای هر موجودیت یک جدول تعریف کنید ، سعی کنید از تعریف فیلدهای بیخودی پرهیز کنید .
از روش id1385 (http://barnamenevis.org/member.php?79574-id1385) برای موجودیت هایی که تعداد صفات نامشخص دارند استفاده کنید

موفق باشید
هنوز که منظور ایشون رو کامل متوجه نشدم!

ممنون جواب خوبی دادین دارم کم کم انواع جدول بندی رو درک میکنم...

[H:Shojaei]

دوستان من الآن یکم دودل شدم!
فرض کنید کل مطالب که 20 تالار هست مثلا 1 میلیارد باشه...
بهتره که 20 جدول 50 میلیون رکوردی داشته باشیم یا یک جدول 1 میلیارد رکوردی؟

[Mohammadsgh]

هم من هم آقای rezaonline توضیح دادیم.برای کارتون جدول جدا باشه بهتره.اگر اشتباه نکنم یکی از اصول نرمال سازی هم همینه

[H:Shojaei]

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

[Mohammadsgh]

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

[us1234]

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

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

شما به هر 2 روش دیتابیس را طراحی کن و با دیتای واقعی تست کن ببین در چه حالتی و با چه اندکس گذاری سرعت به ماکزیمم حالت میرسه .

بعضی مواقع چیزهایی که در تجربه به دست می آید با خواندن 1000 کتاب و پرسیدن از 1000 نفر شاید به دست نیاید ...

[H:Shojaei]

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

شما به هر 2 روش دیتابیس را طراحی کن و با دیتای واقعی تست کن ببین در چه حالتی و با چه اندکس گذاری سرعت به ماکزیمم حالت میرسه .

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