قوائد naming و طراحی بانک اطلاعات بر اساس uncocoder convention
استاندارد های زیادی برای naming وجود دارد، اما ما استاندارد خود را ترجیح می دهیم، چرا که در پروژه های بسیار بزرگ، تست شده و بهترین حالت نامگذاری در نظر گرفته شده است. از طرفی لزوماً convention ایجاد شده توسط یک شرکت بزرگ مثل google یا oracle مورد تأیید نیست، چون در عمل نشان داده خوب کار نمی کند.
اطلاعات زیر در مورد MySQL تدوین گردیده است.
نام گذاری Database
- نام آن خیلی ساده می شود username_databasename مثل uncocoder_sample که username را خود hosting از پیش اضافه کرده.
- Collation دیتابیس باید utf8_general_ci باشد.
- نام Database خود را به گونه ای قرار دهید که با کلیدواژه های MySQL تداخل نداشته باشد. کلیه کلید واژه های MySQL
نام گذاری Table ها
- می شود حداکثر چهار حرف اختصاصی و مشخص کننده پروژه + نام table مورد نظر، مثل wk_content برای بانک اطلاعات محتوای سرویس wiki و یا news_author برای بانک اطلاعات ترجمه کنندگان اخبار در سرویس خبر.
- از اضافه کردن s در انتهای نام بانک خودداری می کنیم یعنی نمی نویسیم news_authors ( مترجمان ) بلکه می نویسیم news_author ( مترجم )
- از اضافه کردن هر گونه ادامه برای Table ها مثل tbl_ و ... خودداری می کنیم.
- Table ها از Collation دیتابیس که utf8_general_ci است استفاده می کنند.
- نام Table های خود را به گونه ای قرار دهید که با کلیدواژه های MySQL تداخل نداشته باشد. کلیه کلید واژه های MySQL
نام گذاری Field ها
- فیلد اول که primary id هست را با نام pid درج می کنیم و مسلماً auto increment
- از درج نام اختصاصی دیتابیس در ابتدای فیلد خودداری می شود و نمی نویسیم: author_firstname بلکه می نویسیم firstname . این موضوع هیچ مشکلی در join کردن ایجاد نخواهد کرد.
- چنانچه قصد جداکردن کلمات را داشتیم از _ استفاده نمی کنیم و lowerCamelCase را رعایت می کنیم. بطور مثال isBanned یا firstName
- هیچ چیز را خلاصه نمی نویسیم. مثلاً نمی نویسیم desc بجای description.
- همه فیلدها غیر از pid ، باید اجازه داشته باشند null باشند.
- برای نوشته های محدود ( مثل تیتر خبر ) varchar انتخاب می شود و برای نوشته های نامحدود ( مثل محتوای یک خبر ) از فرمت text استفاده می شود.
- برای تاریخ ها از فرمت timestamp استفاده می شود.
- برای عبارات boolean مثل 0, 1 از تایپ boolean استفاده نمی شود و از int استفاده می شود.
- فرمت های int نسبت به اندازه مورد نیاز انتخاب می شوند. مثلاً برای تعداد vote تایپ SMALLINT کفایت می کند.
- جهت کسب اطلاعات بیشتر در خصوص تایپ ها لینک مفید است.
- چنانچه قبلاً دیتابیسی با ساختاری غیر از ساختار فوق ایجاد شده باشد، دیگر آنرا تغییر نمی دهیم چون ممکن است باعث شکستن کد شود ولی برای ساختار های جدید از قوانین فوق استفاده می کنیم.
- نام Field های خود را به گونه ای قرار دهید که با کلیدواژه های MySQL تداخل نداشته باشد. کلیه کلید واژه های MySQL
استاد چندتا سوال:
- چرا باید همه فیلدها allow nulls باشند؟ فیلدهایی که اجباراٌ باید پر شوند رو چرا باید allow nulls کنیم؟
- لزوما نباید جداول دارای فیلدی مثله pid و از نوع is identity یا auto incerement باشند،غیر از اینه؟ فرضا اگه از مثال معروف سیستم دانشجویی استفاده کنیم واسه جدول Student آیا بهتر نیست به جای اضافه کردن فیلدی به نام pid از همون شماره دانشجویی به عنوان کلید اصلی استفاده کرد؟ اضافه کردن این فیلد باعث افزونگی نمیشه؟
- در نامگذاری جداول، اضافه کردن پیشوندها خیلی مواقع در خوانایی کد تاثیرگذار خواهد بود مثلا tblAuthor و یا tbl_author و اگه این جدول فرضا یک view هم داشته باشه با عنوان viwAuthor و یا viw_author موجب ایجاد تمایز با table آن خواهد شد و خوانایی بیشتر. اشتباه میکنم؟
- و یا چرا باید به جای استفاده از data type ای چون boolean از int استفاده کرد؟
سئوالاتی که دوست عزیز در پاسخ بالا مطرح کردند، سئوالات خوبی است و البته نظر آقای حمیدرضا نیز کاملاً مناسب، اما با ویرایشی دیگر و کاملتر:
1- محل تولید منابع باگ تا جای ممکن باید محدود و کنترل شده باشد. اگر در جدولی در دیتابیس، مقادیر غیر null درج شوند، گاهاً بدون اینکه برنامه نویس چیزی را در کد نوشته باشد، مقدار پیش فرض جایگزین می شود و باعث گیج شدن. از طرفی در این شرایط اگر ساختار دیتابیس عوض شود و مقدار پیش فرض null شود ممکن است کدهای سرور کاملاً غلط کار کنند و اصطلاحاً کد بشکند. پس ما تنها محل ورود اطلاعات را کد قرار می دهیم و هر چیزی که وارد نشد، null محسوب شود. این تنها یک حسن بود و محاسن زیاد دیگری هم دارد.
2- باز هم برای محدود کردن منابع باگ، قرار دادن یک فیلد pid همیشه مفید تر از قرار ندادنش هست. سرباره ای هم نداره. به این ترتیب روی سایر فیلدها میشه مانور داد و نگران این نبود که unique بودن هر جدول بر اساس یک فیلد نامشخص ( بطور عموم ) مهیا می شود.
3- در برنامه نویسی مدرن، چیزهایی به اسم View دیگر کاربردی ندارند و هر چه باشد ( بهتر است باشد ) تنها دیتابیس خام است. View هم بصورت Realtime توسط Query توسط کدهای سرور ساخته و استفاده خواهند شد. سابق بر این Query های آماده یک Stored Procedure یا View محسوب می شدند ( مثلاً در Access ) که راهکار مناسبی نیست و باز هم منابع تولید باگ بیشتر خواهد شد و سردرگمی تیم توسعه در مواردی که در کد نیست اما کار می کند!
4- در عمل داده Boolean یک int هست و این استاندارد بانک هایی نظیر SQLite نیز می باشد. پس رعایت تایپ های ساده مفید است. از طرفی گاهاً پیش می آید که می فهمید محتوای یک فیلد صرفاً 0 و یا 1 نیست و مثلاً می تواند خنثی یا -1 نیز باشد. در این شرایط مجبور خواهید شد از تایپ Boolean به تایپ int تغییر Structure بدهید.
پاسخگویی و مشاهده پاسخ های این سوال تنها برای اعضای ویژه سایت امکان پذیر است .
چنانچه تمایل دارید به همه بخش ها دسترسی داشته باشید میتوانید از این بخش لایسنس این آموزش را خریداری نمایید .
