طراحی DataBase در سیستمهای چند Package؟

[SYNDROME]

با سلام
ما چند سیستم داریم(حسابداری ،انبار ، حقوق و دستمزد و . . .)
حالا به نظر شما دوستان ما در طراحی DataBaseاین برنامه ها به کدام روش عمل کنیم:
1-برای هر سیستم یک DataBase جداگانه طراحی کنیم و Tableهای آن را در آن ایجاد کنیم؟
2-یک DataBase اصلی درست کرده و همه tableها را در آن طراحی کینم و با استفاده از قانونهای نام گذاری برای جدا سازی Tableها استفاده کنیم؟
البته من خودم به این نتیجه رسیدم اگر حالت اول بر قرار باشد:
1-DataBase حجیم می شود.
2-چون سیستم جداکانه نیز به فروش می رسد نیاز نیست DataBaseهای دیگر را نیز نصب کنیم.
و در حالت دوم:
1-براحتی Relationها را بر قرار می کنیم.
2-فقط یک DataBase داریم و BackUpاز آن راحت است.
منتظر نظرات و پیشنهادات دوستان خوب خودم هستم(اگر امکان دارد با دلیل پیشنهادات خود را بیان کنید).
با تشکر فراوان

[jirjirakk]

بدون شک حالت دوم بهترین راه حل هستش

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

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

[SYNDROME]

با سلام


توی حالت اول نفهمیدم چرا حجم دیتابیستون کم میشه؟

با تشکر از توجه شما.اشتباه لوپی بود:خجالت:اصلاح کردم


بدون شک حالت دوم بهترین راه حل هستش

ممکن است درست باشد ولی در حالت اول ما با ایجاد Relation در بانک Update اطلاعات را به خود SQLواگذار می کنیم.
در حالت دوم خودمان باید Relation را به وسیله کد نویسی مدیریت کنیم.کمی سخت است.
منتظر نظرات همه دوستان هستم.
با تشکر

[ghabil]

روش دوم روش درست هست .

[jirjirakk]

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

[Hamid.Kad]

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

[SYNDROME]

با سلام

روش دوم روش درست هست .
علیرضا جان دلیلت را نگفتی؟

حالت دوم تمام رابطه ها رو ایحاد می کنید دیگه
برای چی به صورت کد نویسی مدیریت کنید؟ توی حالت دوم مشکلی برای ایجاد Relation ها بین جداول وجود نداره می تونید راحت Relation هاتون رو بزنید و کارتون رو ادامه بدین
شرمنده درست می گی من اشتباه گفتم منظورم روش اول بود.

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