نظرخواهی در مورد طراحی جدول

[حمیدرضاصادقیان]

سلام دوستان.
من میخوام جداول تعریف حساب رو به صورت پله ای تعریف کنم.
الان به دوصورت میشه جداول رو به صورت پله ای به صورت نامحدود تعریف کرد.
1- جدول دارای یک فیلد کدحساب و یک فیلد کد PArent باشه و یک فیلد هم برای نام حساب.
2- یک فیلد کد حساب، یک فیلد LEft, یک فیلد Right و یک فیلد نام.
در فیلد چپ و راست بازه عددی کدهایی که زیر مجموعه حساب فوق هستند قرار میگیره.
به طور مثال کد 100 اگر از حساب 200 تا 300 در سطح معین رو داره در فیلد چپ عدد 200 و در فیلد راست عدد 300 قرار میگیره.
حالا سوال اینجاست که اگر من بخوام برای یک سطح یا سطوح دیگه محدودیت ایجاد کنم چطور میتونم اینکارو انجام بدم؟
مثلا فرض کنید میخوام کاربر تعریف کنه که کد حساب کل 3 رقم باشه و کد معین 4 رقم و کد تفصیلی 6 رقم.
چطور این محدودیت هارو با توجه به این نوع ساختارها باید پیاده سازی کنم.؟
سوال دوم اینکه اگر من بخوام برای بعضی از حسابها توضیحات بیشتری اضافه کنم.
مثلا بخوام برای حساب مشتریان آدرس و تلفن و مشخصات دیگه ای ثبت کنم چکار باید بکنم؟
(فکر کنم باید یک جدول واسط طراحی کنم و کد اون با کد جدول حسابها به صورت FK باشه)
یا بخوام حساب بانکها و دسته چکها رو مشخص کنم.؟
من میام در سطح کل حساب بانک رو تعریف میکنم و یک کدی هم بهش میدم.
ولی برای جزئیاتش چی؟؟؟ مثلا بخوام حسابهای جاری اونو مشخص کنم. و مشخصات دسته چک هرحساب جاری رو تعیین کنم؟
سوال سوم اینکه اگر بخوام برای حسابهای کل ماهیت تعریف کنم.که کدوم بدهکار هست کدوم بستانکار یا کدوم دارایی های جاری.
(فکر کنم برای اینهم باید یک جدول جداگانه طراحی کنم و با کد جدول اصلی FK باشه و برای هر حساب کل در این جدول یک رکورد ایجاد کنم و دراونجا تنظیمات رو انجام بدم)
باتشکر.

[حمیدرضاصادقیان]

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

[حمیدرضاصادقیان]

سلام.
این چیزی است که خودم به صورت پیش فرض طراحی کردم.
جدول Tbl_hesab همون جدول درختی هست که کدینگ حساب رو به صورت درختی و نامحدود کاربر تعریف میکنه.
جدول Tbl_Checkinfo مشخصات دسته چک رو وارد میکنه.دیگه در اینجا مشخصات بانک و حساب جاری رو وارد نمیکنم چون به صورت درختی در همون کدینگ حسابها کاربر تعریف میکنه و فقط باید برای حساب جاریش دسته چکهای مختلف رو تعریف کنه.
جدول Tbl_cust_info مشخصات اضافی افراد هست مثلا مشتریان یا کارمندان.
جدول Type_Account گروه بندی حسابها در اینجا تعریف میشه. مثلا گروههای بدهی های جاری، دارایی های جاری، هزینه ها، فروش، و... و نوع ماهیتشون که ترازنامه ای هستند یا سود و زیانی.و همچنین بدهکار هستند یا بستانکار.
جدول Account_Property جدول واسط هست بین جدول حساب و گروه بندی حسابها که مشخص میکنه هر حسابی چه ماهیتی داره.
الان یک مشکل اینجاست که من چطوری کنترل کنم کاربر فقط برای حسابهای کل بتونه ماهیت تعریف کنه.
یا کاربر فقط برای حسابهای سطح تفصیلی بتونه چک یا مشخصات مشتریان رو تعریف کنه.

آیا این طراحی با این نیازمندی ها همخوانی داره؟ یا باید تغییراتی در اون ایجاد بشه؟
باتشکر

[حمیدرضاصادقیان]

سلام.دوستان در این زمینه کسی نظر خاصی نداره؟؟

[حامد مصافی]

سلام
ما در نرم افزار حسابداري دولتي از اين روش استفاده كرديم:

در جدول حساب اطلاعات زير درج مي شوند:


ID (identity)
كد حساب (كد كامل)
نام حساب
سطح (گروه حساب، كل، معين، تفضيلي، ...)
ID حساب parent (براي بالاترين سطح حساب اين مقدار 0 است)

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

ماهيت هر حساب را هم مي توانيد در همين جدول ذخيره كنيد.

اما توضيحات بيشتر نيازماند جدول ديگري است، براي مثال همانگونه كه فرموديد حساب هاي بانكي نياز به شماره حساب و ساير اطلاعات بانكي دارند، از طرفي حساب هاي عمراني نياز به اطلاعات طرح/پروژه دارند و ... پس بهتر است براي هر نوع يك جدول مجرا تعريف كرده و آنها را با يك ارتباط ضعيف به همين جدول متصل كنيد.

گمان مي كنم اگر همين ايده پست سوم را بسط بدهيد به نتيجه اصولي و مورد نظرتان برسيد.

[حمیدرضاصادقیان]

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

[حمیدرضاصادقیان]

سلام.دوستان کسی در این زمینه کاری نکرده؟

[AminSobati]

سلام حمید رضا جان،
متاسفانه حسابداری موضوعیه که تا به حال تحلیلش نکردم ولی در مورد اصل سوال، من به نظرم رسید استفاده از عدد Left و Right داستان Nested Sets هست که Joe Celko روش کار کرده. Queryهای اون برای بدست آوردن سطوح مختلف نوشته شده اگر در اینترنت جستجو کنید. ضمنا در این روش اضافه کردن یک Node به درخت باعث ویرایش Left و Right خیلی Nodeهای دیگه میشه. در SQL Server 2008 تایپ HierarchyID رو بررسی کردین؟

[حمیدرضاصادقیان]

سلام حمید رضا جان،
متاسفانه حسابداری موضوعیه که تا به حال تحلیلش نکردم ولی در مورد اصل سوال، من به نظرم رسید استفاده از عدد Left و Right داستان Nested Sets هست که Joe Celko روش کار کرده. Queryهای اون برای بدست آوردن سطوح مختلف نوشته شده اگر در اینترنت جستجو کنید. ضمنا در این روش اضافه کردن یک Node به درخت باعث ویرایش Left و Right خیلی Nodeهای دیگه میشه. در SQL Server 2008 تایپ HierarchyID رو بررسی کردین؟
امین جان سلام.در مورد left,right کتابشو دارم و یک بار مطالعه کردم. البته من نیازی ندارم بین کدها بخوام چیزی رو درج کنم.فکر کنم همون روش parentid راحتتر باشه.
در مورد HierarchiID بررسی نکردم.ممنون باز سرنخ خوبیه.