مشکل تعداد موجودی انبار و سبد خرید

[desatir7316]

سلام دوستان
فرض کنید من از یک کالا 20 عدد دارم و توی سبد خرید کاربر A همه این کالا هارو انتخاب می کنه یعنی همون 20 تا و منم تعداد درخواستی رو چک کردم و مشکلی نبوده و حالا آماده ارسال به بانک هستم
توی همین موقع یه کاربر دیگه هم دقیقا همچین درخواستی داره، مقدار درخواستی با موجودی انبار چک می شه و درسته آماده ارسال به بانک
اگه من هردوتا رو بفرستم به بانک خوب 40 تا کالا فروختم در حالی که فقط 20 تا توی انبار هست
مشکلاتی از این قبیل رو چطوری می شه حل کرد؟

ممنون

[Unique]

وقتی کالایی را به سبد خرید اضافه میکنی باید موجودیش را توی سایت کسر کنی (حالا توی query یا هر جوری که موجودی را محاسبه میکنی) البته باید سبد خرید وضعیت داشته باشه و یه جایی (مثلا وقتی میخوای یک موردی را به سبد خرید اضافه کنی) سبد های خریدی که توی وضعیت پرداخت بانکی هستند و مثلا ۱۵ دقیقه ازشون گذشته را به کنسلی تغییر بدی تا تعداد موجودیت دوباره به حالت قبلش برگرده.

به طور کلی باید برای کسر موجودی کالاهای توی سبد خرید یک زمان منطقی بگذاری و وقتی این زمان گذشت کلا سبد خرید کنسل بشه.

[desatir7316]

وقتی کالایی را به سبد خرید اضافه میکنی باید موجودیش را توی سایت کسر کنی (حالا توی query یا هر جوری که موجودی را محاسبه میکنی) البته باید سبد خرید وضعیت داشته باشه و یه جایی (مثلا وقتی میخوای یک موردی را به سبد خرید اضافه کنی) سبد های خریدی که توی وضعیت پرداخت بانکی هستند و مثلا ۱۵ دقیقه ازشون گذشته را به کنسلی تغییر بدی تا تعداد موجودیت دوباره به حالت قبلش برگرده.


همین رو می خواستم با cron job انجام بدم
خوب مثلا بخوام هر یک دقیقه این رو چک کنم غیر منطقی نیست ؟ یا راه اصولیش همینه؟

[under22]

این حالتی که شما میگید برای اکثر فروشگاه ها پیش میاد که مثلا یه کالایی رو شفارش میدی بعد زنگ میزنن میگن موجودی نداریم یا چند روز صبر کنید یا پول رو به حسابتون میریزیم .
البته چند تا کار میتونی بکنی یکیش که دوستمون گفت تو سبد خرید یه مرحله نهایی بزاری وقتی به اون مرحله رسید کوئری بزنی و تعداد رو کم کنی
یا میتونی مثل فروشگاه های دیگه که گفتم حتی دیجیکالا هم این شکلی میشه یعضی موقع ها عمل کنی و به صورت عادی که قبلا گفتی باشی و اگه دو یا چند نفر همان خرید کردند بعد زنگ میزنن میگن موجودی نداریم یا چند روز صبر کنید یا پول رو به حسابتون میریزیم .

[fatima-php]

بنظر من مشتری تا وقتی پول نداده اون کالا متعلق بهش نیست. پس میشه کسر کردن از موجودی دیتابیس رو بگذارین بعد از ثبت فاکتور خرید. درگاههای بانکی متدی برای settle دارن که اگه صدا نزنید، مبلغ برگشت میخوره. میتونید وقتی پرداخت رو verify کردین، چک کنید و اگه موجود بود و از موجودی کسر شد، اونوقت settle رو صدا بزنید وگرنه تراکنش بطور خودکار برگشت میخوره و شما هم فقط یه پیغام عذرخواهی نشون میدین به مشتری که داره میگه: «دیر رسیدی عزیزم»

[desatir7316]

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

[Unique]

راه fatima خوبه اما به نظرم همون راهی که گفتم بهتر انجام میشه. نیازی هم به cron job نداره ! وقتی مقدرای را به سبد خرید هر کسی اضافه میکنید سبد خرید هایی که از زمان ۱۵ دقیقه رد شدن و خبری از پرداخت نشده را کنسل کنین.

[n0o0b_sina]

خب جناب Unique (http://barnamenevis.org/member.php?11933-Unique)، اگه ادمین بخواد موجودی رو کم یا زیاد کنه اونوقت تکلیف چیست؟ فرض کنید 10 تا تراکنش کنسل شده وجود داره، موجودیه فروشگاهم ادمین به صورت دستی به صفر تغییر داده!! خب وقتی ما اینارو برگشت میزنیم باز همون آش و همون کاسه!
راه fatima-php (http://barnamenevis.org/member.php?360548-fatima-php) فقط برای یک نوع محصول کاربرد داره

[Unique]

خب جناب Unique، اگه ادمین بخواد موجودی رو کم یا زیاد کنه اونوقت تکلیف چیست؟ فرض کنید 10 تا تراکنش کنسل شده وجود داره، موجودیه فروشگاهم ادمین به صورت دستی به صفر تغییر داده!! خب وقتی ما اینارو برگشت میزنیم باز همون آش و همون کاسه!

ببینین ، موجودی را ما با احتساب سبد های خرید پرداخت شده و کنسل نشده ای که ۱۵ دقیقه از روشون نگذشته حساب میکنیم. مثلا از یک محصول ۱۰ تا داریم و ۶ تاش در حال حاضر درگیر ۴ تا سبد خرید هست که هنوز ۱۵ دقیقه ازش نگذشته و پرداخت هم نشده. خوب اگر حالا ادمین تصمیم بگیره دستی تغییری بده فقط توی اون ۴ مورد میتونه دخل و تصرف کنه مگر اینکه زمان ۱۵ دقیقه تموم بشه. کلا مهم نیست دستی باشه یا کسی آنلاین درخواست بده مهم اینه که حواسمون به خرید های کنسل نشده و ۱۵ دقیقه نگذشته باشه ! اصلا کنسلی ها که مهم نیستن و کنسل شدن و تموم ! شما باید موجودی را در لحظه برای هر درخواست درست محاسبه کنی.

fatima هم کلا میگه اگه در زمان برگشت از بانک برای هر محصولی توی سبد خرید کسری داشتی (یعنی در این حین کسی خریده بود) کلا خرید را reverse کن و بگو مثلا فلان محصول و فلان محصول از تعدادش کم شده و حتی میتونی خودت هم اتوماتیک سبد را تغییر بدی. راه حل ایشون در کل شدنیه و مشکلی پیش نمیاد به شرطی که جداول درگیر را به موقع lock کنی. ربطی به یک محصول و چند محصول هم نداره و مشکلش اینه که اگه خیلی خرید همزمان داشت هباشین مشتری ممکنه دلخور بشه.

[fatima-php]

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

[m.esmaeilzadeh]

اول بگم که در سناریوهای فروش علمی و حرفه ای چرخه تامین که بیشتر خارج ایران پیاده سازی میشن مشکلات تامین کالا تقریبا به زیر 10 % حتی جاهایی به 0 % میرسه !!!
ولی تو ایران چون اکثرا همه چیز غیر اصولی و تکریم ارباب رجوع در آخرین مرحله اولویت های سیستم های مختلف هست با تماس های تلفنی که با مشتری دارن و ایجاد یک خواب زمانی یا اصطلاحا ایجاد یک وقفه تامین همه چیز رو سر هم میآرن و ملت ما عادت ندارن زیاد شکایت کنن و کاری به جایی نمیرسه :چشمک:
بهترین راه هم نوشتن یک قانون برای فروشگاه هستش که اگر مثلا تا فلان زمان تسویه نکردید رزرو سبد خرید شما به کسی دیگه تعلق میگیره و با استفاده از cron job یا روش های دیگه میتونید خرید توسط کاربران دیگه رو ممکن بسازید !!!

[fatima-php]

خب این میشه ولی مشتریو عصبانی میکنه فرض کن از 10 تا محصول یکیش فقط موجودی نداره اونوقت ما باید کله پولو برگشت بزنیم، و مشتری دوباره باید فرآیند خرید (حالا هرچی که باشه) رو طی کنه!
عجب دلیلی "ادمین حواسش باشه بره چک کنه " :قهقهه: عزیزم تعداد خرید و فروش بالاست یکی 2 تا نیست که ادمین بتونه هر 15 دقیقه بره چک کنه فرض بر این که چک کرد، ممکنه بعد از چک کردنش یکی از رکورد ها برگشت بخوره دوباره موجودی بیشتر بشه
خوده دیجی کالا من از دوستم پرسیدم گفت زنگ میزنه به مشتریاش، یعنی اونا هم راه حل نداشتن؟ :متفکر:

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

1- فروش دستی
2- خراب شدن کالا (در کالاهای تاریخ انقضا دار و...)

حالا لازم هم نیست توی دیتابیس بره دستی چک کنه. میتونه موقعی که میخواد تعداد رو کم کنه، توی پنل مدیریت ببینه مثلاً اگه 14 تا موجودی داریم، 10 تاش الان در وضعیت رزرو هست. حالا اگه دلش خواست اونا رو هم حذف کنه، دیگه خودش باید از مشتری عذرخواهی کنه و زنگ بزنه و... ولی اگه فقط میخواد 4 تا رو کم کنه، لازم نیست چون اون ده تای رزرو، اگه خرید بشن موجودی میشه 0 و اگه خرید نشن هم دوباره برمیگردن به موجودی اصلی.

دیجی کالا رو هم اینقدر بزرگ نکنید. درسته که سایت بزرگیه (ازنظر تعداد مشتری و محصول و آمار فروش) ولی ازنظر ساختاری هنوزم برخی جاهاش مهندسی نشده است. از اسمهای بزرگ نترسین.

[Keramatifar]

سلام دوستان
فرض کنید من از یک کالا 20 عدد دارم و توی سبد خرید کاربر A همه این کالا هارو انتخاب می کنه یعنی همون 20 تا و منم تعداد درخواستی رو چک کردم و مشکلی نبوده و حالا آماده ارسال به بانک هستم
توی همین موقع یه کاربر دیگه هم دقیقا همچین درخواستی داره، مقدار درخواستی با موجودی انبار چک می شه و درسته آماده ارسال به بانک
اگه من هردوتا رو بفرستم به بانک خوب 40 تا کالا فروختم در حالی که فقط 20 تا توی انبار هست
مشکلاتی از این قبیل رو چطوری می شه حل کرد؟

ممنون

کاربرد Transaction ها در برنامه نویسی (http://barnamenevis.org/showthread.php?495890-Class-%D9%87%D8%A7-%D9%88-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7-%D9%88-%D8%AA%DA%A9%D9%86%DB%8C%DA%A9-%D9%87%D8%A7%DB%8C-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF%DB%8C-%D8%AF%D8%B1-PHP&p=2224894&viewfull=1#post2224894)

[desatir7316]

کاربرد Transaction ها در برنامه نویسی (http://barnamenevis.org/showthread.php?495890-Class-%D9%87%D8%A7-%D9%88-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7-%D9%88-%D8%AA%DA%A9%D9%86%DB%8C%DA%A9-%D9%87%D8%A7%DB%8C-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF%DB%8C-%D8%AF%D8%B1-PHP&p=2224894&viewfull=1#post2224894)
درسته با به کاربردن transaction ها می شه بهتر مدیریت کرد ولی مشکلی اصلی موجودی فعلی سبد خرید هست که وقتی چند کاربر دارن درخواست همزمان کالا می دن و جمع اون تعدادها از کل می موجودی انبار بیشتره و اینکه هر کاربر توی اون لحظه می تونه توی مرحله خاصی از خرید و سبد خرید باشه
یکی مثلا رفته برای پرداخت ولی پرداخت انجام نشده، یا خودش پشیمون شده و ...
یکی داره فعلا بازم کالا انتخاب می کنه
یکی ...

[Unique]

جناب کرامتی فر ، نمیدونم منظور شما از گفتن "کاربرد Transaction ها در برنامه نویسی" دقیقا به کجای مشکل ایشون بر میگرده اما Transaction در زمانی به کار میان که ما میخوایم تغییراتی متوالی و مرتبط را توی پایگاه داده انجام بدیم و اگه مشکلی پیش اومد تغییرات را rollback یا به حالت اول برگردونیم. در مثال ایشون اصلا قرار به ثبت چیزی نیست. ایشون میخوان راه حلی پیدا کنن که اگه کسی مقداری از موجودی را توی سبد خرید پرداخت نشده داشت و شخص دیگه ای درخواستش را داشت با مشکلات فروش اضافه بر موجودی روبرو نشن. نمیگم transaction ها جایی در این پروسه ندارن اما این تاپیکی که اشاره کردین هم مشکلی را برای ایشون حل نمیکنه.

خود Desatir که توی بحث شرکت نمیکنه اما مهمه کسانی که این پست را میخونن به اشتباه نیفتن.


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

1- فروش دستی
2- خراب شدن کالا (در کالاهای تاریخ انقضا دار و...)

حالا لازم هم نیست توی دیتابیس بره دستی چک کنه. میتونه موقعی که میخواد تعداد رو کم کنه، توی پنل مدیریت ببینه مثلاً اگه 14 تا موجودی داریم، 10 تاش الان در وضعیت رزرو هست. حالا اگه دلش خواست اونا رو هم حذف کنه، دیگه خودش باید از مشتری عذرخواهی کنه و زنگ بزنه و... ولی اگه فقط میخواد 4 تا رو کم کنه، لازم نیست چون اون ده تای رزرو، اگه خرید بشن موجودی میشه 0 و اگه خرید نشن هم دوباره برمیگردن به موجودی اصلی.


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

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


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


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


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

[imohammad]

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

فک کنم این روش شدنی باشه

[fatima-php]

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

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

درمورد حذف سفارشهای معلق با کران جابز هم بنظرم باید فاصله زمانی رو کوتاه درنظر بگیریم چون ممکنه کسانی از این وقفه استفاده کنن و همونطور که میشه حدس زد، تمام موجودی رو در حالت تعلیق نگه داره و فروشگاه رو از کار بندازه. حتی میتونن با یک روبات، اینجور کارها رو انجام بدن. پس باید یه مکانیزمی هم برای سفارشهای معلق درنظر بگیرین. مثلاً اگه یک نفر تعداد دفعات مشخصی سفارش داد ولی قطعی نکرد، تا 24 ساعت دیگه نتونه خرید ثبت کنه (با IP یا کوکی یا هر مکانیزم دیگه که جای بحثش اینجا نیست چون به موضوع تاپیک ربطی نداره).

[Unique]

درمورد حذف سفارشهای معلق با کران جابز هم بنظرم باید فاصله زمانی رو کوتاه درنظر بگیریم چون ممکنه کسانی از این وقفه استفاده کنن و همونطور که میشه حدس زد، تمام موجودی رو در حالت تعلیق نگه داره و فروشگاه رو از کار بندازه. حتی میتونن با یک روبات، اینجور کارها رو انجام بدن. پس باید یه مکانیزمی هم برای سفارشهای معلق درنظر بگیرین. مثلاً اگه یک نفر تعداد دفعات مشخصی سفارش داد ولی قطعی نکرد، تا 24 ساعت دیگه نتونه خرید ثبت کنه (با IP یا کوکی یا هر مکانیزم دیگه که جای بحثش اینجا نیست چون به موضوع تاپیک ربطی نداره).

البته همونظور که گفتم نیاز به cron job نیست و میشه همون کدی که میخوایم بگذاریم توی cron job که مثلا بیا سبد خرید هایی که مثلا ۱۵ دقیقه ازش گذشته و بلاتکلیف هست را کنسل کن در زمان اضافه کردن هر کالا به سبد خرید هر کسی انجام بدیم ، درست هکه تعداد query ها میره بالا اما دیگه نیاز نیست نگران ربات ها یا از کار افتادن cron job باشیم.

[Keramatifar]

جناب کرامتی فر ، نمیدونم منظور شما از گفتن "کاربرد Transaction ها در برنامه نویسی" دقیقا به کجای مشکل ایشون بر میگرده

دوست عزیز
من نگفتم، پست بنده لینک است، اگر به لینک مراجعه می کردید متوجه میشدید که به کجا یا کجاهای مشکل بر می گرده
1- سوال:


فرض کنید من از یک کالا 20 عدد دارم


مثال بنده:


حساب بانکی شخصی، از نوع حساب جاری که دارای دسته چک است را در نظر می گیریم
موجودی فعلی: 2.000.000 ریال


2- سوال:


توی سبد خرید کاربر A همه این کالا هارو انتخاب می کنه یعنی همون 20 تا و
منم تعداد درخواستی رو چک کردم و مشکلی نبوده و حالا آماده ارسال به بانک هستم
توی همین موقع یه کاربر دیگه هم دقیقا همچین درخواستی داره

مثال بنده:


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




3-سوال:


اگه من هردوتا رو بفرستم به بانک خوب 40 تا کالا فروختم در حالی که فقط 20 تا توی انبار هست


مثال بنده:


اگر صندوقدار زودتر دکمه تسویه رو بزنه
چک پاس میشه و موجودی حساب میشه: 1.000.000 ریال
بنابراین وقتی شخص جلوی عابر بانک دکمه تایید رو می زنه پیغام "عدم وجود موجودی کافی" رو می بینه، چرا؟
مبلغ فاکتور + کارمزد کارت به کارت بانک < موجودی فعلی (بعد از پاس شدن چک)
1.000.0000 +7.000 > 1.000.000
اگر شخص جلوی عابر بانک زودتر دکمه تایید رو بزنه:
صندوقدار بانک با پیام "برگشت چک به دلیل عدم تامین موجود کافی" روبرو میشه، چرا؟
موجودی فعلی حساب (بعد از انتقال کارت به کارت) < مبلغ چک
1.000.0000 +7.000 > 1.000.000



درسته با به کاربردن transaction ها می شه بهتر مدیریت کرد ولی مشکلی اصلی موجودی فعلی سبد خرید هست
لطفا به توضیحات ابتدای مثال بنده توجه بفرمایید:





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

[n0o0b_sina]

ما transaction رو موقع ارسال کاربر به درگاه باید start بزنیم ولی rollback و commit رو بعد از برگشت از درگاه آیا این امکان پذیره؟
اگه در این میان یه نفر دیگ بره به درگاه و یه transaction جدید ثبت بشه ما transaction نفره قبلی رو میتونیم rollback و commit کنیم؟
یا اصلا بعد از رفرش صفحه و انتقال به یه سایت دیگه، اینا باقی میمونه؟
---
فکر کنم جوابه سوالای بالا خیر باشه، البته دوستان با تجربه و مدیر محترم بهتر میتونن راهنمایی کنن منو
البته باز من فرضو بر این میزارم که جواب بله باشه
خب ما rollback کردیم و مقدار کسر شده از موجودی انبار رو برگشت زدیم تکلیفه مبلغ پرداختی کاربر چی میشه؟

[Unique]

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


اتفاقا لینک شما را کامل خوندم و به همین جهت گفتم راه حلی براش ارائه ندادین ، شما یک سناریو مطرح کردین و صورت راه حل را Transaction معرفی کردین. اصلا نگفتین این rollback و commit را کجا و چه زمانی استفاده کنه ؟! توی مثال شما transaction ها مشکل را حل نمیکنن چون وقتی شما در مرحله آخر که میخواین commit کنین اگه query هایی که برای محاسبه موجودی زده شده همزمان باشن برنامه به اشتباه هر دو را commit میکنه و به کسری میخوره (موجودی منفی میشه) ! Transaction زمانی کاربرد داره که به علت خطایی یا مشکلی در تکمیل کار (Batch Operation) بخوایم همه چیز به عقب برگردونیم و دردی از مشکلات ناشی از همزمانی درخواست ها دوا نمیکنه ، برای ممانعت از همزمانی باید جداول را Lock کرد.

البته transaction ها موضوع خیلی مهمی هستند و باید بدونیم کی و چطوری ازشون استفاده کنیم.

همونطور هم که سینا اشاره کرد شما اصلا متوجه نیستین که داریم تحت وب عمل میکنیم و نمیتونید توی یک صفحه transaction را ایجاد کنید و توی یک صفحه دیگه اون را commit یا rollback کنید. خواهشا تمنا دارم اگه چنین کاری یه صورت ابتدایی امکان پذیره و نه مثلا Distributed Transaction Coordinator ها که کلی دنگ و فنگ میخواد ، حتما توی انجمن آموزش بدین تا من و دوستان دیگه یاد بگیریم.

امیدوارم حتما پاسخ ابهامات را بدین تا در رشد و ارتقاء انجمنی که تحت مالکیت خودتون هست کمک کنید.
یا حق

[farzad-kh]

به نظر من یه جدول دیگه بیار این وسط مثلا موجودی رو که میخواد نشون بده موجودی کل - موجودی رزرو باشه اینجوری کاربر وقتی میخواد سفارش بده فقط تعداد کالایی رو میبینه که سفارش نداده اصن نمیخواد از cron job استفاده کنی به نظرم هر زمان که وارد سایت یا بسته به بار پردازشی سیستمت داره چک کنه توی جدول رزرو اونایی که زمانشون از 20 دقیقه گذشته رو حذف کنه اما این روش یه مشکلی داره کاربر خریدار همزمان جنسای دیگه هم میخره و زمان بیشتری توی سایته با این روش که دوستان گفتن و من گفتم سبد از اول لیست خالی میشه... میتونی یه فیلد به جدول رزرو اضافه کنه به عنوان آیدی سبد خرید و آخرین تغییر زمانی سبد خرید رو چک کنی اینجوری میتونی چه یک کالا چه چندکالا رو چون دارای دسته بندی زمانی(سبد) هست رو آزاد یا ادامه فرآیند بدی... تغییرات سبد هم که فقط توی جدول رزرو اعمال میشه و با توجه به اصل موجودی کل - موجودی رزرو میتونی از این اشکال جلوگیری کنی... پس شد دو تا جدول این وسط جدول رزرو که کد کالا و تعداد و کد سبد خرید رو داره و سبد خرید هم که کد کاربر و آخرین تغییر زمانی رو داره(اینا مهمه) ... به نظرم قبل عمل با طراحی پایگاه داده مناسب میشه مشکلی رو گفتی حل کرد... البته دید من این بود امیدوارم راه بهتر باشه یا دوستان دید من رو اصلاح کنن

[nazanin_asadi_1]

سلام
بحث خوبی هستش و امیدوارم که به جواب برسه

هر کسی روش و اصول خودش رو داره

به نظر من تا زمانی که پول پرداخت نشده نباید موجودی رو کم کنی
چون عمل رویت جنس و پرداخت مبلغ جنس در حالت فیزیکی با مجازی کلا جدا هستش

مثلا ما 20 عدد جنس داریم و سه تا کاربر هر کدوم 7 تا سفارش میدن ما به ترتیب هر تراکنش مالی که تائید بشه (پرداخت بشه ) رو میاییم مقدارش رو از موجودی کم میکنیم
اینجوری کاربر سوم بعد از پرداخت بهش میگیم شش تا جنس باقی مونده و روند تماس و کندی ایشون در پرداخت مبلغ ملاک هستش

حالا چه ادمین بیاد دستی این موجودی رو کم کنه یا جنس به فروش برسه هیچ تفاوتی نداره
ادمین بیاد دستی اون 20 تا رو صفر کنه خب بعد از پرداخت مبلغ توسط مشتری میاییم موجودی رو چک میکنیم می بینیم موجودی نداریم دلیل نمیشه که ادمین بره مرتب چک کنه
اصلا تصور کنید توی فروشگاه فیزیکی هستین جنسی رو انتخاب کردین و پولشو دادین و یهو متوجه میشین جنس خرابه چه پروسه ای طی میشه ؟
اگه موجودی دیگه ای داشته باشن بهتون میدن
در غیر این صورت پولو پس میدن اما و اگری نمی مونه این وسط

این که میگم تا زمانی که تائید نشده نباید دست به موجودی بزنید به این دلیل هستش که به صورت عملی خودم دیدم
تصور کنید 20 تا جنس دارین توی فروشگاه حالا دوتا کاربر میان هر کدوم 10 تا انتخاب میکنن شما میایین موجودی رو صفر میکنی و کاربر میره تا پرداخت حالا به علت نبود موجودی (نداشتن پول توی حسابش ) نمی تونه پرداخت رو تکمیل کنه
در همین حین یه مشتری دیگه هم میخواد اون محصول رو بخره ولی موجودی میزنه صفر آیا این منطقی هستش ؟

ببینید اصلا همیشه باید اول از مشتری پولو بگیری بعد اگه جنس موجود نبود پولو بهش پس بدی تا این که هی موجودی رو کم کنی بعد به علت تکمیل نشدن فرایند پرداخت بیایی موجودی رو کم و زیاد کنی

[fatima-php]

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

[Unique]

راستش من با nazanin و fatima موافق نیستم. اما شاید اگه خودم فروشگاه آنلاین داشتم نطر دیگه ای داشتم. معمولا وقتی آدم نفه و سودش به خطر میفته تصمیمات دیگه ای میگیره.
کلا میشه سیاست کاری را توی سایت نوشت.

[desatir7316]

درمورد سفارشهایی که چند کالا دارن هم میشه وقتی مشتری به بانک مراجعه میکنه برای پرداخت، در برگشت بهش بگیم این تعداد موجود بود و ثبت شده (از موجودی کم کردیم ولی هنوز Settle نزدیم) و بقیه رو یکی دیگه زودتر از شما خرید (زمانی که توی درگاه بانک بودین و لفت دادین!). حالا اگه همینا رو میخواین روی تکمیل خرید بزنید تا سفارش نهایی بشه و Settle رو صدا میزنیم و اگه نمیخواین هم فلان دکمه رو بزنید (یا هیچ کاری نکنید) تا سیستم خودش سفارش رو برگشت بزنه (Settle صدا زده نمیشه).
این به نظرم جالب اومد
اگه کاربر ببینه جند قلم از جنساش موجود نیست، یه دکمه می ذاریم که کلا از خرید پشیمون شده و می خواد همه رو پس بده
یه دکمه که اشکال نداره و ولی مابقی پول رو توی اولی فرصت به حسابش ریخته بشه

[m.esmaeilzadeh]

آقای Unique بنده بارها دیدم که شما جو تاپیک های دیگران رو متشنج و همیشه سعی میکنی دیگران رو بی سواد جلوه بدی و فکر می کنی خدای برنامه نویسی و آنالیز سیستم های تحت وب و نرم افزاری هستی که برای آدمی به سن شما که یادمه متاسفانه قبلا مدیر این تالار هم بودی خیلی زشت و ناپسند هستش و اینبار هم به آقای کرامتی فر ایراد گرفتی که به نظر من آدم خوبه کمی قدر شناس باشه و شخصیت خودش رو حفظ کنه و با پرخاش یا تمسخر بیجا دیگران سطح سواد کسی بالا نخواهد رفت !!!
نه آقای عزیز , در علوم کامپیوتری دست بالای دست بسیار هست و خود من که چند سال هست برنامه نویسی میکنم باز هم میبینم بچه هایی هستن که از من سطح سوادشون در علوم کامپیوتری بیشتره و این چند روزه مدام دارم مطالعاتم رو از سر میگیرم و حتی سوالاتم رو داخل این انجمن می پرسم ....

در مورد سوال این کاربر هم من توضیح دادم یکبار ولی باز یک مثال میزنم : در یک پروژه ای برای فروش محصولات و تامین مایحتاج کارکنان دولتی برای یک بخش بخصوص طرف حساب ما 300 هزار خانوار بود که خودتون حساب کنید هر کدام از این ها مثلا میخواستن یک رب گوجه فرنگی تبرک یا کیسه برنج 10 کیلویی محسن بخرند چه داستانی سر موجودی انبار مجموعه که تامین کار رو بر عهده داشت می آمد و مدام همه استرس زنجیر چرخه تامین رو داشتن !!!!
برای پروژه ای به این بزرگی که در دقیقه ده ها تراکنش خرید وجود داشت از یک بنده خدایی که تحصیلاتش دکترا بود و خارج ایران بیزینس و تجارت الکترونیک خونده بود کمک گرفتن !!!
کل این مشکلات که شما می فرمایید و موجودی ها تطابق نداشت رو با الگوریتم های خاص و علمی برای سطح فروش حل کردن و اصلا حل مشکلات به برنامه نویسی فروشگاه ربطی نداشت و بحث نرم افزاری رو با یک قانون برای وب سایت که رزرو و انقضاء سبد خرید و فاکتور بسته شده صرفا 1 ساعت است حل شد و دیگه مشکلی نیست !!!
یعنی بعد از یک ساعت در صورتی که محصول مورد نظر جزء اولویت های قرمز یا زرد تامین بود به کاربر اخطار میداد که سریعا تسویه کنه و غیره ....
سیستم هایی مثل دیجی کالا و فینال هم مدام آفلاین با مشتریان در تماس هستن و به اصطلاح وقفه یا خواب در چرخه تامین ایجاد می کنند و یا بخضی از سفارش رو طبق اجازه مشتری حذف و بقیه موجود رو ارسال میکنند ...
امیدوارم توضیحاتم مفید بوده باشه :لبخندساده:

[Keramatifar]

اتفاقا لینک شما را کامل خوندم و به همین جهت گفتم راه حلی براش ارائه ندادین ، شما یک سناریو مطرح کردین و صورت راه حل را Transaction معرفی کردین.
اصلا نگفتین این rollback و commit را کجا و چه زمانی استفاده کنه ؟!
توی مثال شما transaction ها مشکل را حل نمیکنن
چون وقتی شما در مرحله آخر که میخواین commit کنین اگه query هایی که برای محاسبه موجودی زده شده همزمان باشن
برنامه به اشتباه هر دو را commit میکنه


دوست عزیز
الان متوجه شدم که شما پست من رو خوندید، اما با توجه به قسمتی هایی که Bold کردم و بخصوص قسمتی که با رنگ قرمز مشخص کردم
شما نیاز به مطالعه پایه ای و بیسیک در مورد Transaction ها دارید
لطفا سری به تالار تخصصی بانک های اطلاعاتی در برنامه نویس بزنید
یا به سایت MySql مراجعه کنید، یا حتی از یک برنامه نویس (حتی مبتدی) که حداقل 1 بار Transaction نوشته است و بخواهید
براتون توضیح بده که Transaction چیست و مفهوم ACID Atomicity (http://en.wikipedia.org/wiki/Atomicity_%28database_systems%29), Consistency (http://en.wikipedia.org/wiki/Consistency_%28database_systems%29), Isolation (http://en.wikipedia.org/wiki/Isolation_%28database_systems%29), Durability (http://en.wikipedia.org/wiki/Durability_%28database_systems%29) در Transaction چه معنایی دارد
البته حتی از ترجمه Isolation هم کاملا مشخص است که هیچوقت :
برنامه به اشتباه هر دو را commit نمیکنه

[fatima-php]

فکر کنم منظور Unique اینه که دو کاربر همزمان وارد بشن یعنی دو درخواست همزمان داشته باشیم و توی هرکدوم، یک Transaction که میاد و درصورتی که خطایی وجود نداشته باشه، Commit میشه. مسئله اصلی اینه که توی این سناریو که دوستان مطرح کردن، ازنظر منطقی و تئوریک مشکلی وجود نداره که بخواد مانع از کامیت شدن ترنزکشن بشه و درخواستهای هرکدوم با موفقیت ثبت میشه و مشکل اصلی اونه که محدودیت ازنظر منطقی توی برنامه وجود داره (تعداد کالا منفی میشه) و این مسئله رو با ترنزکشن نمیشه حل کرد. ازطرفی وضعیت ترنزکشن رو تا جایی که میدونم نمیشه توی درخواستهای مختلف نگه داشت. مثلاً کاربر A بعد از ثبت خرید میره به درگاه بانک و اونجا لفت میده و تو این فاصله کاربر B میاد کالا رو میخره. حالا توی برگشت، تعداد موجودی سفارش داده شده توسط کاربر A رو از موجودی کم کنه درحالی که موجودی قبلاً توسط کاربر B کم شده و درنتیجه موجودی منفی میشه. لطفاً راهنمایی کنید که اینجا ترنزکشن چطور میخواد به حل مسئله کمک کنه.

[fatima-php]

شما که اینقدر قدیمی هستی چطور نفهمیدی که ایشون مدیر قبلی این تالار نبودن؟ خدا رو شکر که خودتون حرفهای خودتون رو نقض میکنید!

[nazanin_asadi_1]

فکر کنم منظور Unique اینه که دو کاربر همزمان وارد بشن یعنی دو درخواست همزمان داشته باشیم و توی هرکدوم، یک Transaction که میاد و درصورتی که خطایی وجود نداشته باشه، Commit میشه. مسئله اصلی اینه که توی این سناریو که دوستان مطرح کردن، ازنظر منطقی و تئوریک مشکلی وجود نداره که بخواد مانع از کامیت شدن ترنزکشن بشه و درخواستهای هرکدوم با موفقیت ثبت میشه و مشکل اصلی اونه که محدودیت ازنظر منطقی توی برنامه وجود داره (تعداد کالا منفی میشه) و این مسئله رو با ترنزکشن نمیشه حل کرد. ازطرفی وضعیت ترنزکشن رو تا جایی که میدونم نمیشه توی درخواستهای مختلف نگه داشت. مثلاً کاربر A بعد از ثبت خرید میره به درگاه بانک و اونجا لفت میده و تو این فاصله کاربر B میاد کالا رو میخره. حالا توی برگشت، تعداد موجودی سفارش داده شده توسط کاربر A رو از موجودی کم کنه درحالی که موجودی قبلاً توسط کاربر B کم شده و درنتیجه موجودی منفی میشه. لطفاً راهنمایی کنید که اینجا ترنزکشن چطور میخواد به حل مسئله کمک کنه.

والا من هر چقدر فکر میکنم نمی تونم درک کنم که این عمل چه ربطی به تراکنش داره آخه

در حالت فیزیکی هر کسی که زودتر پولو جنس رو بده جنس رو بهش میدیم و تا زمانی که کسی پولو نداده مریض نیستیم که بگیم اون جنس تموم شده

در فروشگاه هم دقیقا همینجوره
اصلا قضیه پرداخت با قضیه کسر از موجودی و ثبت در فاکتور کلا جدا هستش

مشتری جنس رو انتخاب میکنه و فاکتور میکنه
حالا اگه پرداخت کرد فاکتور تائید میشه و از موجودی کسر میشه و به کاربر ارسال میشه **** اگه پردخت نشد همجنان توی موجودیش میمونه و فاکتور رو هم همونجوری نگه میداریم
توی یکی از پروژه ها این مشکل وجود داشت واسه همین اومدم بازه زمانی سه ساعته (بسته به سیاست شرکت ) تعیین کردم
به این صورت که فاکتور تا سه ساعت معتبر بود بعد از سه ساعت دیگه اعتباری نداشت

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

من کاری به سواد داشتن نداشتن کسی ندارم فقط دنبال بهترین روشها و الگوها واسه طراحی هستم اینجا هم چون دیدم بحث شده اومدم نظر دادم

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

[Unique]

مشتری جنس رو انتخاب میکنه و فاکتور میکنه
حالا اگه پرداخت کرد فاکتور تائید میشه و از موجودی کسر میشه و به کاربر ارسال میشه **** اگه پردخت نشد همجنان توی موجودیش میمونه و فاکتور رو هم همونجوری نگه میداریم
توی یکی از پروژه ها این مشکل وجود داشت واسه همین اومدم بازه زمانی سه ساعته (بسته به سیاست شرکت ) تعیین کردم
به این صورت که فاکتور تا سه ساعت معتبر بود بعد از سه ساعت دیگه اعتباری نداشت

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

سناریو شما مشکلی نداره ، موضوع اینه که توی سناریو شما هر کی زودتر پول بده جنس را میگیره و ممکنه کسی زودتر درخواست داده باشه اما چون اونی که زودتر پول داده جنس را گرفته بی کلاه بمونه. موضوع transaction ها هم توی این بحث خیلی جایی نداره (میشه استفاده کرد اما نیاز نیست). در واقع شما وقتی میخوای موجودی بگیری باید جدول های دخیل در محاسبه موجودی را lock کنی ، موجودی بگیری و ادامه بدی. البته سوال کننده بحثش کدنویسی نبود.

سوال کننده میخواد بدونه :

وقتی از کالایی ۲۰ تا داریم و کسی ۲۰ تاش را سفارش میده و در همون زمان یک نفر مثلا ۵ تا دیگه از کالا می‌خواد من چه کاری میتونم بکنم :

دو تا راه حل داری :

۱ - وقتی یک نفر ۲۰ تا کالا میریزه توی سبد خرید شما اون ۲۰ تا کالا را در محاسبه موجودیت برای کاربر دوم کم کنی در نتیجه کاربر دوم نمیتونه چیزی بخره. حالا اگه کاربر اول که ۲۰ تا را سفارش داده تا ۱۵ دقیقه عملیات پرداخت را انجام داد و سفارش نهایی شد که هیچی وگرنه سبد طرف را کنسل میکنی و ۲۰ تا بر میگرده توی موجودیت

۲ - وقتی نفر اول ۲۰ تا کالا میریزه توی سبد خریدش شما اون ۲۰ تا کالا را در محاسبه موجودیت برای کاربر دوم کم نکنی در نتیجه کاربر دوم میتونه ۵ تا را بریزه توی سبدش. حالا اگه کاربر اول سبد خریدش را پرداخت کرد خوب کاربر دوم در زمان برگشت از بانک نمیشه ۵ تا کالا بهش بدیم چون موجودی نداریم. اگه هم دومی زودتر پرداخت کرد خوب نفر اول دیگه نمیتونه ۲۰ تا کالا بخره !

اگه از حالت دوم استفاده میکنی حتما قبل از انتقال به درگاه پرداخت و قبل از settle کردن موجودی را بررسی کنید تا زیاد از حد موجودی نفروشین. میتونین هم پول هر دو را بگیرین و فوقش اونی که کالا گیرش نیومده را راضی کنین.

انقدر که lock کردن جداول توی این کار اهمیت داره transaction نداره ! با استفاده از transaction مطمئن میشین اگه خطایی پیش اومد همه چی به حالت اول بر میگرده. همین‌!

جناب Desatir حالا انتخاب با شما !

[under22]

سناریو شما مشکلی نداره ، موضوع اینه که توی سناریو شما هر کی زودتر پول بده جنس را میگیره و ممکنه کسی زودتر درخواست داده باشه اما چون اونی که زودتر پول داده جنس را گرفته بی کلاه بمونه. موضوع transaction ها هم توی این بحث خیلی جایی نداره (میشه استفاده کرد اما نیاز نیست). در واقع شما وقتی میخوای موجودی بگیری باید جدول های دخیل در محاسبه موجودی را lock کنی ، موجودی بگیری و ادامه بدی. البته سوال کننده بحثش کدنویسی نبود.

سوال کننده میخواد بدونه :

وقتی از کالایی ۲۰ تا داریم و کسی ۲۰ تاش را سفارش میده و در همون زمان یک نفر مثلا ۵ تا دیگه از کالا می‌خواد من چه کاری میتونم بکنم :

دو تا راه حل داری :

۱ - وقتی یک نفر ۲۰ تا کالا میریزه توی سبد خرید شما اون ۲۰ تا کالا را در محاسبه موجودیت برای کاربر دوم کم کنی در نتیجه کاربر دوم نمیتونه چیزی بخره. حالا اگه کاربر اول که ۲۰ تا را سفارش داده تا ۱۵ دقیقه عملیات پرداخت را انجام داد و سفارش نهایی شد که هیچی وگرنه سبد طرف را کنسل میکنی و ۲۰ تا بر میگرده توی موجودیت

۲ - وقتی نفر اول ۲۰ تا کالا میریزه توی سبد خریدش شما اون ۲۰ تا کالا را در محاسبه موجودیت برای کاربر دوم کم نکنی در نتیجه کاربر دوم میتونه ۵ تا را بریزه توی سبدش. حالا اگه کاربر اول سبد خریدش را پرداخت کرد خوب کاربر دوم در زمان برگشت از بانک نمیشه ۵ تا کالا بهش بدیم چون موجودی نداریم. اگه هم دومی زودتر پرداخت کرد خوب نفر اول دیگه نمیتونه ۲۰ تا کالا بخره !

اگه از حالت دوم استفاده میکنی حتما قبل از انتقال به درگاه پرداخت و قبل از settle کردن موجودی را بررسی کنید تا زیاد از حد موجودی نفروشین. میتونین هم پول هر دو را بگیرین و فوقش اونی که کالا گیرش نیومده را راضی کنین.

انقدر که lock کردن جداول توی این کار اهمیت داره transaction نداره ! با استفاده از transaction مطمئن میشین اگه خطایی پیش اومد همه چی به حالت اول بر میگرده. همین‌!

جناب Desatir حالا انتخاب با شما !
من حالت 2 که شما میگید رو بیشتر قبول میکنم
چون فروشگاه های که من دیدم شاید 5% مواقع با موجودی مشکل دارن ولی اکثر اگه این حالت اتفاق بیقته سریع میتونن موجودی جدید بگیرن یا با مشتری تماس بگیرن بگن یک روز دیرتر تحویل میدن یا بگن فعلا نداریم که من گفتم خدمتتون 5% مواقع میگن فعلا نداریم .
حرفتونم قبول دارم اینقدری که lock مهم هست transaction اهمیتی تو این قضیه نداره

[desatir7316]

۲ - وقتی نفر اول ۲۰ تا کالا میریزه توی سبد خریدش شما اون ۲۰ تا کالا را در محاسبه موجودیت برای کاربر دوم کم نکنی در .....

اگه از حالت دوم استفاده میکنی حتما قبل از انتقال به درگاه پرداخت و قبل از settle کردن موجودی را بررسی کنید تا زیاد از حد موجودی نفروشین. میتونین هم پول هر دو را بگیرین و فوقش اونی که کالا گیرش نیومده را راضی کنین.

جناب Desatir حالا انتخاب با شما !

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


یه چیزی که فکر می کنم بد نباشه اینه که موجودی رو قبل از ارسال به بانک یک بار دیگه چک کنیم ( مثلا به عنوان مرحله نهایی) و اگه مشکلی نداشت اون تعداد رو توی جدول رزرو قرار بدیم و از موجودی واقعی کم کنیم و بعد از 15 دقیقه اگه پرداخت نشده بود سر جاش برگردونیم و اگر هم پرداخت شده بود که از جدول رزرو حذف می کنیم...
ولی برای کاربرانی که می خوان خرید کنن و موجودی نداریم و احتمال این هست که مثلا صرف چند دقیقه بعد موجودی اضافه بشه رو از طریق sms و email به کاربر اطلاع بدیم...

اینطوری کاربر اگه چند تا کالا کم داره و اونا توی جدول رزرو هستن و قرار نیست خرید براشون انجام بشه، می تونه توی چند دقیقه آینده خرید اونا رو هم انجام بده

[Unique]

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

نه دیگه ! شما زمان برگشت از بانک هر چی موجودی داری را بر اساس پرداخت کامل کاربر انجام میدی و هر چی میمونه را پس میدی یا چند روز دیگه میدی بهش که موجودی جدید بیاد.


یه چیزی که فکر می کنم بد نباشه اینه که موجودی رو قبل از ارسال به بانک یک بار دیگه چک کنیم ( مثلا به عنوان مرحله نهایی) و اگه مشکلی نداشت اون تعداد رو توی جدول رزرو قرار بدیم و از موجودی واقعی کم کنیم و بعد از 15 دقیقه اگه پرداخت نشده بود سر جاش برگردونیم و اگر هم پرداخت شده بود که از جدول رزرو حذف می کنیم

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


لی برای کاربرانی که می خوان خرید کنن و موجودی نداریم و احتمال این هست که مثلا صرف چند دقیقه بعد موجودی اضافه بشه رو از طریق sms و email به کاربر اطلاع بدیم...
این روشیه برای خودش اما جایی ندیدم.

احتمال این موضوع انقدر کم هست که قابل چشم پوشیه و مثلا nazanin و fatima اعتقاد دارن نمیخواد نگران باشی و فوقش برای کاربر دوم که موجودی کمتر داره کالا را با ایجاد وقفه و امروز فردا بالاخره میفرستی.

[desatir7316]

نه دیگه ! شما زمان برگشت از بانک هر چی موجودی داری را بر اساس پرداخت کامل کاربر انجام میدی و هر چی میمونه را پس میدی یا چند روز دیگه میدی بهش که موجودی جدید بیاد.


در این مورد منظورم این قسمت بود که اگه مشکلی بود settle نکنیم کل پول پرداختی رو برمیگردونیم که جالب نیست چندان
در ضمن اگه بخوایم همه چیز رو خودمون چک کنیم وقتی تراکنش ها زیاد بشن کنترل کردن سایت هر سری سخت تر می شه

[Keramatifar]

موضوع transaction ها هم توی این بحث خیلی جایی نداره
در واقع شما وقتی میخوای موجودی بگیری باید جدول های دخیل در محاسبه موجودی را lock کنی ،
انقدر که lock کردن جداول توی این کار اهمیت داره transaction نداره !

بنده دیگه دارم نگران شما می شم دوست عزیز
اما امیدم رو از دست نمیدم و برای چندمین بار شما را به مطالعه در مورد Transaction و بخصوص مفهوم ISOLATION در تئوری ACID مربوط به تراکنش ها هدایت می کنم
باور بفرمایید حتی از ترجمه کلمه ISOLATION هم می شود به این نتیجه رسید که :
اصولا از آنجائیکه Transaction برای موارد این چنینی بوجود آمده، بصورت طبیعی، هنگام اجرا، خودش جدول های دخیل در محاسبه موجودی را lock می کند
ابن هم منبع برای مطالعه
مفهوم تراکنش یا Transaction در دیتابیس

[fatima-php]

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

[fatima-php]

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

[Unique]

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

من یا اقای کرامتی فر جایی نگفتیم باید جداول را ۱۰ دقیقه قفل کنیم یا قفل کنیم تا از سایت بانک برگردیم ! ببینین ما معمولا یک جدول داریم که برای ثبت کالاهای جدید ازش استفاده میکنیم و یک جدول هم کالاهایی هست که توی سبد های خرید قرار گرفته و عملیات خرید روشون انجام شده ، موجودی یک کالا تعداد ورودی (جدول انبار) - تعداد خروجی (ایتم های سبد های خرید تسویه شده) میشه. اگه شما جدول های دخیل را در زمانی که میخواین موجودی را محاسبه کنید lock نکنید که اصلا ممکنه موجودی را اشتباه محاسبه کنید. مثلا وقتی تعداد کالای ورودی را گرفین و رفتین سراغ query برای کالاهای سبد خرید تسویه شده همون موقع ادمین ۴ تا از اون کالا را اضافه کنه و محاسبه شما اشتباه بشه یا بر عکس. پس lock کردن چه read و write در زمان کار با جداول دخیل در محاسبه موجودی واجبه !


باور بفرمایید حتی از ترجمه کلمه ISOLATION هم می شود به این نتیجه رسید که :
اصولا از آنجائیکه Transaction برای موارد این چنینی بوجود آمده، بصورت طبیعی، هنگام اجرا، خودش جدول های دخیل در محاسبه موجودی را lock می کند
ابن هم منبع برای مطالعه
بله transaction ها و مفاهیم مربوط به اونها و table locking و غیره وجود داره ! من اصلا بحثی در این مورد ندارم. من و دوستان دیگه میگیم transaction چه نقشی را در حل مشکل شروع کننده تاپیک بازی میکنه ؟ منظور شما اینه که مانع بشیم کاربر دوم بتونه کالایی که موجودیش تموم شده را به سبدش اضافه کنه ؟ قائدتا اینه چون اگه قرار باشه بتونه افزون بر موجودی کالا بریزه توی سبد خریدار که شاید طرف پرداختش کامل نشه ، با transaction نمیخونه ! اصل قضیه اینه که شما میگین transaction راه حل مشکله اما نمیگین چطور مشکل را حل میکنه. لطفا نگران من نباشین و مشکل دوستمون را حل کنین. من حتما در مورد transaction ها مطالعه بیشتری میکنم.

[n0o0b_sina]

آقا میشه یکی لطف کنه توضیح بده چرا من نمیتونم بعد از رفرش transaction رو rollback کنم؟ یه مثالی چیزی بزارید یاد بگیرم :|

[fatima-php]

تا جایی که میدونم، وقتی اتصال قطع میشه، تراکنشها بطور پیشفرض کامیت میشن. البته این موضوع به فعال بودن Auto Commit بستگی داره. درموردش تحقیق کنید.

[Keramatifar]

آقا میشه یکی لطف کنه توضیح بده چرا من نمیتونم بعد از رفرش transaction رو rollback کنم؟ یه مثالی چیزی بزارید یاد بگیرم :|
دوست عزیز
آیا Transaction شما سمت دیتابیس مدیریت می شود یا سمت php؟
شما باید کد مربوطه را اینجا قرار دهید تا من و دوستان بتونیم کمکتون کنیم
برای شروع:
مفهوم تراکنش (Transaction) در دیتابیس (http://barnamenevis.org/showthread.php?495890-Class-%D9%87%D8%A7-%D9%88-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7-%D9%88-%D8%AA%DA%A9%D9%86%DB%8C%DA%A9-%D9%87%D8%A7%DB%8C-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF%DB%8C-%D8%AF%D8%B1-PHP&p=2225599&viewfull=1#post2225599)

[Unique]

آقا میشه یکی لطف کنه توضیح بده چرا من نمیتونم بعد از رفرش transaction رو rollback کنم؟ یه مثالی چیزی بزارید یاد بگیرم :|
آقا سینا نمیشه !

[Hamed Beyranvand]

سلام دوستان
فرض کنید من از یک کالا 20 عدد دارم و توی سبد خرید کاربر A همه این کالا هارو انتخاب می کنه یعنی همون 20 تا و منم تعداد درخواستی رو چک کردم و مشکلی نبوده و حالا آماده ارسال به بانک هستم
توی همین موقع یه کاربر دیگه هم دقیقا همچین درخواستی داره، مقدار درخواستی با موجودی انبار چک می شه و درسته آماده ارسال به بانک
اگه من هردوتا رو بفرستم به بانک خوب 40 تا کالا فروختم در حالی که فقط 20 تا توی انبار هست
مشکلاتی از این قبیل رو چطوری می شه حل کرد؟

ممنون
دوست عزیز اگه شما بعد از چک کردن برای 20محصول یه عمل update روی جدول انجام بدین دیگه مشکلی برای 20 محصول بعدی پیش نمیاد(یعنی موجودی کافی نیست).با استفاده از عملی که اکثر فروشگاها انجام میدن یا برای هر سفارش یه عمل update انجام بدین(که ممکنه خرید کاملی ام نباشه)یا اینکه در زمان ارسال اطلاعات نهایی برای مشتری بانک اطلاعاتی رو چک کنید.

[fatima-php]

یه موضوع دیگه هم هست و اونم اینه که توی اینجور فروشگاهها که درخواست بالا دارن، یک حد پایین موجودی میگذارن (مثلاً 100 عدد - بسته به میزان فروش هر کالا) که اگه موجودی کمتر از اون حد شد، بطور خودکار سیستم به مدیر پیام بده و مدیر موجودی رو افزایش بده (دوباره خرید کنه و تو فروشگاه بیاره).

[n0o0b_sina]

آقا سینا نمیشه !

تا جایی که میدونم، وقتی اتصال قطع میشه، تراکنشها بطور پیشفرض کامیت میشن. البته این موضوع به فعال بودن Auto Commit بستگی داره. درموردش تحقیق کنید.
هر دو نقل و قول درستن! (البته به نظره منه n0o0b :لبخند:)
با فعال کردن AUTOCOMMIT باز هم بعد از رفرش نمیشه COMMIT و ROLLBACK کرد! میتونید خودتون امتحان کنید...
حالا آقای کرامتی فر چطوری این کارو میکنن واقعا خوب میشه اگه به ما هم آموزش بدند! حالا قضیه ی بانک رفرش هم نیست... redirect میشه صفحه!!!

[n0o0b_sina]

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

۴- همچنین خاتمه غیر طبیعی برنامه تراکنش را ناتمام می گذارد، دقیقا همانطور که دستور ROLLBACK اجرا می شد. در این مورد هم، چون برنامه پایان یافته است، تراکنش جدید و دیگری برای شروع وجود ندارد.

نقل و قول از توضیحات آقای کرامتی فر!!!
با این توضیحات ما چطوری از transaction ها توی موضوع این تاپیک استفاده کنیم؟

[desatir7316]

از اونجایی که ممکنه یه کاربر عمدا بیاد و همه کالا ها رو هر سری بریزه توی سبد کالا و بفرسته برای بانک و در کار سایت اختلال ایجاد کنه بهتره اصلا از این جدول رزرو و ... استفاده نشه
پول از کاربر گرفته بشه و بعد از بازگشت، موجودی ها تنظیم بشن و اگه مشکلی بود پیغام بده و با کاربر هماهنگ کنیم...