داده ها در فرم برنامه کنترل میشود ، آیا نیازی به کنترل در دیتا بیس نیز هست ؟

[Helmod]

سلام دوستان ،

سوالم اینه که من داده ها رو روی فرم چک میکنم ، یعنی برای مثال وقتی فیلدی برای ورود عدد هست ، فیلد فقط عدد رو قبول میکنه .

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

در نهایت بعد از چک کردن درستی داده ها و فشردن دکه " ثبت اطلاعات " ، اطلاعات بدرستی در دیتا بیس ذخیره میشه .

سوال :

من میام توی پایگاه داده که اکسس هست همه فیلد ها رو در یک جدول مشخصات فردی از نوع Short Text میگیریم . و اطلاعاتی که درون فرم هست رو داخل این جدول ذخیره میکنم .

آیا باید همونطوری که درون فرم میام از وزود اطلاعات نادرست ( شماره ملی : فقط عدد **** نام : فقط حرف ) جلوگیری میکنم ، باید در طراحی دیتا بیس نیز این ظرایط رو رعایت کنم ؟ یعنی برای فیلد کد ملی باید Number رو انتخاب کنم ؟ یا فرقی نمیکنه ؟

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

مرسی

[veniz2008]

سلام.
قانون جامعیت دیتابیس میگه که یک طراح دیتابیس وظیفه داره تا قوانینی رو حاکم کنه که جامع بودن و کامل بودن بانک اطلاعاتی رو تضمین کنه.
این درست که شما در برنامه این موارد رو چک می کنید ولی آیا تضمین میدید که در هر شرایطی (اشتباه یا فراموش کردن بخشی از بررسی در سمت برنامه، دسترسی مستقیم به دیتابیس و ...) باز هم اطلاعات بدرستی ثبت بشه؟
قطعا چنین تضمینی وجود نداره. بنابراین حتما باید در سمت دیتابیس هم این کنترل ها لحاظ بشه.
ما در کل دو نوع قوانین جامعیت داریم :
1. قوانین جامعیت عام:
الف) قانون جامعیت موجودیتی : کلید نمیتونه null باشه.(این مورد بصورت اتومات توسط دیتابیس ها چک میشه)
ب) قانون جامعیت ارجاعی : کلید خارجی وابسته به مقادیر کلید اصلی هست در غیر اینصورت باید null درج بشه.
2. قوانین جامعیت خاص:
الف) Check Constraint : مثلا برای فیلد نمره دانشجو که یک عدد بین 0 تا 20 هست و نباید عددی خارج از این محدوده درج بشه.
ب) Unique Constraint : در سیستم دانشجویی که معمولا شماره دانشجویی کلید هست، برای ثبت کد ملی اشخاص که منحصر بفرد هست کاربرد داره.
و ...

[plus]

همونطور که دوستمون گفتن، اگه شما قوانین رو در دیتابیس هم پیاده کنید، در صورتی که سمت فرم به دلیلی قوانین بررسی نشن، جامعیت داده های شما در دیتابیس حفظ میشه...البته پیشنهاد من اینه که اگه نرم افزار شما بیشتر از 7-8 تا فرم داره، این بررسی ها رو در فرم انجام ندین و در لایه دیگه ای انجام بدین...


سلام.
قانون جامعیت دیتابیس میگه که یک طراح دیتابیس وظیفه داره تا قوانینی رو حاکم کنه که جامع بودن و کامل بودن بانک اطلاعاتی رو تضمین کنه.
این درست که شما در برنامه این موارد رو چک می کنید ولی آیا تضمین میدید که در هر شرایطی (اشتباه یا فراموش کردن بخشی از بررسی در سمت برنامه، دسترسی مستقیم به دیتابیس و ...) باز هم اطلاعات بدرستی ثبت بشه؟
قطعا چنین تضمینی وجود نداره. بنابراین حتما باید در سمت دیتابیس هم این کنترل ها لحاظ بشه.
ما در کل دو نوع قوانین جامعیت داریم :
1. قوانین جامعیت عام:
الف) قانون جامعیت موجودیتی : کلید نمیتونه null باشه.(این مورد بصورت اتومات توسط دیتابیس ها چک میشه)
ب) قانون جامعیت ارجاعی : کلید خارجی وابسته به مقادیر کلید اصلی هست در غیر اینصورت باید null درج بشه.
2. قوانین جامعیت خاص:
الف) Check Constraint : مثلا برای فیلد نمره دانشجو که یک عدد بین 0 تا 20 هست و نباید عددی خارج از این محدوده درج بشه.
ب) Unique Constraint : در سیستم دانشجویی که معمولا شماره دانشجویی کلید هست، برای ثبت کد ملی اشخاص که منحصر بفرد هست کاربرد داره.
و ...
موضوعی که میگین درست هست...منتها مسائله ای هست...تکرار بررسی قوانین هم در مثلا لایه Business Logic و هم در دیتابیس، باعث Duplicate قوانین میشه که این موضوع تغییر رو سخت میکنه...مثلا اگه قرار بشه قانون محدودیت نمره از 0 تا 20 به 0 تا 10 تغییر کنه، هم باید Business Logic Layer تغییر کنه و هم Constraint دیتابیس...حالت دیگه اینکه برخی قوانین پیچیده هستن که به سادگی توسط امکانات دیتابیس قابل پیاده سازی در دیتابیس نیستن...اونها رو باید چکار کرد؟
البته، در شرایطی که چندین نرم افزار مختلف به طور کاملا مجزا بدون واسط یکتا روی یک دیتابیس کار میکنن، عدم بررسی قوانین در دیتابیس قطعا مشکل ساز هست، چون یک درگاه یکتایی که با داده ها کار کنه (جز خود دیتابیس) وجود نداره.

[veniz2008]

تکرار بررسی قوانین هم در مثلا لایه Business Logic و هم در دیتابیس، باعث Duplicate قوانین میشه که این موضوع تغییر رو سخت میکنه...مثلا اگه قرار بشه قانون محدودیت نمره از 0 تا 20 به 0 تا 10 تغییر کنه، هم باید Business Logic Layer تغییر کنه و هم Constraint دیتابیس
این دلیل خوبی نیست که بخاطر دو بار چک شدن، جامعیت اطلاعات رو که بسیار مهم هم هست در سمت دیتابیس کنار بزاریم. ضمن اینکه بسیاری حالات ثابت هستن و کمتر دستخوش تغییرات میشن. سال هاست که سیستم نمره دهی بین 0 تا 20 هست و در عمل کمتر اتفاق می افته که این تغییرات رخ بده. هر چند اگر تغییرات هم داشته باشیم باز هم من کنترل اطلاعات حساس رو بهش تاکید دارم. به نظرم این نه تنها یه عیب نیست که یک حسن خیلی خوب هم هست. تضمین یکپارچگی اطلاعات، قابلیت اعتماد نرم افزار رو افزایش میده.
اما معمولا در کنترل اطلاعات در سمت دیتابیس زیاده روی نمیشه و اطلاعات حساس و کلیدی رو چک میکنن. نمره برای یک دانشجو میتونه بسیار حائز اهمیت باشه یا چک کردن تکراری بودن یا نبودن شماره سند در سیستم حسابداری به همین صورت هست ولی ثبت یک تاریخ رو میشه در همون سمت برنامه انجام داد.
گرچه امنیت و سرعت هر دو بسیار مهم هستند ولی من اولویت رو اول به امنیت داده ها میدم و بعد سرعت.

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

[Helmod]

همونطور که دوستمون گفتن، اگه شما قوانین رو در دیتابیس هم پیاده کنید، در صورتی که سمت فرم به دلیلی قوانین بررسی نشن، جامعیت داده های شما در دیتابیس حفظ میشه...البته پیشنهاد من اینه که اگه نرم افزار شما بیشتر از 7-8 تا فرم داره، این بررسی ها رو در فرم انجام ندین و در لایه دیگه ای انجام بدین...

میشه بیشتر توضیح بدین ؟ ممنون میشم