بهینه سازی

[zari_attari]

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

[ASKaffash]

سلام
بستگی دارد به نحوه گزارش گیری و شرط جلوی Where

[zari_attari]

سلام
بستگی دارد به نحوه گزارش گیری و شرط جلوی Where
کلا بهتره سطر بیشتری داشته باشیم یا ستون ؟ به where کاری ندارم!!

[pezhvakco]

درود :

کلا بهتره سطر بیشتری داشته باشیم یا ستون ؟

این پرسش شما یه کم نامربوط به هم است .
سطر و ستون به هم ربطی ندارند و نباید با هم مقایسه بشن .

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

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

فکر خوش.

[zari_attari]

درود :


این پرسش شما یه کم نامربوط به هم است .
سطر و ستون به هم ربطی ندارند و نباید با هم مقایسه بشن .

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

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

فکر خوش.

منظورم اینه که من میتونم جدولی طراحی کنم که دارای 15 ستون باشه یا اینکه جدولی طراحی کنم که دارای 5 ستون باشه اما تعداد سطرهای آن زیاد باشه.
کدوم بهتره؟ از بابت بهینه سازی؟؟؟؟؟

[pezhvakco]

کدوم بهتره؟ از بابت بهینه سازی؟؟؟؟؟
بهینه سازی به این معنی نیست که شما امکانات رو کم کنی ؟

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

برای Sql این تعداد سطر یا ستون زیاد تفاوتی نداره، چون برای بیش تر از این ها طراحی شده .

شما باید کد نویسی روان تری برای کار با اطلاعات داشته باشی تا به تونی بهینه کار کنی .

فکر خوش .

[AminSobati]

اگر قصدتون اینه که فیلدها رو به صورت General بیارین داخل رکورد، و ساختاری مثل Open Schema (متشکل از فیلدهای عمومی Property و Value) بوجود بیارین، جز موارد نادر اصلا توصیه نمیکنم.

[محمد سلیم آبادی]

اگر قصدتون اینه که فیلدها رو به صورت General بیارین داخل رکورد، و ساختاری مثل Open Schema (متشکل از فیلدهای عمومی Property و Value) بوجود بیارین، جز موارد نادر اصلا توصیه نمیکنم.

بطور مثال در بحث Cross tabbing می تونیم از دو سناریوی open schema و frequent schema changes استفاده کنیم. که best این هست که از سناریوی open schema استفاده کنیم. در غیر اینصورت با کمک DDL نیاز داریم تا بطور مداوم ساختار را تغییر دهیم که این کار ساده ای نیست.
از طرفی زبان قدرمند SQL و قابلیت های Querying امکان مانور فراوانی را در سناریوی open schema به ما می دهند.

شما که در SQL Server خیلی knowledgeable هستین لطفا یک گوشه چشمی هم به اینجا بی اندازین:
http://www.barnamenevis.org/forum/showthread.php?t=220709

[mohitlog]

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

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

مثلا در بحث ادرس دو راه وجود داره
1 - ادرس بصورت یک فیلد کلی در نظر گرفته بشه و زیاد کاری باهاش نداریم و نهایت کارمون چاپ ادرس باشه
2- ادرس = استان+ شهر + خیابان + کد پستی و برای هر کدوم از فیلدها میخایم کاری انجام بدیم.



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

[محمد سلیم آبادی]

اینم بگم بهتره ستونها کم باشه و یا اگر خیلی زیاد هست تو چند تا جدول شکسته بشه ولی طوری که هیچ اطلاعاتی از بین نره و بتوان با ترکیب جدوال اطلاعات اصلی را بدست اوردو هیچ اطلاعاتی گم نشه
دوست من،
کم یا زیاد بودن تعداد ستون به خودی خود نمی تونه منجر به کاهش عملکرد سیستم شود.
در پرس و جوهایی که عموما از جدول گرفته می شود قرار بر این نیست که تمام ستونها یا بیشتر آنها SELECT شوند. و خیلی از ستون ها تنها برای جستجوهای خاص (مثلا در ماه یک بار) در نظر گرفته میشند و مکررا از آنها بهره نمی بریم. و با تعریف و ساختن شاخص های مناسب روی ستون ها مشکل سرعت بازیابی را حل می کنیم.
از طرفی SQL Server برای جداول Narrow/nonwide تا 1024 ستون را suport می کند.
http://msdn.microsoft.com/en-us/library/ms143432.aspx

زمانی ستون های جدول را split می کنیم در چند جدول که تنها نمونه های خاصی از جدول دارای مقدار برای تمام خصیصه های جدول هستند، در این حالت دو جدول را یکدیگر یک ارتباط یک به یک خواهند داشت. (که با وجود ویژگی ستون های sparse در SQL Server 2008 مشکل هدر رفتن حافظه توسط اینگونه ستون ها از بین رفته است)

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