ساختار جداول برای وب سایت دارای چند ساب دامین و چند زبانه

[اوبالیت به بو]

درود بر شما

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

مثلا در جدول آلبوم تصاویر باید 2 فیلد اضافه برای مشخص نمودن ساب دامین و زبان مشخص نمود؟ و یا در جدول اخبار علاوه بر صفات موجود باید صفت نام دامنه و زبان را هم مشخص نمود؟

منظور اینکه اگر بخواهیم اخبار مربوط به دپارتمان x از دامنه test.com را که به 3 زبان انگلیسی، پارسی و عربی منتشر می شود را در یک جدول به نام News ذخیره کنیم، چه کار باید بکنیم؟

همچنین مدیریت کاربران به چه صورت خواهد بود؟ یک کاربر می تواند در دپارتمان (ساب دامین) های دیگر گشت و گذار کند یا خیر؟

[raziee]

با سلام.
نیاز نیست نام دامنه را در جدول آلبوم و یا اخبار ذخیره کنید. این اشتباه هست. ممکنه برای اون دامنه ، دامنه های جانشین هم انتخاب بشه.
بهتر هست شما یک جدول داشته باشید به نام Portals که اطلاعات مربوط به هر پورتال رو در اون ذخیره کنید.
یک جدول هم به نام PortalAlias که دامنه های جانشین هر پورتال رو نگهداری کنه.
شما باید با هر پورتال به صورت کاملا جداگانه رفتار کنید. صفحات، کاربرها، سطح دسترسی ها و ...
برای هر پورتال نیاز به کاربرهای کاملا جداگانه ای دارید. مثلا کاربر admin در PortalA (به طور مثالUserId = 1) با کاربر admin در PortalB (به طور مثالUserId = 2)کاملا متفاوت هستند. ممکنه نیاز داشته باشید که کاربرانی با یک نام کاربری و رمز عبور (به طور مثالUserId = 3) در همه ی پورتال ها یا چند پورتال یکی باشند.
برای زبان ها هم هر پورتال میبایست زبان های خاص خودش رو داشته باشه(ممکنه یک پورتال 3 زبان داشته باشه یک پورتال دیگه تک زبان باشه)
اما موردی که درپروژه هایی در این سطح هست اینه که نیاز ها ممکنه کاملا متفاوت باشه و همینطور نیازهایی که بعدا اضافه بشه.
به همین دلیل از شروع کار باید به فکر یک سیستم کاملا ماژولار باشید.
که هر وقت نیاز به افزودن یک امکان جدید بود به صورت جداگانه این امکان جدید پیاده سازی شده و به سیستم اصلی اضافه بشه.

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

[اوبالیت به بو]

درود بر شما جناب رضیئی


برای هر پورتال نیاز به کاربرهای کاملا جداگانه ای دارید. مثلا کاربر admin در PortalA (به طور مثالUserId = 1) با کاربر admin در PortalB (به طور مثالUserId = 2)کاملا متفاوت هستند. ممکنه نیاز داشته باشید که کاربرانی با یک نام کاربری و رمز عبور (به طور مثالUserId = 3) در همه ی پورتال ها یا چند پورتال یکی باشند

آیا باید چند پایگاه داده جداگانه داشته باشم؟ چون فرمودید باید با هر کاربر جداگانه رفتار بشه. از طرفی چون نوشتید UserID=1 برای کاربر پرتال A و بعد در ادامه نوشتید UserID=2 برای کاربر پرتال B من به یک نتیجه دیگه می رسم که باید یک پایگاه داده باشم. چون کاربر پرتال B با ID=2 معرفی شد نه ID=1. از طرفی به قول شما اگر کاربری مجوز گشت و گذار در تمام پرتال ها را داشته باشد باید همه در یک جدول ذخیره شوند.

از طرف دیگه اگر بخواهیم از Users & Groups مایکروسافت در بحث ویندوز سرور الگو بگیریم فکر کنم همه باید در یک جدول ذخیره بشوند. آیا دات نت نیوک از بحث ویندوز سرور برای مدیریت کاربران الگو گرفته؟ مایلم نظر شما رو بدونم.

[aminghaderi]

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

[d_derakhshani]

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

[اوبالیت به بو]

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


با این روش موافقم.

[A.S.Roma]

به نظر من استفاده از چند تا Database رو فراموش کنید.
نظر من اینه که شما در Step‌اول نرید سراغ Data Model کردن.

سعی کنید ابتدا بیزنس رو مدل کنید زمانی که به Class Diagram رسیدید و ارتباط و Multiplicity بین موجودیت ها مشخص شد به‌راحتی می‌تونین تبدیلش کنید به Data Model .

[aminghaderi]

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

هر پرتال یک دیتابیس و برای هر زبان یک تیبل مجزا
سلام مجدد.
خوب کاری نداره که یه اسکریپت می خواد اجرا بشه و یه جدولی که قبلا ساختارش تولید شده و برای همه زبان ها یک شکل است.
من سعادت تجربه بکابگیری از دیتابیس های پیچیده و حجیم رو تا بحال نداشتم و نه دیدم ولی فکر کنم زیاد پیچیده باشه برای گرفتن فایل پشتیبانی کمی سخت باشه و همچنین تحلیل و توسعه پایگاه (که به نظر من از همه چیز مهم تر هست)؟!
مورد بعدی هم که به ذهنم می یاد گرفتن گزارشات داده ای از پایگاه هم بدین روش خیلی مشکل می شه و شاید به یه DBA نسبتا حرفه ای نیاز پیدا کنیم(درصورتی که واقعا کار بزرگ شده باشه)؟!

[d_derakhshani]

سلام مجدد.
خوب کاری نداره که یه اسکریپت می خواد اجرا بشه و یه جدولی که قبلا ساختارش تولید شده و برای همه زبان ها یک شکل است.
من سعادت تجربه بکابگیری از دیتابیس های پیچیده و حجیم رو تا بحال نداشتم و نه دیدم ولی فکر کنم زیاد پیچیده باشه برای گرفتن فایل پشتیبانی کمی سخت باشه و همچنین تحلیل و توسعه پایگاه (که به نظر من از همه چیز مهم تر هست)؟!
مورد بعدی هم که به ذهنم می یاد گرفتن گزارشات داده ای از پایگاه هم بدین روش خیلی مشکل می شه و شاید به یه DBA نسبتا حرفه ای نیاز پیدا کنیم(درصورتی که واقعا کار بزرگ شده باشه)؟!

دوست عزیز این پروژه ها پروژها های کوچیکه. پروژه ای که بزرگه که بالای 200 تا جدول داشته باشه. معمولا 400 یا 500 دیگه میشه واقعا بزرگ.
موضوع اجرای اسکریپت نیست، موضوع maitenance بهتره و کم هزینه تره. این یکی از بزرگترین چالش ها بعد تولید یک نرم افزار به حساب میاد.
شما بین اینکه یک رکورد تو جدول بزنید و بدون هیچ تغییر دیگه ای یک زبان به برنامه تون اضافه شه با اینکه اسکریپت بگیرید و روی یک دینابیس دیگه اطلاعات رو بریزید و همچنین کدهایی بنویسید که از این به بعد به جای 3 تا پایگاه داده 4 تا رو پشتیبانی کنه و اینکه هر تغییر رو در 3 تا 4 تا دیتابیس اعمال کنید کدوم رو ترجیح میدید؟

[raziee]

درود بر شما جناب رضیئی
آیا باید چند پایگاه داده جداگانه داشته باشم؟ چون فرمودید باید با هر کاربر جداگانه رفتار بشه. از طرفی چون نوشتید UserID=1 برای کاربر پرتال A و بعد در ادامه نوشتید UserID=2 برای کاربر پرتال B من به یک نتیجه دیگه می رسم که باید یک پایگاه داده باشم. چون کاربر پرتال B با ID=2 معرفی شد نه ID=1. از طرفی به قول شما اگر کاربری مجوز گشت و گذار در تمام پرتال ها را داشته باشد باید همه در یک جدول ذخیره شوند.

از طرف دیگه اگر بخواهیم از Users & Groups مایکروسافت در بحث ویندوز سرور الگو بگیریم فکر کنم همه باید در یک جدول ذخیره بشوند. آیا دات نت نیوک از بحث ویندوز سرور برای مدیریت کاربران الگو گرفته؟ مایلم نظر شما رو بدونم.

با درود.
استفاده از چند پایگاه داده صحیح نیست.
اطلاعات تمامی کاربران در یک جدول نگهداری خواهند شد.
حالا شما باید ببینید که کاربران شما در پورتال های مختلف به چه صورت هستند. یعنی اگر کاربران هر پورتال با پورتال دیگه کاملا متفاوت هستند استفاده از یک کلید خارجی به نام PortalId در جدول کاربران میتونه اونها رو از همدیگه متمایز کنه. در این حالت شما میتونید مثلا چند کاربر با نام کاربری Admin داشته باشید چون PortalId های متفاوت دارند.
در غیر این صورت (کاربر ها در پورتال های دیگه هم هستند) شما نیاز به یک جدول کمکی UserInPortals خواهید داشت تا کاربر ها رو به پورتا ها انتصاب بده (دقیقا مثل انتصاب چند Role به یک کاربر).
در مورد سطح دسترسی شما باید ببینید منظورتون از "سطح دسترسی" چیست.
اگه سطح دسترسی رو از دید کاربران در یک سازمان نگاه کنیم. بعضی از کاربر ها هستن که تنها به برخی صفحات دسترسی دارند. بعضی از کاربران به برخی از قسمت های یک صفحه دسترسی دارند و برخی دیگه در یک قسمت خاص به بخش ها یا عملیات متفاوتی دسترسی خواهند داشت.
مثلا سیستم خبر یک سازمان رو در نظر بگیرید.
یک کاربر تنها مجوز دیدن صفحه خبر رو داره(که عموما تمامی کاربران هستند). یک کاربر دیگه میتونه نظرش رو در مورد اون خبر بگذاره. یک کاربر دیگه متونه اون کامنت رو ویرایش و یا حذف کنه. کاربر دیگه ای میتونه پیش نویسی از اخبار آماده کنه کاربر دیگه ای میتونه خبر رو تائید و قابل نمایش کنه و .... (البته بحث "جریان کاری" هم جایگاه خودش رو در برخی قسمت ها مثل همین خبر داره)
این موارد به پروژه ی شما و میزان بزرگی پروژه تون داره. اگه بیشتر توضیح بدید، بهتر میتونیم کمک کنیم)


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

[aminghaderi]

اینکه اسکریپت بگیرید و روی یک دینابیس دیگه اطلاعات رو بریزیدنه من منظورم این نیست؟!
من می گم برای هر پرتال یک دیتابیس .
و برای هر زبان یه جدول جدید.

حالا روش من هم صرفا یه روش هست ، که خودم هم بالا گفتم که بهترین نیست و فقط یه راهه.

ولی درباره این جمله :

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

[aminghaderi]

میتونه یه این روش پیاده بشه اما در حجم داده های بسیار بالا.
در حجم داده هایی که ما باهاشون سروکار داریم نیاز نیست.
فکر می کنم صورت سوال دوستمون کمی با صورت مسئله فرق می کنه ؟!

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

[d_derakhshani]

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