ده اشتباه رایج در طراحی پایگاه داده در شیراز

ده اشتباه رایج در طراحی پایگاه داده در شیراز

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

هیچ لیستی از اشتباهات هرگز جامع نخواهد بود. مردم (از جمله خود من) کارهای واقعا احمقانه زیادی را انجام می دهند، گاهی اوقات، به نام "انجام آن". این لیست به سادگی نشان دهنده اشتباهات طراحی پایگاه داده در شیراز  است که در حال حاضر در ذهن من، یا در برخی موارد، دائماً در ذهن من است. این تاپیک رو قبلا دو بار انجام دادم. اگر علاقه مند به شنیدن نسخه پادکست هستید، به SQL Down Under فوق العاده عالی Greg Low مراجعه کنید. من همچنین یک نسخه فشرده و ده دقیقه ای در PASS برای غرفه Simple-Talk ارائه کردم. در ابتدا ده نفر بودند، سپس شش نفر و امروز به ده نفر برگشته اند. و اینها دقیقاً همان ده موردی نیستند که من با آن شروع کردم. این ده نفر هستند که از امروز برای من برجسته هستند.

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

طراحی/برنامه ریزی ضعیف

نادیده گرفتن عادی سازی

استانداردهای نامگذاری ضعیف

عدم وجود مستندات

یک جدول برای نگهداری تمام مقادیر دامنه

استفاده از ستون های هویت/راهنما به عنوان تنها کلید

عدم استفاده از امکانات SQL برای محافظت از یکپارچگی داده ها

عدم استفاده از رویه های ذخیره شده برای دسترسی به داده ها

تلاش برای ساخت اشیاء عمومی

عدم انجام تست

طراحی/برنامه ریزی ضعیف

جورج هریسون "اگر ندانید به کجا می روید، هر جاده ای شما را به آنجا خواهد برد."

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

اجازه بدهید از شما بپرسم: آیا شما یک پیمانکار برای ساختن خانه استخدام می کنید و سپس از آنها بخواهید که از فردای آن روز شروع به ریختن فونداسیون کنند؟ حتی بدتر از آن، آیا می خواهید که بدون نقشه یا نقشه خانه انجام شود؟ امیدوارم به هر دوی اینها "نه" پاسخ داده باشید. یک طرح لازم است تا مطمئن شوید که خانه ای که می خواهید ساخته می شود و زمینی که روی آن می سازید در غار زیرزمینی فرو نمی رود. اگر پاسخ شما مثبت است، مطمئن نیستم که چیزی که بتوانم بگویم به شما کمک کند یا خیر.

مانند یک خانه، یک پایگاه داده در شیراز  خوب با تدبیر ساخته می شود و با دقت و توجه مناسب به نیازهای داده هایی که در آن زندگی می کنند، داده می شود. نمی توان آن را در نوعی انفجار معکوس کنار هم انداخت.

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

اغلب اوقات، یک مرحله برنامه ریزی مناسب به نفع "انجام آن" نادیده گرفته می شود. پروژه در جهت خاصی پیش می رود و زمانی که مشکلاتی به ناچار به وجود می آیند - به دلیل عدم طراحی و برنامه ریزی مناسب - "هیچ زمانی" برای بازگشت و رفع آنها با استفاده از تکنیک های مناسب وجود ندارد. این زمانی است که «هک کردن» شروع می‌شود، با وعده پنهانی برای بازگشت و اصلاح مسائل بعداً، چیزی که واقعاً به ندرت اتفاق می‌افتد.

مسلماً پیش‌بینی هر نیازی که طراحی شما باید برآورده کند و هر مشکلی که احتمالاً پیش می‌آید غیرممکن است، اما مهم است که با برنامه‌ریزی دقیق تا حد امکان مشکلات احتمالی را کاهش دهید.

نادیده گرفتن عادی سازی در شیراز

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

مفهوم عادی سازی 30 سال است که وجود داشته است و مبنایی است که SQL و پایگاه داده های رابطه ای بر اساس آن پیاده سازی می شوند. به عبارت دیگر، SQL برای کار با ساختارهای داده عادی ساخته شده است. عادی سازی فقط طرحی توسط برنامه نویسان پایگاه داده در شیراز  برای آزار برنامه نویسان برنامه نیست (این صرفاً یک عارضه جانبی رضایت بخش است!)

SQL ماهیت بسیار افزودنی دارد، زیرا اگر بیت‌ها و تکه‌های داده‌ای داشته باشید، ایجاد مجموعه‌ای از مقادیر یا نتایج آسان است. در عبارت FROM، مجموعه ای از داده ها (یک جدول) را می گیرید و (JOIN) را به جدول دیگری اضافه می کنید. برای تولید مجموعه نهایی مورد نیاز، می توانید هر تعداد مجموعه داده را با هم اضافه کنید.

این ماهیت افزودنی بسیار مهم است، نه تنها برای سهولت توسعه، بلکه برای عملکرد. ایندکس ها زمانی موثرتر هستند که بتوانند با کل مقدار کلید کار کنند. هر زمان که مجبور به استفاده از SUBSTRING، CHARINDEX، LIKE و غیره هستید، برای تجزیه مقداری که با مقادیر دیگر در یک ستون ترکیب شده است (مثلاً برای جدا کردن نام خانوادگی یک فرد از یک ستون نام کامل) پارادایم SQL شروع به شکسته شدن می کند و داده ها کمتر و کمتر قابل جستجو می شوند.

بنابراین عادی سازی داده های شما برای عملکرد خوب و سهولت توسعه ضروری است، اما همیشه این سوال مطرح می شود: "چقدر نرمال سازی شده به اندازه کافی نرمال شده است؟" اگر کتاب‌هایی در مورد نرمال‌سازی خوانده‌اید، بارها شنیده‌اید که فرم سوم عادی ضروری است، اما فرم‌های عادی چهارم و پنجم واقعاً مفید هستند وقتی به آن‌ها رسیدگی کنید، به راحتی قابل دنبال کردن هستند و ارزش آن را دارند. زمان لازم برای اجرای آنها

با این حال، در واقعیت، بسیار رایج است که حتی اولین فرم عادی به درستی اجرا نمی شود.

استانداردهای نامگذاری ضعیف

"آنچه را که ما گل رز می نامیم، با هر نام دیگری بوی شیرین می دهد"

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

اسامی، در حالی که یک انتخاب شخصی است، اولین و مهمترین خط اسناد برای درخواست شما هستند. من در اینجا وارد تمام جزئیات بهترین نامگذاری چیزها نمی شوم - این یک موضوع بزرگ و درهم و برهم است. چیزی که در این مقاله می‌خواهم بر آن تاکید کنم، نیاز به ثبات است. نام‌هایی که انتخاب می‌کنید فقط برای این نیستند که بتوانید هدف یک شی را شناسایی کنید، بلکه به همه برنامه‌نویسان، کاربران و غیره آینده اجازه می‌دهد تا به سرعت و به راحتی درک کنند که چگونه بخشی از پایگاه داده در شیراز شما قرار است استفاده شود، و چه چیزی داده هایی که ذخیره می کند هیچ کاربر آینده ای از طراحی شما نیازی به بررسی یک سند 500 صفحه ای برای تعیین معنای برخی از نام های حواس پرت ندارد.

به عنوان مثال، ستونی به نام X304_DSCR را در نظر بگیرید. لعنتی یعنی چی؟ ممکن است پس از کمی سر خاراندن تصمیم بگیرید که به معنای "توضیح X304" باشد. احتمالاً اینطور است، اما شاید DSCR به معنای تمایزکننده یا تفکیک کننده باشد؟

مگر اینکه DSCR را به‌عنوان مخفف استاندارد شرکتی برای توضیحات تعیین کرده باشید، پس X304_DESCRIPTION نام بسیار بهتری است و هیچ چیزی را به تصور نمی‌گذارد.

این فقط به شما اجازه می دهد تا بفهمید قسمت X304 چه معنایی دارد. در بازرسی اول، به نظر من، X304 بیشتر به نظر می رسد که باید داده های یک ستون باشد تا نام ستون. اگر بعداً متوجه شدم که در سازمان، X305 و X306 نیز وجود دارد، آن را به عنوان یک مشکل در طراحی پایگاه داده در شیراز علامت‌گذاری می‌کنم. برای حداکثر انعطاف پذیری، داده ها در ستون ها ذخیره می شوند، نه در نام ستون ها.

در همین راستا، در مقابل وسوسه گنجاندن «فراداده» در نام یک شی مقاومت کنید. نامی مانند tblCustomer یا colVarcharAddress ممکن است از منظر توسعه مفید به نظر برسد، اما برای کاربر نهایی فقط گیج کننده است. به‌عنوان یک توسعه‌دهنده، باید بر این تکیه کنید که بتوانید تعیین کنید که نام جدول یک نام جدول بر اساس متن در کد یا ابزار است و نام‌های واضح، ساده و توصیفی مانند مشتری و آدرس را به کاربران ارائه دهید.

روشی که من به شدت به آن توصیه می کنم استفاده از فاصله ها و شناسه های نقل قول در نام اشیا است. شما باید از نام ستون‌ها مانند «Part Number» یا به سبک مایکروسافت [Part Number] اجتناب کنید، بنابراین از شما کاربران می‌خواهد که این فاصله‌ها و شناسه‌ها را در کد خود وارد کنید. آزاردهنده و به سادگی غیر ضروری است.

عدم وجود مستندات

در مقدمه اشاره کردم که در برخی موارد به اندازه شما برای خودم می نویسم. این موضوعی است که در آن بیشتر صادق است. با نام‌گذاری دقیق اشیا، ستون‌ها و غیره، می‌توانید به همه بفهمانید که پایگاه داده در شیراز شما در حال مدل‌سازی چیست. با این حال، این تنها گام اول در نبرد مستندسازی است. واقعیت تاسف بار این است که «مرحله اول» اغلب تنها قدم است.

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