دوستان خبره برنامه نويس براي اين دو سناريو چه كاري انجام ميديد؟

[vb_nima]

با سلام.
دوستان خبره برنامه نويس در كاراهاتون آيا اين دو سناريو را در نظر ميگيريد يا بيخيالش ميشيد؟ من خودم تو آموزشها و پروژه هاي كوچك ديدم اصلا به اين موارد توجه نمي شه در صورتي كه اين موارد باعث ايجاد ناسازگاري در ديتاهامون ميشه.
اين دو سناريو اينه:
الف- در بيشتر پروژه ها از جداول گروه و محصول استفاده مي كنيم كه كليد جدول گروه را در جدول محصول تكرار ميكنيم تا متوجه بشيم اين محصول جز كدوم گروه هست. و معمولا ميان براي ادمين امكان حذف و درج و ويرايش گروه را ايجاد ميكنند.حالا فرض كنيد مدير يك وبسايت يك فرد عادي مياد يك گروه را حذف ميكنه و با اين كار تمام اون محصولات كه كليد اصلي اين گروه را دارند نامعتبر ميشن و ديگه دسترسي هم بهشون امكان پذير نيست.
ب- معمولا هم براي مشخص كردن اينكه كدوم خريدار چه محصول خريده از يك جدول ميانجي مثلا به نام "سبد" كه كليد اصلي مشتري و كليد اصلي محصول در اون بصورت كليد خارجي هست استفاده ميشه.حال فرضا از جدول محصول يك محصول حذف بشه يا از جدول خريدار يك حريدار حذف بشه در اينصورت جدول سبد دچار ناسازگاري ميشه و مثلا وقتي يك گزارش از سبد گرفته ميشه بايد بجاي كليدهاي اصلي مقادير نام اونها در گزارش بياريم كه در صورت حذف اصلا اون كليدها ديگه معتبر نيستند.

حالا سوالم اينه دوستان اين دوتا سناريو را در كارهاشون مدنظر قرار ميدن؟
اگر قرار ميدن بفرمائيد چه راهكارهايي را اتخاد ميكنيد؟راهكار استاندارد چيه؟

جواب خودم: به نظر خودم دوتا كار ميشه كرد ولي نمي دونم استاندارد هست يانه:
يك: مثلا قبلا از حذف گروه بررسي كنيم اگر محصولي زيرمجموع اون بود به كاربر بگيم كه ابتدا محصولات زير مجموعه را حذف يا منتقل كن سپس حذف كن.
ب- حذف واقعي انجام نديم و مثلا يك فيلد deleted به جدول گروه اصافه كنيم و در صورتي كه گروه را خواستيم حذف كنيم فقط مقدار اين فيلد را true كنيم.

كلا نظر شما چيه؟
ببخشيد طولاني شد.

[dorparasti]

خوب اینم بستگی به سناریو شما داره : اگر بخواید در آینده امکان رستور برای رکورد های پاک شده وجود داشته باشه خوب اونا رو واقعاً پاک نمی کنید و تنها اونا رو به عنوان یک رکورد Delete شده تعیین می کنید ( حالا با هر شکلی ) . تا اگر مدیر خواست رکوردی رو برگردونه این امکان وجود داشته باشه . البته به نظرم موقعیت های کمی هستند که نیاز باشه اطلاعات قابل بازگشت باشه مثل سیستم های حسابداری و ... /

در مورد سوال اولتون اگر بخواید اطلاعات پاک بشن واقعاً ، می تونید بین جدولها ارتباط برقرار کنید و شرط CaseCade Delete رو براش فعال کنید تا با حذف یک رکورد از جدول parent تمام رکوردهای متناظرش از جدوا child حذف بشن . که اغلب همین کارو می کنن البته با یک هشدار به کاربر .

روش استانداردی هم نمیشه گفت وجود داره . همه چی بستگی به نیاز های پروژه داره .

[vb_nima]

خوب اینم بستگی به سناریو شما داره : اگر بخواید در آینده امکان رستور برای رکورد های پاک شده وجود داشته باشه خوب اونا رو واقعاً پاک نمی کنید و تنها اونا رو به عنوان یک رکورد Delete شده تعیین می کنید ( حالا با هر شکلی ) . تا اگر مدیر خواست رکوردی رو برگردونه این امکان وجود داشته باشه . البته به نظرم موقعیت های کمی هستند که نیاز باشه اطلاعات قابل بازگشت باشه مثل سیستم های حسابداری و ... /

در مورد سوال اولتون اگر بخواید اطلاعات پاک بشن واقعاً ، می تونید بین جدولها ارتباط برقرار کنید و شرط CaseCade Delete رو براش فعال کنید تا با حذف یک رکورد از جدول parent تمام رکوردهای متناظرش از جدوا child حذف بشن . که اغلب همین کارو می کنن البته با یک هشدار به کاربر .

درسته در اين روش ركوردهاي وابسته هم حذف ميشه ولي جداقل مطمئنيم كه ديگه "ركورد سرگردان" نخواهيم داشت و ديتابيس ناسازگاري نداره.

روش استانداردی هم نمیشه گفت وجود داره . همه چی بستگی به نیاز های پروژه داره .

چه جالب من فكر ميكردم اگر cascading deltete فعال باشه وقتي يك روكورد از Parent حذف ميشه ارور ميده. پس اين گزينه باعث ميشه كه ركوردهاي وابسته هم حذف بشن.
با اين تفاسير براي پروژه هاي معمولي فكر كنم اين كار مناسب باشه:
بين جدول parent و chaild يك ارتباط ايجاد ميكنيم. و cascading delete را فعال ميكنيم.

بعد زماني كه كاربر عمل delete خواست انجام بده ابتدا كوئري ميزنيم اگر ركورد وابسته وجود داشت به كاربر هشدار ميديم كه با حذف اين ركورد ركوردهاي وابسته هم حذف ميشود ولي اگر تائيد كرد. خودبه خود حذف مي شوند.

ممنون از شركت كردن در بحث و راهنمايي كه كردين.
موفق و مويد باشيد.

[mohsen_f_b]

سلام

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

موفق باشید