عادی سازی در جهان واقعی
نرمال سازی پایگاه داده یکی از گاوهای مقدس توسعه نرم افزار است. هر دوره برنامه نویسی دوره کارشناسی که شما خواندید یا کتابی که خوانده اید، به اهمیت پایگاه داده های عادی احترام می گذارید.
وقت آن رسیده است تا این حقیقت را به چالش بکشد. گاهی اوقات خوب است که پایگاه داده خود را دگرگون کند!
هنگامی که شما باید عادی شود؟
عادی سازی پایگاه داده از یکپارچگی داده ها محافظت می کند. این یک ایده عالی در بسیاری از موارد است و شما باید هر گونه تلاش طراحی پایگاه داده را با در نظر گرفتن عادی شروع کنید. اگر شما می توانید پایگاه داده خود را عادی کنید، برای آن بروید! در حقیقت، در اینجا چند توصیه عملی در مورد نحوه به کارگیری پایگاه داده خود در این سایت ارائه می شود:
- قرار دادن پایگاه داده در فرم اول طبیعی (1NF)
- قرار دادن پایگاه داده خود در فرم عادی دوم (2NF)
- قرار دادن پایگاه داده خود در فرم عادی سوم (2NF)
خط پایین این است که شما باید پایگاه داده خود را نرمال کنید، مگر اینکه دلیل خوبی داشته باشید. نرمال کردن معمولا طراحی صدا است. این اطلاعات را از کار بیاندازد، عملکرد بهینه سازی را کاهش می دهد و این احتمال را می دهد که شما از مسائل مربوط به یکپارچگی داده ها ناشی می شود که از یکسانی داده ها در گوشه های مختلف پایگاه داده شما جدا شده است.
بعضی از دلایل خوب برای عادی کردن
به گفته او، دلایل خوبی برای نادیده گرفتن پایگاه داده شما وجود دارد. بیایید به چند مورد نگاه کنیم:
- پیوستن به گران است به طور منظم پایگاه داده شما اغلب شامل ایجاد تعداد زیادی جداول می شود. در حقیقت، شما می توانید به راحتی با آنچه که فکر می کنید باید یک پرس و جو ساده است که شامل پنج یا 10 جدول باشد. اگر تا کنون سعی در پیوستن به پنج جدول داشته باشید، می دانید که در اصل کار می کند، اما در عمل عمیقا دشوار است. اگر شما در حال ایجاد یک برنامه وب هستید که به درخواستهای چندگانه در برابر جداول بزرگ متکی است، ممکن است خودتان فکر کنید: "اگر تنها این پایگاه داده عادی نشود!" هنگامی که این فکر را در سر خود می شنوید، وقت خوبی است در نظر نگیرید اگر شما می توانید تمام داده های مورد استفاده توسط آن پرس و جو را به یک جدول جدا کنید بدون آن که خطرناک بودن تمامیت داده خود باشید، برای آن بروید! یک شورشی باشید و پایگاه داده خود را انکار کنید. شما باز نخواهد گشت
- طراحی نرمال مشکل است اگر شما با یک طرح پایگاه داده پیچیده کار می کنید، احتمالا خود را در برابر پیچیدگی نرمال شدن در برابر جدول خود می بینید. به عنوان یک قاعده ساده، اگر شما تمام روز را صرف تلاش برای کشف نحوه حرکت به شکل نرمال چهارم، شما ممکن است به نرمی شدن بیش از حد. گام بردارید و از خودتان بپرسید آیا واقعا ارزش ادامه دارد؟
- سریع و کثیف باید سریع و کثیف باشد. اگر شما فقط یک نمونه اولیه را توسعه می دهید، فقط کاری انجام دهید که به سرعت کار کند. واقعا خوبه. توسعه برنامه سریع گاهی مهمتر از طراحی ظریف است. فقط به یاد داشته باشید که به عقب برگردید و نگاه دقیق به طراحی خود را داشته باشید، زمانی که آماده باشید که فراتر از مرحله تولید اولیه حرکت کنید. قیمت شما برای طراحی پایگاه داده سریع و کثیف پرداخت می شود که ممکن است لازم باشد که آن را دور بریزید و وقت آن زمان برای ساختن برای تولید شروع شود.
- اگر از پایگاه داده NoSQL استفاده می کنید ، طبیعی بودن سنتی مطلوب نیست. در عوض، پایگاه داده خود را با استفاده از مدل BASE طراحی کنید که خیلی آمرزنده است. این مفید است هنگامی که شما ذخیره داده های غیر ساختار مانند ایمیل ها، تصاویر و یا فیلم ها.
برخی از کلمات احتیاط
عادی سازی پایگاه داده به طور کلی یک ایده خوب است. شما باید سعی کنید از اصول نرمال بودن پیروی کنید، زمانی که منطقی به نظر برسد. اما اگر همه شاخص ها به عادی بودن پیوسته پیچیده باشند، رویکردی را که کار را در حین محافظت از داده های شما انجام می دهد، در نظر بگیرید.
در نهایت - اگر انتخاب کنید که از قوانین عادی برداشته شود، در مورد چگونگی اجرای یکپارچگی پایگاه داده، مراقب باشید. اگر اطلاعات ذخیره شده بیش از حد را ذخیره کنید، راه اندازی کنید و سایر کنترل ها را در محل قرار دهید تا اطمینان حاصل شود که اطلاعات سازگار باقی می مانند.