آیا مقادیر NULL در عملکرد دیتابیس تاثیر دارند؟

[rasoul_par]

سلام دوستان
ما یک جدول داریم به اسم product و یکی از خاصیت های product اینه که آیا suspend شده یا نه، و اگر شده دلیل مربوط suspension رو باید ذخیره کنیم. سوال من اینه که کدوم گزینه بهتره از بین دو گزینه زیر:

ساخت یک جدول دیگه به اسم suspend و ذخیره کردن id مربوط به product و ایجاد یک خاصیت دیگه برای reason
ضافه کردن خاصیت reason توی جدول product

نکته اینه که اگر گزینه دوم انتخاب بشه مقدار زیادی فیلد null خواهیم داشت که از نوع text هستن.
در واقع سوال اینه که فیلدی با مقدار null و از نوع مثلا varchar(50) آیا به اندازه 50 کاراکتر رو رزرو می کنه یا نه، اگر نمی کنه تاثیرش بر عملکرد دیتابیس چیه!
اگر هم تاپیکی وجود داره در این رابطه که من ندیدم لطفا بگید.

[حمیدرضاصادقیان]

سلام.
ببینید اگر افزونگی برای جدول اصلی شما به ارمغان نمیاره میتونید در همون جدول ذخیره کنید و مقدار پیش فرض اونو خالی بذارید که Null ذخیره نکنه.
وقتی شما نوع فیلد رو Varchar انتخاب میکنید در واقع در Page ها در قسمت Variable Length Field ها مقادیر این فیلد نگهداری میشن و با توجه به داده ای که ذخیره شده فضا اشغال میکنه.مثلا اگر یک کارکتر باشه یک بایت و اگر بیشتر باشه به همون مقدار. ولی وقتی از نوع ثابت مثل Char باشه چه داده ثبت بشه چه نشه به اندازه طول فیلد فضا در نظر میگیره.
مقادیر Null یکی از مشکلاتشون در رویارویی با شرطهای Where و Join ها و Grouping ها هستند که مقادیر مختلفی از خودشون نشون میدن و نتایج گوناگونی به شما میدن که به همین خاطر بهتره از ذخیره اونا جلوگیری کرد و با یک مقدار پیش فرض جایگزین بشن.

[tooraj_azizi_1035]

گزینه 1 بهتره چون SQL Server باید به ازای فیلد Reason فضا رزرو کنه و اگه 50 درصد احتمال ثبت Reason باشه یعنی NULL نباشه بازهم در در کوئری هایی که می زنید تعداد خواندن های منطقی افزایش پیدا میکنه.
اما با وجود یک جدول دیگه درسته که متحمل یک INNER JOIN می شیم اما چون احتمالاً جدول Reason اونقدرها رشد پیدا نمی کنه JOIN توسط OPTIMIZER از نوع Nested Loops انتخاب میشه و Cost آنچنانی در پی نخواهد داشت.
ذخیره مقادیر NULL باعث بوجود آمدن LOOKUP اضافی خواهد شد:http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search

[حمیدرضاصادقیان]

گزینه 1 بهتره چون SQL Server باید به ازای فیلد Reason فضا رزرو کنه و اگه 50 درصد احتمال ثبت Reason باشه یعنی NULL نباشه بازهم در در کوئری هایی که می زنید تعداد خواندن های منطقی افزایش پیدا میکنه.
اما با وجود یک جدول دیگه درسته که متحمل یک INNER JOIN می شیم اما چون احتمالاً جدول Reason اونقدرها رشد پیدا نمی کنه JOIN توسط OPTIMIZER از نوع Nested Loops انتخاب میشه و Cost آنچنانی در پی نخواهد داشت.

البته در این حالت میتونه اون فیلد رو فیلتر کنه درصورتی که وجود نداره.Logical Read ها نیز مقداری افزایش پیدا میکنند ولی اینجا شما یک حلقه از Join رو کم کردین.اگر تعداد فیلدها زیاد بود و باعث کاهش Page Density میشه بهتره در یک جدول جدا باشه ولی اگر مثلا در اینجا 3 تا فیلد دارید بهتره در همین جدول نگهداری کنید و تاثیری در سرعت شما نخواهد داشت.
همچنین مورد دیگر اینکه اگر در جدول جدا باشه شما باید همیشه این Join رو بزنید و این مقدار رو بیارید و اگر مقدار Null باشه مجبورید از Outer Join استفاده کنید که این نیز سبب میشه Plan شما تغییر کنه و در نتیجه باعث تغییر در سرعت خواهیم شد.

[mohsen_sh]

Null علاوه بر اشکالات ذکر شده در عملیات ریاضی و نیز مقایسه ای مشکلاتی ایجاد می کنه.
به نظر من هم وجود یک جدول مناسب تر هستش.کلا تا حد ممکن باید از هزینه Jion اجتناب بشه