چگونگی طراحی سال مالی (حسابداری) در دیتا بیس

[INeedHelp]

من برای طراحی سال مالی یک سیستم حسابداری چند روش رو فهمیدم که مزایا و محاسنشون رو کاملا نمی دونم. اگه ممکنه راهنمایی کنید:

1. فایل دیتا بیس جداگانه
2. قرار دادن فیلد مشخص کننده سال مالی در جدول ها
3.برای هر سال مالی یک جدول

می خوام از MS SQL استفاده کنم.
متاسفانه من در جستجو در سایت به جواب مشخصی نرسیدم ، و مجبور شدم تایپک بزنم.
چرا تو این سایت کسی جواب ما رو نمی ده :ناراحت:
لطفا کمکم کنید چون هرچه زودتر باید شروع کنم :عصبانی++:

[ASKaffash]

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

[منصور بزرگمهر]

در اکسس که مشکل حجم داشتیم، برای هر سال مالی یک دیتا بیس جداگانه داشتیم، و به فایل اکسس که فرم ها و ریپورتها در ان بود، لینک می کردیم، و اینگونه نام جداول لینک ما یکی بود، و مشکل برنامه نویسی نیز نداشتیم، ولی در SQL Server که مشکل حجم نداریم، یک جدول جداگانه بهتر بنظر می رسد، و یک کمی بیشتر برنامه نویسی برای پیدا کردن نام جداول سال مالی مناسب، می توانیم به سال مالی مورد نظر رسید.
من فرمت MY SQL را نمی دانم، ولی اگر مشکل حداکثر حجم نداشته باشد، (مثل اکسس حداکثر یک گیگ) راه حل سوم بهتر است.
یک ستون بیشتر خوب نیست، چرا که حجم اطلاعات حسابداری زیاد است، که پس از چند سال میلیاردها و تریلیاردها سطر داری، که محاسبه آنها غیر ممکن می شود.

[بهنام بهمنی]

گزینه شماره 2
حالتهای 1و3 درصورتی که نیاز به گزارشهایی که بر مبنای 2 یا بیشتر سال مالی باشد, بسیار پیچیده خواهد شد.
در مورد حجم هم که MS-SQL تا جایی که هارد جا داشته باشد , می تواند حجم پایگاه داده را افزایش دهد.
مباحثی مانند اینکه در هر دوره مالی شماره ها از نو شرع می شود ویا نه - ایندکسینگ و ... را هم در نظر بگیرید.

[bahman_akbarzadeh]

گزينه 2 اصلا گزينه خوبي نيست.
گزينه 3 هم داراي پياده سازي مشكليه و در نهايت، باز هم حجم ديتابيس رو بالا ميبره.
به نظر من، گزينه اول از همه بهتره. چون اولا حجم جداول و به دنبال اون، حجم ديتابيس بالا نميره و سرعت كوئري گرفتن بهتر ميشه، ثانيا در بحث حسابداري، ما به بايگاني و غير قابل تغيير بودن اطلاعات، احتياج داريم.
البته بايد در نظر داشت كه در اطلاعاتمون، دوگانگي داده صورت نگيره.
من قبلا از گزينه دوم استفاده كردم و ضرر كردم. در نهايت اگر از دوستان كسي دليلي براي گزينه سوم داره، - چون من به اين مسئله زياد فكر نكردم - ممنون ميشم كه راهنمايي كنه.

[منصور بزرگمهر]

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

البته راه حل بالا برای SQL Server ممکن می باشد، و برای MY SQL نمی دانم، ببین می توانی فایل پایگاه داده خود را چند قسمت نمائی، در غیر اینصورت، مشکل خواهی داشت.

متشکرم - بزرگمهر

[INeedHelp]

با تشکر از دوستانی که نظر دادن منظورم از MS SQL همون Microsoft SQL Server بود که خودمم نمی دونم چرا اینجوری نوشتم !
خودم به نتایجی رسیدم که بد نیست دوستان و اساتید نظرشون و رو در این موارد اعلام کنند.
1. فایل دیتا بیس جداگانه:
به نظر می رسه این روش از همه روش ها بهتر باشه چون در علم حسابداری کسی اجازه نداره اسناد قطعی ( وقتی سال مالی بسته می شه کلیه اسناد قطعی می شن) رو اصلاح یا حذف کنه. در نتیجه ما هیچ وقت عملیاتی روی سال مال گذشته انجام نمی دیم و فقط ممکنه نیاز به گزارش باشه که دو حالت داره یا بکاپ سال مالی قبل رو برگردونیم یا نرم افزار را طوری طراحی کنیم که قبل از ورود به سیستم ازمون بخواد سال مالی رو انتخاب کنیم.
2. قرار دادن فیلد مشخص کننده سال مالی در جدول ها
طوری که من پرسوجو کردم ایرادش اینه که در آینده که تعداد سندها زیاد می شه با عث کندی در سیستم می شه
پیاده سازی در این حالت احتمالا ساده تر از دو روش دیگه است.

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

از آقا منصور و کاربر ASKaffash و دیگر دوستان خواهش می کنم بحثو ادامه بدن تا به نتایج کاملتری برسیم.

[mpmsoft]

به نظر بنده شما برای سالهای مالی یک جدول بسازید و در یگ Ndf ذخیره کنید بهتره
1 - قابلیت ارتباطی سریع تر و آسانتر بین سالهای مالی (گزارش)
2 - بک آپ
3 - امنیت بیشتر جهت دسترسی کاربران تنها به یک بانک اطلاعاتی
و ...

شما برای این منظور چند روش داری
1 - قبل از اسم جدول سال رو بزن 88TblMoein
2 - یا می تونی اسم جداولتو توی یک جدول دیگه همراه با سالهای مالی معرفی کنی

[INeedHelp]

منظورتون از Ndf همون mdf است؟
من خودمم می خوام از این روش استفاده کنم مثلا جدول سند بشه tbl_CurrentDoc بعد که سال تمام شد تغییر نام پیدا کنه به tbl_doc88 و جدول tbl_CurrentDoc دوباره ساخته بشه و ... می خواستم بدون کسی از این روش استفاده کرده که کاملا به معایب اون آشنا باشه مثلا عیب این روش اینه که حجم دیتا بیس بعد از چند سال زیاد میشه که بخاطر ماهیت کار ما ( کار با داده های string ) نباید مشکل خاصی باشه ...

[بهنام بهمنی]

همانطور که می دانید SQL-Server برای ایندکس دهی از شیوه B+Tree چند طرفه استفاده می کند , در این جستجو اگر ما n ردیف داشته باشیم تعداد جستجو برای پیدا کردن یک ردیف خاص برابر لگاریتم n بر پایه تعداد طرفه های درخت می شود - بطور مثال اگر ما 250میلیون ردیف داشته باشیم با حدود 12 جستجو ردیف مورد نظر پیدا خواهد شد.بنابراین نگرانی از جهت اینکه حجم بالای رکوردها موجب کندی , می شود , درصورت درست تعریف شدن ایندکس ها نگرانی بجایی نیست.ضمنا توجه شود که ساختار اینکس جدا از فایل اصلی ذخیره می شود - بنابرین بزرگ شدن خود جدول لزوما به معنی بزرگ شدن زیاد فایل ایندکس نمی شود.

[منصور بزرگمهر]

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

من روش سوم را ترجیح می دهم، جم جور تر و قابل اعتماد تر است.

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

متشکرم - بزرگمهر

[INeedHelp]

دوست بزرگ مهر که با بزرگواری وقت میزاری و دو صفحه تایپک می نویسی ، من در دوران خدمت از 20 ماه 16 ماه کمک دستیار یک حسابدار خبره بودم و مفاهیم اولیه رو اونجا یاد گرفتم و سعی می کردم حسابداری رو با دقت تجزیه تحلیل کنم. قبل از اونم با هلو کار کرده بودم و بعد از خدمت به نرم افزار هلو تسلط کامل پیدا کردم منظورم اینه که با حسابداری غریبه نیستم 6 ماه پیش کتاب اصول حسابداری 1 رو خریدم و پراکنده خوندم و در هفته گذشته کتاب اصول حسابداری 1 رو تقریبا دو سه دور خوندم . الان تا حدود زیادی به مسایل حسابداری تسلط دارم راستی من 6 ماه پیش یک نرم افزار حسابداری ناقص نوشتم که که بجز خرید و فروش کالا همه عملیات حسابداری رو انجام میده (برای یک آموزشگاه نوشتم) الان دارم بانک داده برنامه رو از ACCESS به SQL Server تبدل می کنم که قابلیت شبکه رو هم داشته باشه . یکی از ایراداتی می خوام برطرف کنم قابلیت بستن سال مالی می باشه و ......

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

اینجور که من برداشت می کنم سالهای مالی داخل یک فایل mdf باشه خیلی راحتتره وبهتر باید باشه من روی این روش کار میکنم امیدوارم دیگر دوستان تجربیات و نظراتشونو در اختیار ما بگذارند.

[bahman_akbarzadeh]

با تشكر از دوستان.
من هم متقاعد شدم كه روش سوم، مناسب تر از روش هاي ديگه هستش.
تنها مشكلي كه وجود داره اينه كه يكم پياده سازيش سخت تر ميشه.
ميخوام بدونم دوستاني كه كار كردن، روش خاصي رو در اين رابطه استفاده ميكنن؟
آيا SQL Server روش خاصي رو نداره كه جداول، بصورت فيزيكي، چند تكه باشن ولي بصورت مجازي، يكي باشن؟
يعني يه فيلد به عنوان كليد خارجي باشه، كه در اصل، همون اسم جداول جديدي باشه كه براي اسناد ايجاد شده.

[منصور بزرگمهر]

دوست عزیز با سلام مجدد
دوست عزیز اصولاً کامپیوتر ابزار می باشد؛ و دانستن سایر علوم کمکی غیر قابل تصوری در استفاده از این ابزار قدرتمند می نماید.
باور نمی کنی کسانی که علم دیگری، بغیر از علم کامپیوتر ندارند، چه بیراه هائی می روند، که قابل تصور نیست. (من می بینم هر روز، آخرشان همه ASP کار می شوند، چون فقط کامپیوتر می خواهد)و هر چه دانش فوق بهتر بدانی می توانی در ساخت نرم افزار منطقی تر و تاکید می کنم منطقی تر برنامه بسازی و منطقی تر برنامه ریزی کنی.
و اما حسابداری و کارائی آن
کسی که خوب حسابداری را بداند، ستون فقرات نرم افزارهای اداری مالی را می داند. بدین ترتیب شما هر گونه نرم افزار اداری مالی و تاکید می کنم دوباره، برنامه اداری(نه فقط حسابداری و مالی) می توانی ایجاد کنی، و شما دانش ایجاد و چرائی و چگونگی آن را داری. و نیاز روز افزون جامعه ما به نرم افزار اداری غیر قابل انکار است. مطمئن باش من تاکید می کنم، صد ها هزار و نه هزاران موسسه نیازمند به کارهای اداری می باشند، و امثال شما دارای ایده مناسب برای ایجاد ان دارید.

ولی توصیه من، 16 ماه یا چند کتاب اولیه حسابداری، ایده کافی در مورد این حد نرم افزار که گفتم ایجاد نمی کند، و تو نیاز به یک دانش پایه ای برای حسابداری می باشی، (منظور از پایه ای نتنها عمیق بلکه بسیار وسیع و همه ابعاد حسابداری را بدانی) نمی دانم قبلاً لیسانس کامپیوتر گرفته ای و حال در سربازی هستی، یا حال می خواهی وارد دانشگاه شوی، و دیپلم داری، ولی ایده مرا تحقیق کن، داشتن لیسانس حسابداری (نه حتی فوق دیپلم) دانش بزرگی بشما می دهد، که برای آینده کاری شما بسیار مفید می باشد، و همانطور که گفتم غیر قابل انکار.
من خودم لیسانس حسابداری دارم، و دیدم دولت ایران گله ای رشته حسابداری وارد می کند، و ما در آینده کاری نخواهی داشت، این شد که رشته کامپیوتر را شخصاً خواندم، و چه در ایران و چه حال که به خارج مهاجرت کرده ام، در کشور مادر کامپیوتر برنامه نویس ارشد و طراح نرم افزار هستم، و طراح بانک اطلاعاتی هستم، و کارائی خود را فقط مدیون دانش حسابداری می دانم، و می بینم حتی متخصصین ارشد کامپیوتر (حتی هندها وچینی ها که خبره هستند و آخر همشان ASP کار می شود) نیز داری ایده ای نیستند، که من داری دانش لازم می باشم، و بهر حال کامپیوتر ابزار و سایر دانشها بیس می باشند. بهر حال امیدوارم توانائی و زمان و حوصله دوباره تحصیل را داشته باشی و بدان زندگی در قرن 21 (البته نه قرن 21 ایرانی که یعنی افکار قرون وسطائی و جمعیت زیادی اینگونه هستند و تنبل - پول نفت) یعنی مطالعه همیشگی است و امیدوارم همیشه موفق باشی.

متشکرم - بزرگمهر

[hojjatshariffam]

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

[eastprogrammer]

من خودم قبلا این راه رو انتخاب کردم که به صورت عملی تست شده و ازون راضی هم هستم:

یک دیتابیس برای موجودیت های عمومی مثل دفاتر - حساب ها - اشخاص - شاخص ها و صفات جداول و ارتباط ها که برای همه سال ها همینه و اونو Accounting_master نام گذاری کردم

به ازای هر سال یک دیتابیس که مثلا اونو Accounting_1389 نام گذاری کردم و کل اسناد رو توی اون ثبت کردم

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

این کار رو من به صورت ابداعی انجام دادم اما بسیار ازش راضیم

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

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

[in_chand_nafar]

دوست عزیز شما SQL را دست کم نگیرید کلیه سال های مالی را در داخل یک جدول ذخیره و فیلد سال مالی را در آن جدول به عنوان یکی از کلیدهایتان استفاده کنید با پیاده سازی چند ایندکس بر روی جدول فوق و عملیات نگهداری ایندکس ها سرعت بانک اطلاعاتی بالا خواهد رفت
همچنین گر خواهان افزاریش سرعت هستید و برنامه بر روی شبکه اجرا می شود بهتر است سخت افزار شما از RAID استفاده کند و در ضمن می توانید سراغ Data Partitioning جهت پارتیشن بندی اطلاعات موجود در جداول بروید
مثلا می توانید یک جدول پر از اطلاعات سالهای مالی مختلف داشته باشید و با استفاده از فیلد سال مالی جدول خود را به دو قسمت تقسیم کنید (سال مالی جاری، سال های مالی قدیمی) و اطلاعات این دو جدول را در داخل فایل های جدا و دیسک جداگانه نگهداری کنید اما ر کل جدول شما یک جدول بوده لازم می دونم اشاره کنم این روش برنامه نویسی خاصی نمی خواهد و کاملا بحث SQL Admin می باشد و صرفا در SQL 2005,2008 وجود دارد
اگر اطلاعات بیشتری در مورد این روش خواستی می توانم وضیح بیشتری بدهم سعی کن در بین این روش هایی که بررسی می کنی چرخ را دوباره اختراع نکنی موفق باشی

[ASKaffash]

سلام
روش سوم :
معایب به دلایل ذیل :
- برای هر سال مالی باید Script جداول و ایندکس های مرتبط با هر سال ایجاد شود(با کد نویسی)
- پیاده سازی SP ها عموما با Dynamic SQL است (روش دوم پیاده سازی آسان ولی سرعت پائین تری دارد)
- امکان مقایسه اطلاعات سالهای متفاوت وجود دارد ولی پیاده سازی کمی پیچیده است
مزایا به دلایل ذیل :
- بانک اطلاعاتی کل پروِژه یکی است (ConnectionString و Backup و ....)
- چون Object های بانک کوچکتر هستند سرعت در مقایسه با روش دوم بالاتر است
- SP ها و جداول پایه و UDF ها یکدست و پشتیبانی های بعدی آسان است (ارسال نسخه از راه دور)

[mc_laren]

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

[tooraj_azizi_1035]

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

[bahman_akbarzadeh]

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

[MOJTABAATEFEH]

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

موفق باشید