دیتابیس حسابداری لاراول با mysql
سلام دوستان
در این تاپیک که برای 4 سال پیش هست در مورد دیتابیس حسابداری صحبت شده ، یکی از دوستان گفته که ایجاد کردن چند دیتابیس برای اینکه دیتابیس قبلی حجیم میشه کار خوبی نیست و باید رابطه ای باشه، دوباره دوستی گفتن که سال مالی که تموم شد باید برای سال جدید دیتابس جدید ایجاد بشه
1- برای دیتابیس حسابداری که بلخره روزانه چند صدتا فاکتور میزنه و کلی گزارشات، پارتیشن بندی خوبه یا نه؟
2- برای بحث سال مالی چی بهتره؟ اینکه سال مالی تموم شد سیستم سال مالی جدید رو باز کنه، آیا در همون دیتابیس قدیمی باشه یا جدید ایجاد بشه؟
ممنون از دوستان عزیز 😍
گزینش سوالات
گفت و گو های مرتبط
دسته بندی سوالات
تگ‌های محبوب
ببینید @honardad
دو نکته دیگه هم ممکنه برای شما مفید باشه
- توی تاپیک مورد نظر در مورد nosql بودن هم صحبت شده بود با توجه به اینکه در امور مالی سیستم های متمرکز (سیفای) به شدت روی روابط جدوال حساب میشه باید قید nosql رو بزنید.
- در مورد پارتیشن بندی در حال حاضر بعید میدونم این مشکل شما باشه اما در هر صورت راهکار مناسبی هست و میتونید جز گزینه ها در نظرش بگیرید مثلا برای تیبل یوزر نیاز ندارید ولی ممکنه برای بخش اسناد یا فاکتورها کارایی داشته باشه و با توجه به اینکه تمام پروسه گزارش گیری اغلب متاثر از تاریخ شروع دوره مالی است پس فیلد تاریخ میتونه گزینه مناسبی برای Partition Key باشه و اگر دقت کرده باشید تعیین بازه زمانی برای فیلد جستجو در فرم های حسابداری امری متداوله حتی اگر کاربر علاقمند به تعیین نباشه میتونید به صورت پیش فرض برای الزام استفاده از پارتیشن بازه پیش فرض رو از ابتدای سال مالی منظور کنید.
سلام @honardad
هدف از فرایند سال مالی تهیه صورتحساب های مالی در بازه های زمانی مشخص و بستن حساب های دائمی و موقت و در نهایت انتقال آنها از یک دوره به دوره بعدی است. منظور از بستن حساب ها عدم دسترسی به آنها یا کنار گذاشتن آنها نیست بلکه متوقف کردن هرگونه عملیات حسابداری بر روی اسناد برای دخل و تصرف و ویرایش یا حذف است به صورت ساده و سنتی بخواهیم توضیح دهیم یعنی مهر و موم کردن اسناد.
مهر و موم کردن اسناد به معنی عدم دسترسی به گزارشات نیست مثلا باید در هر دوره با فرض بسته شدن حسابها بتوانید گزارشات کاملی از دفتر روزنامه،کل یا معین داشته باشید.
وقتی سال مالی انجام می شود میزان بدهکاری یا بستانکاری و مولفه های دیگر به صورت تجمیع شده در سر فصل های مورد نظر باید به حساب اشخاص منظور شود. در مورد حساب ها و دارایی ها و تضامین و صندوق ها و ... نیز به همین شکل است منتها قبل از این فرایندها باید محاسبه تراز کل صورت گرفته باشد و مثلا در یک حسابداری دوبل مکانیزه انتظار داریم همیشه تراز صفر رعایت شده باشد.
کل یک دوره مالی پس از بسته شدن مانند تشکیل یک زنجیره در بلاکچین می ماند که داده های هدر یک بلوک پیش فرض تشکیل بلوک بعدی است.
با این توصیف تشکیل دیتابیس جدید برای هر دوره منتفی است و اگر نگرانی از باب بزرگی دیتابیس وجود دارد باید از راه کارهای استاندارد مهندسی برای بهینه سازی و مدیریت استفاده شود.
سپاس جناب @hekmati
واقعا عالی توضیح دادین
پس با این حساب پارتیشن بندی هم ایده خوبی نیست و باید همین روش مهندسی و مدیریت استفاده بشه؟
ببینید @honardad
دو نکته دیگه هم ممکنه برای شما مفید باشه
- توی تاپیک مورد نظر در مورد nosql بودن هم صحبت شده بود با توجه به اینکه در امور مالی سیستم های متمرکز (سیفای) به شدت روی روابط جدوال حساب میشه باید قید nosql رو بزنید.
- در مورد پارتیشن بندی در حال حاضر بعید میدونم این مشکل شما باشه اما در هر صورت راهکار مناسبی هست و میتونید جز گزینه ها در نظرش بگیرید مثلا برای تیبل یوزر نیاز ندارید ولی ممکنه برای بخش اسناد یا فاکتورها کارایی داشته باشه و با توجه به اینکه تمام پروسه گزارش گیری اغلب متاثر از تاریخ شروع دوره مالی است پس فیلد تاریخ میتونه گزینه مناسبی برای Partition Key باشه و اگر دقت کرده باشید تعیین بازه زمانی برای فیلد جستجو در فرم های حسابداری امری متداوله حتی اگر کاربر علاقمند به تعیین نباشه میتونید به صورت پیش فرض برای الزام استفاده از پارتیشن بازه پیش فرض رو از ابتدای سال مالی منظور کنید.