نیاز به راه حل طراحی !! [بایگانی]

manager

پنج شنبه 12 بهمن 1385, 00:15 صبح

سلام

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

http://i15.tinypic.com/4cwwv44.jpg

همان ظور که مشاهده می فرمائید. هر جدول بخش دارای یک جدول دسته نیز می باشد. در این سیستم حدود 8 بخش وجود دارد و برای هر بخش یک عدد جدول دسته در نظر گرفته شوده است.

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

خود بنده روش اول را انتخاب کردم به خاطر علت های زیر :

1-شفاف سازی سیستم

2-استفاده از محدودیت و امتیاز روابط (Relationships)

3-ساده سازی پیاده سازی

4-جلوگیری از Redundancy

5-جداکردن داده ها از نظر منطقی

خوب حالا مشکل کجاست ؟ من اگر 8 تا جدول برای بخش ها داشتم الان به 16 عدد افزایش پیدا کرده ! حالا اگر بخوام برای هر رکورد اطلاعاتی در این جداول یه نظر سنجی هم بذارم چیزی در حدود 48 جدول به وجود می آید !!!! و اگر بعد ها بخوام تغییر کوچکی در یکی از فیلدهای نظر سنجی بدم باید 32 بار این کار رو انجام بدم !!! ونکته مهم تر اینکه تعداد کلاس هائی که به دیتابیس مپ می شوند نیز افزایش پیدا می کند و مدیریت پیچیده ای را طلب می کنند ؟

راه حل معرفی کنید !!

zerobit-ltd

پنج شنبه 12 بهمن 1385, 11:14 صبح

این ساختار خوبه. چون atomic بودن رو رعایت کردی.
ولی به نظر من جداولی رو که می تونی، با هم ترکیب کن. مثلا اگر فیلدهای جداول مقالات و کتاب ها زیاد با هم تفاوت ندارند و می تونی با یه فیلد bit اونها رو از هم تشخیص بدی، این دو تا جدول رو با هم ترکیب کن.

حالا اگر بخوام برای هر رکورد اطلاعاتی در این جداول یه نظر سنجی هم بذارم چیزی در حدود 48 جدول به وجود می آید !!!!

منظورتو نفهمیدم؟
چرا 48 جدول؟ یه جدول نظرسنجی بگیر. چون فیلد هاش برای تمام بخشها می تونه ثابت باشه. بعدش یه فیلد بگیر که مشخص کنه هر نظر مربوط به کدوم بخشه.

manager

پنج شنبه 12 بهمن 1385, 11:49 صبح

دقیقا دوست من مشکل همین جاست !! فیلد های جداول بخش های مختلف مثل کتاب و مقاله و .. با هم تفاوت دارند، چیزی در حدود 20% تفاوت !! نظر سنجی رو اگر یکجا متمرکز کنم (که همین کار رو هم کردم) دیگه نمی تونم Relation بین جداول بخش ها و جدول نظرات را بر قرار کنم و باید به صورت برنامه نویسی این کار رو کنم !!

yade_gham

پنج شنبه 12 بهمن 1385, 11:56 صبح

سلام
می خواهم در مورد پایگاه داده من را راهنمایی کنید

zerobit-ltd

پنج شنبه 12 بهمن 1385, 12:05 عصر

سلام
می خواهم در مورد پایگاه داده من را راهنمایی کنید
به نظر من سوال خودت رو در تالار مربوطه مطرح کنی، زودتر و بهتر جواب می گیری.
http://barnamenevis.org/forum/forumdisplay.php?f=71

zerobit-ltd

پنج شنبه 12 بهمن 1385, 12:43 عصر

نظر سنجی رو اگر یکجا متمرکز کنم (که همین کار رو هم کردم) دیگه نمی تونم Relation بین جداول بخش ها و جدول نظرات را بر قرار کنم و باید به صورت برنامه نویسی این کار رو کنم !!

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

manager

پنج شنبه 12 بهمن 1385, 12:49 عصر

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

از نظر مهندسی کدوم روش بهتره ؟ آیا برای این مشکل Design Pattern خاصی وجود داره یا نه ؟

zerobit-ltd

پنج شنبه 12 بهمن 1385, 15:02 عصر

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

manager

پنج شنبه 12 بهمن 1385, 15:53 عصر

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

Microsoft.net

پنج شنبه 12 بهمن 1385, 19:22 عصر

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

جل الخالقققققق

zerobit-ltd

جمعه 13 بهمن 1385, 10:57 صبح

جل الخالقققققق
از چی تعجب کردی بابایی؟

zerobit-ltd

جمعه 13 بهمن 1385, 10:59 صبح

از توجه تون ممنونم ولی زیاد با نظرتون موافق نیستم.
پس با کمال تاسف باید بگم باید بری سراغ همون 48 تا جدول.

Microsoft.net

جمعه 13 بهمن 1385, 19:30 عصر

از چی تعجب کردی بابایی؟

از اینکه اینقدر قشنگ و راحت و سریع و بدون رودربایسی با یک فن "جودانسوکی" زدی تو دهن مهندسی نرم افزار و علوم انفورماتیک و تئوریسین ها و سالها تلاش و تحقیق و ...

zerobit-ltd

جمعه 13 بهمن 1385, 19:51 عصر

جودانسوکی واسه کدوم رشته است؟ شاید یه فن مهندسی نرم افزاره یا شایدم تو کتاب پرسمن اومده باشه! (البته ممکنه تو ترجمه استاد چشم خدا یه همچین فنی اضافه شده باشه!)

smhoseyni

شنبه 14 بهمن 1385, 07:40 صبح

از نظر مهندسی کدوم روش بهتره ؟ آیا برای این مشکل Design Pattern خاصی وجود داره یا نه ؟

کاش DBMS ی که انتخاب کردی از شیءگرایی پشتیبانی می‌کرد.
البته می‌توانی با استفاده از میان‌افزارهای مبدل شیءگرایی به رابطه‌ای (Object2Relational)
مانند Hibernate (http://www.hibernate.org/)مشکلت رو حل کنی. در این صورت به راحتی می‌توانی یک ساختار سلسله مراتبی
از کلاس‌ها برای داده هایت ایجاد کنی (با حداقل فیلد‌های تکراری) و تبدیل آن به کلاس‌های پایگاه داده و مدیریت ارتباط آن در طی اجرای برنامه را به آن middle ware بسپاری.

smhoseyni

دوشنبه 16 بهمن 1385, 10:53 صبح

اگه استفاده کردی لطفا راجع به کارایی و راحتی استفاده از آن در net. بنویس.
روی java/j2ee که خیلی خوب جواب میده.

manager

سه شنبه 17 بهمن 1385, 12:50 عصر

من از Gentle.Net استفاده کردم البته Gentle یه ORM هست و من نمی دونم که منظور حضرت عالی همین بود یا نه ولی هنوز از مبدل واسطی که معرفی کردید هنوز استفاده نکردم. تو Gentle.Net برای دسته های موضوعات که قبلا توضیح دادم از مزایای شی گرائی استفاده کردم و جواب داد.(اطلاعات بیشتر در مورد دسته های بخش ها (http://www.barnamenevis.org/forum/showpost.php?p=303846&postcount=1)) یعنی یک کلاس پدر برای دسته ایجاد کردم و سایر دسته ها از آن به ارث بردن ولی مشکل در بخش کدینگ DAL یا BL نیست بلکه در طراحی دیتابیس هست و که من مجبورم به ازای هر دسته یک جدول بسازم.
سعی می کنم سوالم رو واضح تر مطرح کنم. آیا حفظ شفافیت سیستم در پایگاه داده ها مهم است یا خیر ؟ به عبارت دیگر مشکل فوق الذکر با نادیده گرفتن این مهم (شفاف سازی سیستم) حل خواهد شد حال آنکه می توان شفاف سازی را در DAL انجام داد.

MM_Mofidi

چهارشنبه 18 بهمن 1385, 11:05 صبح

شما اگر بتونید مشکل را برای تغییرات آتی حل کنید یعنی برای مثل نظر سنجی مجبور به ایجاد تغییرات یکسان در تمام query و .. نشوید مشکل حل است.
من فکر میکنم با پارامتریک نوشتن sp ها , views,queries&... شما میتونید مقدار زیادی از این مشکل را مرتفع کنید.یک جدول از نام جداول و شرایط شون و سنخیتهاشون ایجاد کن بعد به sp بگو لیست کارهاشو یا تغییراتشو توی جداولی با شرایطx از این جدول اعمال کنه این میتونه شامل هر کاری باشه حتی دوباره نویسی یا اعمال تغییرات در کد یک sp

manager

چهارشنبه 18 بهمن 1385, 13:11 عصر

شما اگر بتونید مشکل را برای تغییرات آتی حل کنید یعنی برای مثل نظر سنجی مجبور به ایجاد تغییرات یکسان در تمام query و .. نشوید مشکل حل است.
من فکر میکنم با پارامتریک نوشتن sp ها , views,queries&... شما میتونید مقدار زیادی از این مشکل را مرتفع کنید.یک جدول از نام جداول و شرایط شون و سنخیتهاشون ایجاد کن بعد به sp بگو لیست کارهاشو یا تغییراتشو توی جداولی با شرایطx از این جدول اعمال کنه این میتونه شامل هر کاری باشه حتی دوباره نویسی یا اعمال تغییرات در کد یک sp
وجود sp مستلزم استفاده از mssql حال آنکه من بیشتر دوست داستم به معماری و مارک DB وابسته نباشم. مطلب دیگه اینکه هنگامی که از ORM یا امثالهم استفاده می شه به سختی می شه از sp ها استفاده کرد.
از جوابتون ممنونم ولی هنوز سوال من بی جواب مانده :
آیا حفظ شفافیت سیستم در پایگاه داده ها مهم است یا خیر ؟به عبارت دیگر مشکل فوق الذکر با نادیده گرفتن این مهم (شفاف سازی سیستم) حل خواهد شد حال آنکه می توان شفاف سازی را در DAL انجام داد.