نیاز به راه حل طراحی !!

Printable View

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

نیاز به راه حل طراحی !!

سلام

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

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

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

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

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

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

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

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

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

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

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

راه حل معرفی کنید !!
پنج شنبه 12 بهمن 1385, 11:14 صبح
zerobit-ltd

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

نقل قول:

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

منظورتو نفهمیدم؟
چرا 48 جدول؟ یه جدول نظرسنجی بگیر. چون فیلد هاش برای تمام بخشها می تونه ثابت باشه. بعدش یه فیلد بگیر که مشخص کنه هر نظر مربوط به کدوم بخشه.
پنج شنبه 12 بهمن 1385, 11:49 صبح
manager

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

سلام
می خواهم در مورد پایگاه داده من را راهنمایی کنید
پنج شنبه 12 بهمن 1385, 12:05 عصر
zerobit-ltd

نقل قول:

نوشته شده توسط yade_gham

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

به نظر من سوال خودت رو در تالار مربوطه مطرح کنی، زودتر و بهتر جواب می گیری.
https://barnamenevis.org/forumdisplay.php?f=71
پنج شنبه 12 بهمن 1385, 12:43 عصر
zerobit-ltd

نقل قول:

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

به نظر من اگر از طریق برنامه نویسی این کارو انجام بدی، بهتره. چون همون طور که خودت گفتی، موقع اعمال تغییرات یه کوچولو اذیت می شی.
پنج شنبه 12 بهمن 1385, 12:49 عصر
manager

نقل قول:

نوشته شده توسط zerobit-ltd

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

از نظر مهندسی کدوم روش بهتره ؟ آیا برای این مشکل Design Pattern خاصی وجود داره یا نه ؟
پنج شنبه 12 بهمن 1385, 15:02 عصر
zerobit-ltd

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

نقل قول:

نوشته شده توسط zerobit-ltd

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

از توجه تون ممنونم ولی زیاد با نظرتون موافق نیستم.
پنج شنبه 12 بهمن 1385, 19:22 عصر
Microsoft.net

نقل قول:

نوشته شده توسط zerobit-ltd

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

جل الخالقققققق
جمعه 13 بهمن 1385, 10:57 صبح
zerobit-ltd

نقل قول:

نوشته شده توسط Microsoft.net

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

از چی تعجب کردی بابایی؟
جمعه 13 بهمن 1385, 10:59 صبح
zerobit-ltd

نقل قول:

نوشته شده توسط manager

از توجه تون ممنونم ولی زیاد با نظرتون موافق نیستم.

پس با کمال تاسف باید بگم باید بری سراغ همون 48 تا جدول.
جمعه 13 بهمن 1385, 19:30 عصر
Microsoft.net

نقل قول:

نوشته شده توسط zerobit-ltd

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

از اینکه اینقدر قشنگ و راحت و سریع و بدون رودربایسی با یک فن "جودانسوکی" زدی تو دهن مهندسی نرم افزار و علوم انفورماتیک و تئوریسین ها و سالها تلاش و تحقیق و ...
جمعه 13 بهمن 1385, 19:51 عصر
zerobit-ltd

جودانسوکی واسه کدوم رشته است؟ شاید یه فن مهندسی نرم افزاره یا شایدم تو کتاب پرسمن اومده باشه! (البته ممکنه تو ترجمه استاد چشم خدا یه همچین فنی اضافه شده باشه!)
شنبه 14 بهمن 1385, 07:40 صبح
smhoseyni

نقل قول:

نوشته شده توسط manager

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

کاش DBMS ی که انتخاب کردی از شیءگرایی پشتیبانی می‌کرد.
البته می‌توانی با استفاده از میان‌افزارهای مبدل شیءگرایی به رابطه‌ای (Object2Relational)
مانند Hibernate مشکلت رو حل کنی. در این صورت به راحتی می‌توانی یک ساختار سلسله مراتبی
از کلاس‌ها برای داده هایت ایجاد کنی (با حداقل فیلد‌های تکراری) و تبدیل آن به کلاس‌های پایگاه داده و مدیریت ارتباط آن در طی اجرای برنامه را به آن middle ware بسپاری.
دوشنبه 16 بهمن 1385, 10:53 صبح
smhoseyni

اگه استفاده کردی لطفا راجع به کارایی و راحتی استفاده از آن در net. بنویس.
روی java/j2ee که خیلی خوب جواب میده.
سه شنبه 17 بهمن 1385, 12:50 عصر
manager

من از Gentle.Net استفاده کردم البته Gentle یه ORM هست و من نمی دونم که منظور حضرت عالی همین بود یا نه ولی هنوز از مبدل واسطی که معرفی کردید هنوز استفاده نکردم. تو Gentle.Net برای دسته های موضوعات که قبلا توضیح دادم از مزایای شی گرائی استفاده کردم و جواب داد.(اطلاعات بیشتر در مورد دسته های بخش ها) یعنی یک کلاس پدر برای دسته ایجاد کردم و سایر دسته ها از آن به ارث بردن ولی مشکل در بخش کدینگ DAL یا BL نیست بلکه در طراحی دیتابیس هست و که من مجبورم به ازای هر دسته یک جدول بسازم.
سعی می کنم سوالم رو واضح تر مطرح کنم. آیا حفظ شفافیت سیستم در پایگاه داده ها مهم است یا خیر ؟ به عبارت دیگر مشکل فوق الذکر با نادیده گرفتن این مهم (شفاف سازی سیستم) حل خواهد شد حال آنکه می توان شفاف سازی را در DAL انجام داد.
چهارشنبه 18 بهمن 1385, 11:05 صبح
MM_Mofidi

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

نقل قول:

نوشته شده توسط MM_Mofidi

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

وجود sp مستلزم استفاده از mssql حال آنکه من بیشتر دوست داستم به معماری و مارک DB وابسته نباشم. مطلب دیگه اینکه هنگامی که از ORM یا امثالهم استفاده می شه به سختی می شه از sp ها استفاده کرد.
از جوابتون ممنونم ولی هنوز سوال من بی جواب مانده :

نقل قول:

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