لطفا بگید که ایجاد کردن تعداد زیادی ستون (40 یا 50) تاثیر مخرب نداره؟

[phpweb]

من توی دیتابیس یه جدول درست کردم که 40 تا ستون داره، این مسئله مشکلی توی امنیت و سرعت جدول ایجاد نمیکنه؟

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

لطفا بگید که ایجاد کردن تعداد زیادی ستون (40 یا 50) تاثیر مخرب نداره؟

[binyaft]

یعنی پایگاه داده اونقد بده که با 40-50 تا جدول مشکلی براش پیش بیاد!؟

فکر نکنم اینطوری باشه!

[Sajjad.Aghapour]

من توی دیتابیس یه جدول درست کردم که 40 تا ستون داره، این مسئله مشکلی توی امنیت و سرعت جدول ایجاد نمیکنه؟

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

لطفا بگید که ایجاد کردن تعداد زیادی ستون (40 یا 50) تاثیر مخرب نداره؟

گرچه این مسئله ربطی به Normalization نداره ولی هدف اون باید اینجا اعمال بشه. 40 تا ستون زیاد نیست؟ بهتره تجزیه بشه اگر امکانش هست. گر جدول مربوط به تنظیمات هست میتونید تنظیمات رو طبقه بندی کنید و براساس طبقه بندی خودتون جداول رو ایجاد کنید....

[phpweb]

گرچه این مسئله ربطی به Normalization نداره ولی هدف اون باید اینجا اعمال بشه. 40 تا ستون زیاد نیست؟ بهتره تجزیه بشه اگر امکانش هست. گر جدول مربوط به تنظیمات هست میتونید تنظیمات رو طبقه بندی کنید و براساس طبقه بندی خودتون جداول رو ایجاد کنید....

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

در ضمن یعنی مای اس کیو ال نمی تونه با این چنین جدولی بخوبی به کار خودش ادامه بده؟

[phpweb]

یعنی پایگاه داده اونقد بده که با 40-50 تا جدول مشکلی براش پیش بیاد!؟

فکر نکنم اینطوری باشه!

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

[eshpilen]

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

[phpweb]

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

با توجه به اینکه 20 حالت مختلف (درکمه های رادیویی) و 20 فیلد ورود اطلاعات راهی ندارم جز اینکه تعداد ستونها رو زیاد کنم.

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

یه جدول با 5 ردیف و 40 ستون، 2000 خونه داره و نسبت به بقیه جداول که ممکنه فقط 10 ستون داشته با شه اما تعداد ردیف های اون جدول خیلی زیاد باشه، جدول من کارایی خوبی باید داشته باشه.

نظر شما در مورد این مقایسه که مد نظر من هست چیه؟

[eshpilen]

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

[eshpilen]

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


من توی دیتابیس یه جدول درست کردم که 40 تا ستون داره، این مسئله مشکلی توی امنیت و سرعت جدول ایجاد نمیکنه؟
تعداد ستون یک جدول به خودی خود نمیتونه هیچ ربطی به امنیت داشته باشه!
غیر از اینه؟
یا شاید شما منظور دیگری داشتید و بد بیان کردید!؟

[امیـرحسین]

MySQL با این موضوع مشکلی نداره ولی معمولا این تعداد ستون لازم نیست و میشه بهینه‌اش کرد. به این فکر کنید که چه تعداد از این فیلدها اغلب ممکنه خالی بمونه و استفاده نشه و کدوم فیلدها معمولا پر میشه و یا به کدوم فیلدها همیشه احتیاج هست.
تصور کنید میخوایم برای اطلاعات کاربران سایت جدول طراحی کنیم. این جدول شامل اطلاعات شحصی کاربرها مثل و نام و آدرس و ایمیل و غیره است به اضافه تعدادی 0/1 برای مشخص کردن دسترسی‌های کاربر و مثلا ستونی که تعیین میکنه کاربر VIP هست یا خیر.
این اطلاعات رو میشه به سه تا جدول تقسیم کرد. چرا که معمولا کم پیش میاد که به همه‌ی این اطلاعات یکجا نیاز داشته باشیم. یا اطلاعات شخصی رو میخوایم یا دسترسی‌ها یا امکانات ویژه‌ی هر کاربر. با این تقسیم بندی وقتی به اطلاعات شخصی نیاز دارم با یک جدول با تعداد مناسبی ستون روبرو هستم. اگر به دسترسی ها نیاز داشته باشم براحتی با یک JOIN ساده بدستش میارم و برای اطلاعاتی که لزوما هر کاربر نداره مثل همون VIP و مشابهش جدول جدایی دارم که مجبور نباشم برای بیشتر کاربرانی که جزوش نیستند NULL یا 0 ذخیره کنم....

خلاصه توصیه میکنم اول فیلدهایی که ممکنه هیچوقت پر یا فعال نشه رو پیدا و جدا کنیدو دوم فیلدهای که همخونی ندارند رو جدا کنید تا کوئری‌ها بهینه بشند.

[phpweb]

MySQL با این موضوع مشکلی نداره ولی معمولا این تعداد ستون لازم نیست و میشه بهینه‌اش کرد. به این فکر کنید که چه تعداد از این فیلدها اغلب ممکنه خالی بمونه و استفاده نشه و کدوم فیلدها معمولا پر میشه و یا به کدوم فیلدها همیشه احتیاج هست.
تصور کنید میخوایم برای اطلاعات کاربران سایت جدول طراحی کنیم. این جدول شامل اطلاعات شحصی کاربرها مثل و نام و آدرس و ایمیل و غیره است به اضافه تعدادی 0/1 برای مشخص کردن دسترسی‌های کاربر و مثلا ستونی که تعیین میکنه کاربر VIP هست یا خیر.
این اطلاعات رو میشه به سه تا جدول تقسیم کرد. چرا که معمولا کم پیش میاد که به همه‌ی این اطلاعات یکجا نیاز داشته باشیم. یا اطلاعات شخصی رو میخوایم یا دسترسی‌ها یا امکانات ویژه‌ی هر کاربر. با این تقسیم بندی وقتی به اطلاعات شخصی نیاز دارم با یک جدول با تعداد مناسبی ستون روبرو هستم. اگر به دسترسی ها نیاز داشته باشم براحتی با یک JOIN ساده بدستش میارم و برای اطلاعاتی که لزوما هر کاربر نداره مثل همون VIP و مشابهش جدول جدایی دارم که مجبور نباشم برای بیشتر کاربرانی که جزوش نیستند NULL یا 0 ذخیره کنم....

خلاصه توصیه میکنم اول فیلدهایی که ممکنه هیچوقت پر یا فعال نشه رو پیدا و جدا کنیدو دوم فیلدهای که همخونی ندارند رو جدا کنید تا کوئری‌ها بهینه بشند.

این جدول فقط 5 ردیف و 42 ستون داره و همه اینها پر می شن.

با توجه به کم بودن تعداد ردیف های جدول، هنوز این مسئله مشکلی بوجود می یاره؟

[امیـرحسین]

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