چند اشتباه در طراحی پایگاه داده

20 03 2010
Database - سال نو مبارک

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

این مطلب رو هم مدتی قبل که یک پروژه نیمه کاره رو تحویل گرفتم تا کار کنم و از دست مشکلات پروژه ناراحت بودم نوشتم. پست با کمی ویرایش الان آماده شد!

سال نو همه مبارک و خوش و خرم باشید!

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

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

در ادامه می خواهم چند اشتباه در طراحی پایگاه داده رو مطرح کنم، به این امید که دیگر شاهد آنها نباشم. این موارد مطمئنن در طور دوره های آموزی به کرات مطرح می شود ولی شگفتا که هنوز هم عده ای این اشتباه ها را تکرار می کنند.

  • استفاده ازنوع داده های رشته ای به عنوان اندیس یا  کلید اصلی

نوع داده varchar و هر نوع داده کاراکتری یا رشته ای بدترین نوع انتخاب برای اندیس جدول است. این اشتباه زمانی بدتر خواهد شد که این فیلد به عنوان کلید اصلی نیز استفاده کنید؛ و سرانجام اشتباه با استفاده از این کلید به عنوان کلید خارجی تکمیل خواهد شد!

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

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

راه حل: راه حل بسیار ساده استفاده از انواع داده عددی مانند int یا bigint است. در عین حال می توانید از سایر انواع ساده دیگر نیز استفاده کنید.

  • عدم استفاده از اندیس یا کلید اصلی

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

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

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

  • استفاده از فیلد های NULL بی مورد

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

Database

در کنار استفاده از فیلدهای null می توانید از مقادیر پیش فرض هم استفاده کنید تا هیچ فیلدی ندانسته خالی رد نشود. این کار کدهای sql شما را هم کوتاه تر خواهد کرد.

در همین زمینه مطالعه کنید:

10 Common Design Mistakes

Ten Common Database Design Mistakes

Database Performance Philosophy


کارها

Information

5 responses

21 03 2010
پیام

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

21 03 2010
امیرحسین

مقاله خیلی خوب و مفیدی بود ولی کوتاه بود😉

23 03 2010
ایمان

سال نو مبارک سالار عزیز، امیدوارم سال خوبی پر از موفقیت داشته باشی.
زندگی بدون حادثه و اتفاق که دیگه اسمش زندگی نیست دوست من!

در مورد این مطلب هم اگر کسی دیتابیس خودش رو نرمال بسازه و اون قواعد نرمال سازی پایگاه داده ها رو رعایت کنه دیگه نیازی نیست نگران باشه دیگه!

25 03 2010
22 04 2010
ماکرو

این مورد هایی رو که اشاره کردی ، اشتباهات خیلی فاحشی هستند که اگه یکی تو طراحیش بکار ببره یعنی دیگه تعطیله . فکر کنم بخش دوم اشتباهات طراحی دیتابیس رو باید کم کم تو وبلاگت بذاری ، اما اشتباهاتی رو بنویس که یکمی مخفی هستند و آدم هایی هم که قبلا کارکردن ممکنه انجامش بدن.
مثلا اشتباهاتی که باعث بوجود آمدن join های اضافی میشه و ….

پاسخی بگذارید

در پایین مشخصات خود را پر کنید یا برای ورود روی شمایل‌ها کلیک نمایید:

نشان‌وارهٔ وردپرس.کام

شما در حال بیان دیدگاه با حساب کاربری WordPress.com خود هستید. بیرون رفتن / تغییر دادن )

تصویر توییتر

شما در حال بیان دیدگاه با حساب کاربری Twitter خود هستید. بیرون رفتن / تغییر دادن )

عکس فیسبوک

شما در حال بیان دیدگاه با حساب کاربری Facebook خود هستید. بیرون رفتن / تغییر دادن )

عکس گوگل+

شما در حال بیان دیدگاه با حساب کاربری Google+ خود هستید. بیرون رفتن / تغییر دادن )

درحال اتصال به %s




%d وب‌نوشت‌نویس این را دوست دارند: