راهنمایی در مورد منطق پیاده سازی جداول سبد خرید و سفارشات و....
سلام دوستان وقت بخیر
در مورد منطق پیاده سازی جداول سبد خرید، سفارشات، گزاراشات و... سوال داشتم.
1- مثلا جدول سفارشات چه اطلاعاتی از محصول رو ذخیره کنیم؟ من قبلا فقط آیدی محصول رو ثبت میکردم بعدا ها دیدم قیمت عوض میشه و فاکتور ها بهم میخوره، دوباره بعدش دیدم نام محصول یا تصویر محصول تغییر کنه باز فاکتور تغییر میکنه،
باید چیکار کرد؟ کلا از اون محصول یه بکاپ توی یه جدول دیگه ذخیره کنیم درسته؟ جدولش چجوری میتونه باشه؟
2- برای موجودی محصول کجا باید اعمال بشه؟ وقتی کاربر محصول رو به سبد خرید اضافه کرد باید یکی از موجودی کم بشه؟ یا بعد از تکمیل سفارش؟ مثلا فرض کنین یه محصول داریم که کلا 1 عدد موجودی داره، کاربر x و کاربر y هر دو اون محصول رو به سبد خرید اضافه میکنن، اینجا ما باید محصول رو به کاربری بدیم که زودتر پرداخت میکنه؟ درسته؟
3- سبد خرید، سفارشات، پرداخت ها، همین سه تا جدول کافیه؟ مثلا یه موقع کاربر میاد یه محصول رو با قیمت 1000تومن توی سبد خرید اضافه میکنه و بعدش فروشنده قیمت رو افزایش میده (یا تغییر میده محصول رو)، بعد از چند ساعت که مثلا کاربر میخواد بیاد پرداخت کنه ، چجوری بفهمیم قیمت تغییر داده شده که به کاربر اطلاع بدیم؟ مثلا وقتی فروشنده قیمت رو تغییر داد توی یه جدول دیگه ثبت کنیم فلان محصول تغییر کرده و هر کاربری توی سبد خریدش اون محصول رو داشت وقتی وارد سبد خرید شد یه پیام بهش نشون بدیم؟
4- به جز اطلاعات محصول، مثلا نام کاربر، شماره تماس، آدرس و... ممکنه بعد از سفارش عوض بشه، برای همه اینا باید موقع ثبت سفارش اطلاعات رو توی یه جدول دیگه ذخیره کنیم؟
5- یا مثلا کلید خارجی های داخل لاراول و دیتابیس، یه دسته بندی یا محصولی چیزی حذف بشه ممکنه چیزای دیگه هم که بهش وابسته هستن حذف بشه و پاک بشن و بعدا فاکتور تغییر کنه و بهم بریزه
6- و...
شاید سوالات من بدیهی باشه ولی توی پروژه های مختلف به مشکل خوردم و خواستم از شما دوستان راهنمایی بگیرم که چه مواردی رو باید توی جداول دیتابیس رعایت کنم.
همچنین به صورت کلی اگه نکته ای ، ترفندی ، راهنمایی چیزی دارین ممنون میشم در اختیار من و سایر دوستان بذارین.
تشکر🌹🌺
گزینش سوالات
گفت و گو های مرتبط
دسته بندی سوالات
تگ‌های محبوب
سلام
پرسش یک: اطلاعات مرتبط با خرید و فروش و تحویل کالا جز سوابق مالی و حسابرسی محسوب میشن پس لازمه در جایگاه مناسب آون ها رو آرشیو کنید بدون وابستگی با منابع اولیه. مثلا قیمت و دیمانسیون کالا مرتبط در حال تغییر هستند و قطعا با جزییات فروش مغایرت پیدا خواهند کرد پس اطلاعات دیمانسیونی کالا در هر فاکتور فروش باید در جدول مرتبط با سفارشات و فروش یا تسویه حساب هم ذخیره بشه. در واقع اطلاعات مربوط به کالا که در جدول کالا ذخیره می شود برای نشان داده وضعیت موجود و معرفی کالاست و اطلاعاتی که در تیبل های مربوط به سفارشات ذخیره می شود برای سوابق. منظور از اطلاعات کلیدهای روابط نیستند بلکه دقیقا خود اطلاعات.
برای شماره دو هم میتونید از روشهای مختلف استفاده کنید. موجودی دیتابیس فقط زمانی باید کاهش یا افزایش پیدا کنه(متاثر از سفارش کاربر) که یک فاکتور تسویه کامل میشه یا اینکه کنسل یا مرجوعی میشه. حالا برای فرایندش می تونید مدیریت این کار رو در سشن ها انجام بدید یعنی وقتی کاربری کالا رو توی سبد قرار میده محاسبات اون در سشن لحاظ بشه و اختلاف تعداد اونجا نگهداری بشه و پس از تکمیل سفارش یعنی پرداخت از دیتابیس کم بشه برای مثال کاربر x و y هم بستگی به استراتژی فروشگاه و ذنجیره تامین و میزان رسوب کالا در انبار می تونید هم به روشی که توضیح داد عمل کنید هم اینکه اگر توی سبد قرار داشت برای کاربر دوم موجودی صفر بزنید اما از یک طرف محدودیت زمانی برای نگداری سفارش باز برای کاربر اول لحاظ کنید و از طرف دیگه به کاربر دوم پیشنهاد بدید در صورت موجود بودن بهش اطلاع بدید.
برای شماره سه اعمال محدودیت زمانی به نوع جنس بستگی داره مثلا برای معاملات otc ارز دیجیتال شما بیشتر از چند دقیقه مختصر نمیتونید به خریدار زمان بدید برای کالاهای دیگه ممکنه تا نیم ساعت هم زمان بدید اما چند ساعت فکر خوبی نیست، چرا کاربری که تا حد تکمیل سبد پیش اومده و اینقدر تمایل به خرید داره رو به سمتی هدایت کنیم که فاصله با تسویه بیشتر میشه؟ فکر کنید در حالی که سیستم فروش مختل شده همون کاربر در حال بررسی کالای رقباست! همچنین برای سفارشات دو جدول بهتره یکی برای سفارش یکی برای جزییات سفارش ببینید در دنیای واقعی هم همینه شما یک فاکتور دارید یک ریز فاکتور، لیست فاکتور ها در یک جدول و ریز اونها در جدول مرتبط دیگه.
برای شماره 4 هم قطعا بله لازمه.
شماره 5: ببینید وقتی اطلاعات به صورت value نه key توی جدول جزییات سفارش ذخیره شد شما برای ارایه گزارش به کاربر مشکلی نخواهید داشت اما اگر بخواهید پس از فروش در روابط جدولی تغییر ایجاد کنید قطعا برای مدیریت و گزارشات مرتبط با ادمین به مشکل بر میخورید. همچنین باید این رو در نظر بگیرید برای متد حذف باید شرط تعیین کنید و اگر داده ای در جداول دیگر رابطه داره نباید حذف بشه مثلا کاربر تا زمانی قابل حذف هست که تسویه مالی نداشته باشه یا دسته بندی تا زمانی میشه حذف بشه که کالای فروخته شده در مجموعه خودش نداشته باشه.
سلام دوست عزیز
1 - id - price کافیه. عکس نام عوض بشه باید تو فاکتور هم عوض بشه درستش همینه و حذفم به صورت سافت دیلیت باشه تا محصولم پاک شد مشکلی نباشه.
2 - بعد از اینکه کاربر فرایند خریدشو تکمیل کرد چه آنلاین و چه آفلاین (هر کی زودتر خرید) . ادمین در صورت نیاز موجودیو برمیگردونه.
3 - جداول همین سه تاست (شاید تغییر کنه بر حسب نیاز) . برای تغییر قیمت باید یی ایونتی ایجاد کنی که اگر محصول آپدیت شد جدول Baskets هم آپدیت بشه.
4 - اطلاعات دریافت کننده رو تو جدول factors ثبت کن.
5 - سافت دیلیت استفاده کن یا ازش جلوگیری کن بستگی به خودت داره.