یلدا ادامه داره... ❤️ ۴۰ درصد تخفیف همه دوره‌ها
استفاده از تخفیفهاذخیرهی فاکتور فروش در دیتابیس
سلام خدمت دوستان عزیز و اساتید گرامی
فرض کنیم کاربر در هر خرید یک سری کالا و از هر کالا یک یا بیش از یک عدد خریداری میکنه. بهترین و بهینه ترین روش برای ذخیره‌ی این اطلاعات در دیتابیس به چه صورته؟
بهتره یک جدول برای فاکتور ها درست کنیم که مشخص کنه هر فاکتور در چه تاریخی و برای چه کاربری ایجاد شده، با این فیلد‌ها (id, user_id, date) و یه جدول هم برای تعداد هر محصولی که در هر فاکتور خریداری شده (invoice_id, product_id, count) .
یا اینکه یه جدول کافیه و ای دی هر محصول و تعداد خریداری شده از اون محصول رو داخل آرایه بریزیم و سریالایز کنیم و ذخیره کنیم؟
تو این تصویر جدول‌های مربوط به دو حالت رو کشیدم:
http://s9.picofile.com/file/8365799492/Tables.png
ممنون میشم راهنمایی کنید که کدوم حالت بهتره، یا اگه روش بهتری غیر از اینها هست بفرمایید. ممنون...
گزینش سوالات
گفت و گو های مرتبط
دسته بندی سوالات
تگ‌های محبوب
سلام
مرسوم ترین راه برای ذخیره سازی داده های این ماژول در سیستمهای مالی این هست که شما از دو جدول استفاده کنید(Master Detail)
جدول اول بعنوان سربرگ فاکتور که شامل اطلاعات کلی مانند شماره فاکتور، شناسه فاکتور، شناسه مشتری، تاریخ صدور فاکتور، وضعیت تصویه فاکتور و ... میباشد
جدول دوم بعنوان اقلام فاکتور در نظر گرفته میشود که اطلاعات اقلام خریداری شده یا فروخته شده در آن ذخیره میشود بطور مثال:
شناسه فکتور، شناسه محصول، تعداد و ...
@alireza1ir3za
میتونید مقادیر رو به صورت یک آرایه کلی و ولیو ذخیره کنید که key بشه ای دی محصول و value بشه تعدادش و اینو تو یه جدول ذخیره کنید که مقادیرش شامل ای دی کاربر و تاریخ و ... باشه یکیم باشه پروداکت این آرایه توش ذخیره بشه . بعدش راحت با php حساب کتابشو انجام بدین . این ساده ترین راهشه با تنها یک تیبل و چنتا مقدار .
البته استفاده از چند جدول و جداول واسط خوبیشون اینه بیشتر میتونید مدیریت کنید و دستتون باز تره ولی اینجوری یک جدول و آریایه حجم دیتابیس و کوئری های دیتابیس خیلی کمتر میشه .
سلام،
راستش با توجه به اینکه در سیزن ها هم تقریبا همینطور سبد خرید رو ذخیره میکنیم وقتی بحث طراحی دیتابیس فاکتور رسید همین روش به ذهنم اومد که خب همون آرایه سبد خرید key value رو ذخیره کنیم در دیتابیس، ولی اینکار تا چه حد اصولیه؟ آیا ممکنه بعدا ازین مدل طراحی ایرادی بگیرن؟! احساس میکنم یخورده شبیه این کلک رشتیاست. :))
(البته من فعلا پروژه های سبک یا تمرینی کار میکنم) .
و روش رابطه ای کمی غیربهینه نیست؟ چیزی که من ازش متوجه شدم، شما هر آیتم خرید رو بایست در یک ردیف جدول ذخیره کنید، و با توجه به اینکه هرکسی معمولا بیش از یک جنس خرید میکنه کلی سطرهاش میره بالا! مثلا برای یک خرید ده آیتمی میشه ده سطر با شماره فاکتور یکسان! (درسته؟)
ممنونم.
طبق اصل نرمال سازی دیتابیس باید ۲ تا جدول باشه
یکی واسه فیلدهای سفارش مثل زمان و وضعیت و شماره فاکتور و اسم کاربر و ...
و یکی واسه جزئیات سفارش مثل ایدی محصول و تعداد و ...
بعد با کلید خارجی به هم ارتباطشون میدیم
درود
دوستان توضیحات خوبی دادند.
فقط دو نکته مهم رو باید توجه کنید.
ذخیره به صورت آرایه شما رو موقع گزارش گیری به دردسر و پیچیدگی بیشتری میرسونه پس همون ذخیره مرسوم دو تیبل رو استفاده کنید.
نکته بعدی به خاطر اینکه تعهدات فروش و موضوع رفع مسئولیت باید توجه کنید که در ذخیره اطلاعات فاکتور فروش قسمتهای مهم مثل نام محصول و قیمت و ... رو که از تیبل های دیگر فراخوانی میشن توی همین تیل ذخیره کنید یعنی اطلاعات این تیبل باید مستقل از تیبل های دیگر قابل دستابی باشه ، چرا که ممکن است شما بعدا قیمت یا نام محصول رو در تیبل های اصلی تغییر بدید بعد فاکتور فروش مشتری هم دستخوش تغییر میشه
@mazyar ممنون بابت توضیحات،
فرض کنید ما در گذر زمان یه جدول مثلا هزارتایی از آیتمهای فاکتورهای مختلف در یک تیبل داشته باشیم (تیبل دوم) ، کوئری زدن به چنین تیبلی که مثلا برو آیتمهای فاکتور شماره x رو در بین هزارتا بگرد و پیدا کن یکم سنگین نیست؟
درود بر شما
این قسمت چیزی نیست که همه کاربران همزمان بخوان ازش استفاده کنن یا اینکه خیلی منابع سرور رو درگیر کنه اما یک آیتم الزامی است.
چرا که اگر نام محصول و قیمتش رو اینجا ذخیره نکنید و بخواهید همیشه از تیبل اصلی فراخوانی کنیدبعدا که کاربر بخواد جزییات فاکتورش رو بررسی کنه نام و قیمت رو از تیبل اصلی میگیره و این چیزی نیست که خریده چرا که در گذر زمان اگر ادمین قیمت و نام رو تغییر بده روی مستندات فروش های قبلی تاثیر میزاره و اختلاف حساب پیش میاد.
موفق باشید
@AliRezaa