راهنمایی در مورد منطق پیاده سازی جداول سبد خرید و سفارشات و....

سلام
پرسش یک: اطلاعات مرتبط با خرید و فروش و تحویل کالا جز سوابق مالی و حسابرسی محسوب میشن پس لازمه در جایگاه مناسب آون ها رو آرشیو کنید بدون وابستگی با منابع اولیه. مثلا قیمت و دیمانسیون کالا مرتبط در حال تغییر هستند و قطعا با جزییات فروش مغایرت پیدا خواهند کرد پس اطلاعات دیمانسیونی کالا در هر فاکتور فروش باید در جدول مرتبط با سفارشات و فروش یا تسویه حساب هم ذخیره بشه. در واقع اطلاعات مربوط به کالا که در جدول کالا ذخیره می شود برای نشان داده وضعیت موجود و معرفی کالاست و اطلاعاتی که در تیبل های مربوط به سفارشات ذخیره می شود برای سوابق. منظور از اطلاعات کلیدهای روابط نیستند بلکه دقیقا خود اطلاعات.
برای شماره دو هم میتونید از روشهای مختلف استفاده کنید. موجودی دیتابیس فقط زمانی باید کاهش یا افزایش پیدا کنه(متاثر از سفارش کاربر) که یک فاکتور تسویه کامل میشه یا اینکه کنسل یا مرجوعی میشه. حالا برای فرایندش می تونید مدیریت این کار رو در سشن ها انجام بدید یعنی وقتی کاربری کالا رو توی سبد قرار میده محاسبات اون در سشن لحاظ بشه و اختلاف تعداد اونجا نگهداری بشه و پس از تکمیل سفارش یعنی پرداخت از دیتابیس کم بشه برای مثال کاربر x و y هم بستگی به استراتژی فروشگاه و ذنجیره تامین و میزان رسوب کالا در انبار می تونید هم به روشی که توضیح داد عمل کنید هم اینکه اگر توی سبد قرار داشت برای کاربر دوم موجودی صفر بزنید اما از یک طرف محدودیت زمانی برای نگداری سفارش باز برای کاربر اول لحاظ کنید و از طرف دیگه به کاربر دوم پیشنهاد بدید در صورت موجود بودن بهش اطلاع بدید.
برای شماره سه اعمال محدودیت زمانی به نوع جنس بستگی داره مثلا برای معاملات otc ارز دیجیتال شما بیشتر از چند دقیقه مختصر نمیتونید به خریدار زمان بدید برای کالاهای دیگه ممکنه تا نیم ساعت هم زمان بدید اما چند ساعت فکر خوبی نیست، چرا کاربری که تا حد تکمیل سبد پیش اومده و اینقدر تمایل به خرید داره رو به سمتی هدایت کنیم که فاصله با تسویه بیشتر میشه؟ فکر کنید در حالی که سیستم فروش مختل شده همون کاربر در حال بررسی کالای رقباست! همچنین برای سفارشات دو جدول بهتره یکی برای سفارش یکی برای جزییات سفارش ببینید در دنیای واقعی هم همینه شما یک فاکتور دارید یک ریز فاکتور، لیست فاکتور ها در یک جدول و ریز اونها در جدول مرتبط دیگه.
برای شماره 4 هم قطعا بله لازمه.
شماره 5: ببینید وقتی اطلاعات به صورت value نه key توی جدول جزییات سفارش ذخیره شد شما برای ارایه گزارش به کاربر مشکلی نخواهید داشت اما اگر بخواهید پس از فروش در روابط جدولی تغییر ایجاد کنید قطعا برای مدیریت و گزارشات مرتبط با ادمین به مشکل بر میخورید. همچنین باید این رو در نظر بگیرید برای متد حذف باید شرط تعیین کنید و اگر داده ای در جداول دیگر رابطه داره نباید حذف بشه مثلا کاربر تا زمانی قابل حذف هست که تسویه مالی نداشته باشه یا دسته بندی تا زمانی میشه حذف بشه که کالای فروخته شده در مجموعه خودش نداشته باشه.