نمایش نتایج 1 تا 31 از 31

نام تاپیک: مشکل در طراحی اصولی یک دیتابیس ساده

  1. #1
    کاربر دائمی
    تاریخ عضویت
    فروردین 1387
    محل زندگی
    www
    پست
    741

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

    با سلام

    من تو یه قسمتی از یک پروژه گیر کردم
    گفتم از شما دوستان کمک بگیرم
    این چیزی که من مطرح میکنم پروژه اصلی نیست


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

    برای حل این مشکل چه راه حلی باید انجام داد .

  2. #2
    کاربر دائمی آواتار Davidd
    تاریخ عضویت
    آذر 1392
    محل زندگی
    تهران
    پست
    391

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    سلام. از Generalization استفاده کن. میتونی یک جدول پایه داشته باشی برای خصوصیات مشترک با کلید id و برای هر نوع محصول هم یک جدول جداگانه داشته باشی با کلید id و خصوصیات مختص نوع محصول که این کلید id، کلید خارجی هم هست و به id جدول پایه اشاره می کنه.

  3. #3
    کاربر دائمی
    تاریخ عضویت
    فروردین 1387
    محل زندگی
    www
    پست
    741

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    دوست عزیز حرف شما متین
    ولی زمانیکه برای هر محصول یک جدول با خصوصیات مربوط به اون بسازیم ای دی اون رو بخوایم تو جدول پایه بزاریم که با ای دی های دیگه غیر قابل تشخیص میشه
    مثلا برای یک محصول یک جدول داریم با آی دی و نام محصول و طول و عرض
    و برای محصول دیگه یک جدول داریم با آی دی و نام محصول و وزن
    زمانیکه بخوایم از هر کدوم از این جداول ای دی رو در جدول پایه بزاریم که قابل تشخیص نیست که فلان آی دی برای جدول اول بوده یا جدول دوم یا ....
    در ضمن اگر بخواهیم برای هر محصول یک جدول بسازیم اگر 1000 محصول باشه که .....
    آخرین ویرایش به وسیله IMANAZADI : سه شنبه 08 اردیبهشت 1394 در 09:03 صبح

  4. #4
    کاربر دائمی
    تاریخ عضویت
    اسفند 1384
    محل زندگی
    تهران
    پست
    1,629

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    نقل قول نوشته شده توسط IMANAZADI مشاهده تاپیک
    دوست عزیز حرف شما متین
    ولی زمانیکه برای هر محصول یک جدول با خصوصیات مربوط به اون بسازیم ای دی اون رو بخوایم تو جدول پایه بزاریم که با ای دی های دیگه غیر قابل تشخیص میشه
    مثلا برای یک محصول یک جدول داریم با آی دی و نام محصول و طول و عرض
    و برای محصول دیگه یک جدول داریم با آی دی و نام محصول و وزن
    زمانیکه بخوایم از هر کدوم از این جداول ای رو در جدول پایه بزاریم که قابل تشخیص نیست که فلان آی دی برای جدول اول بوده یا جدول دوم یا ....
    در ضمن اگر بخواهیم برای هر محصول یک جدول بسازیم اگر 1000 محصول باشه که .....
    سلام
    دو تا مطلب:

    اول این که پیش‌نهاد دوسمتون Davidd درسته، فقط ایشون خیلی قضیه رو شفاف برات ننوشته بود. شما تو جدول‌های جنبی نباید برای Id خودت
    Identity تغیین کنی. بلکه بجای این کار اون ستون رو کلید خارجی می‌کنی به Id در جدول اصلی ( ضمن این که کلید اصلی جدول خودش هم هست.)
    یعنی تو جدول‌های جنبی ستون Id هم کلید اصلی هست و هم کلید فرعی. و این روش کار می‌کنه، خیالت راحت باشه.

    دوم این که بله، انتقاد شما به تعداد جدول‌ها اگه تعداد محصولات زیاد باشه کاملاً درسته. و پیش‌نهاد من استفاده از یک جدول اصلی برای خاصیت‌های
    عمومی محصولات است و نگهداری بقیه‌ی اطلاعات خاص محصولات به صورت MetaData.
    این روش یه کم پیاده‌سازیش سخته، اما دقیقاً چیز1ی هست که شما نیاز داری.
    1. یه جدول می‌گیری که مشخصات فیلد‌های اطلاعاتی مورد نیازی محصولات رو توش نگهداری می‌کنی. مثلاً میزان حافظه‌ی اصلی موبایل.
    2. یه جدول می‌گیری که مقدار اون خصیصه رو برای هر کالا می‌تونه نگهداری کنه. من تمام انواع داده رو به صورت رشته نگهداری می‌کنم، اما می‌تونی
    تو این جدول چند تا ستون برای انواع رشته‌ای، عددی و تاریخ به صورت جداگانه نگهداری کنی.
    این جدول دو تا کلید خارجی داره، یکی به جدول نوع فیلدها ( ایتم 1 ) و یکی به جدول محصولات که Id محصول هست.

    دیگه تنها چیزی که لازم داری متد یا SP ای هست که این ستون‌های از هم جدا رو بازیابی کنه و در کنار هم نمایش بده.
    حالا اگه 1000 تا محصول متفاوت هم داشته باشی، فقط دو تا جدول به جدول اصلی اضافه کردی، و نیازی به ویرایش دیتابیس هم نداره.
    با هر محصول جدید، فقط خصیصه‌های اون رو به جدول اول و مقدارها رو به جدول دوم اضافه می‌کنی.

    صبا صبوحی

  5. #5
    کاربر دائمی
    تاریخ عضویت
    فروردین 1387
    محل زندگی
    www
    پست
    741

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    آقای صبا صبوحی عزیز سلام و عرض ادب
    ما همیشه مدیون اطلاعات فنی شما هستیم

    اما من متوجه منظور شما نشدم

    اول این که پیش‌نهاد دوسمتون Davidd درسته، فقط ایشون خیلی قضیه رو شفاف برات ننوشته بود. شما تو جدول‌های جنبی نباید برای Id خودت
    Identity تغیین کنی. بلکه بجای این کار اون ستون رو کلید خارجی می‌کنی به Id در جدول اصلی ( ضمن این که کلید اصلی جدول خودش هم هست.)
    یعنی تو جدول‌های جنبی ستون Id هم کلید اصلی هست و هم کلید فرعی. و این روش کار می‌کنه، خیالت راحت باشه.
    میشه بیشتر توضیح بدید یا اگر براتون ممکن است یک دیاگرام sample واسم بزارید (تو برنامه paint بکشید کفایت میکنه)

    اینو متوجه بشم تا قسمت دوم سوال

  6. #6
    کاربر دائمی
    تاریخ عضویت
    فروردین 1387
    محل زندگی
    www
    پست
    741

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    چی شد دوستان

  7. #7
    کاربر دائمی آواتار Davidd
    تاریخ عضویت
    آذر 1392
    محل زندگی
    تهران
    پست
    391

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

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

  8. #8
    کاربر دائمی
    تاریخ عضویت
    فروردین 1387
    محل زندگی
    www
    پست
    741

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    کاش میشد یه دیاگرام ساده از جدول ها و روابط واسم میذاشتی

  9. #9
    کاربر دائمی آواتار Davidd
    تاریخ عضویت
    آذر 1392
    محل زندگی
    تهران
    پست
    391

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    subclass-lots-scheme.gif
    این تصویر گویاست. در جدول CityLots و CountryLots فیلد lotID هم کلید اصلی است و هم کلید خارجی. همانطور که گفتم این روش برای وقتی تعداد دسته ها ثابت و کم باشه مناسبه

  10. #10
    کاربر دائمی
    تاریخ عضویت
    فروردین 1387
    محل زندگی
    www
    پست
    741

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده


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

  11. #11
    کاربر دائمی آواتار Davidd
    تاریخ عضویت
    آذر 1392
    محل زندگی
    تهران
    پست
    391

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    نقل قول نوشته شده توسط IMANAZADI مشاهده تاپیک

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

  12. #12
    کاربر دائمی
    تاریخ عضویت
    اسفند 1384
    محل زندگی
    تهران
    پست
    1,629

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    نقل قول نوشته شده توسط IMANAZADI مشاهده تاپیک

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

    نوشته‌های دوستمون Davidd کاملاً درسته. من یه کم قضیه رو باز می‌کنم هر چند که این روش به درد صورت مساله‌ی شما نمی‌خوره.

    می‌خوایم یه موبایل رو ذخیره کنیم.
    1. یه سطر به جدول کالاها اضافه می‌کنم که فقط شامل نوع کالا ( موبایل ) نام کالا ( ایفون 6 ) و مثلاً کد کالا هست ( مثلاً بارکد کالا )
    اضافه کردن یک سطر به این جدول یه Id برای من تولید می‌کنه که مثلاً 315 هست. ( چون Id از نوع Identity هست )
    2. حالا به جدول اطلاعات موبایل یه رکورد اضافه می‌کنم شامل Id ( با مقدار 315 )، میزان حافظه ( 64 ) تعداد سیم‌کارت ( 1 ) و غیره

    و حتماً باید هر دو اضافه‌کردن داخل یک Transaction انجام بشه.

    حالا می‌خوایم یه مانیتور رو اضافه کنیم.
    1. یک سطر به جدول کالاها اضافه می‌کنیم که شامل اطلاعات نوع کالا ( مانیتور ) نام کالا ( Asus ) و بارکد کالا هست.
    اضافه کردن این سطر هم یه Id ایجاد می‌کنه ( مثلاً 317 )
    2. یک سطر به جدول مانیتورها اضافه می‌کنیم که شامل Id (با مقدار 317 ) و قطر ( "19 ) و قدرت تفکیک و کنتراست و مثلاً داشتن یا نداشتن Speaker هست.

    توجه کن که تو جدول کالاها هم مانیتور اومده و هم موبایل ( Id های 315 و 317 رو داریم )
    اما تو جدول موبایل‌ها فقط 315 رو داریم و تو جدول مانیتورها هم فقط 317 رو.

    از نظر Relation ها:
    1. چون Idها تو جدول‌های مانیتور و موبایل از نوع Identity نیستن، پس می‌تونیم ( و باید ) بهشون مقدار بدیم
    2. چون Idها Primary Key هستن، پس یکتا هم هستن، پس رابطه با جدول اصلی ( کالاها ) به صورت یک به یک نمایش داده می‌شه.
    اما با توجه به این که فقط برای برخی از سطرهای جدول اصلی تو این جدول سطر متناظر وجود داره، بنابراین نرمال‌سازی رو نقض نمی‌کنه.
    3. چون Idها کلید خارجی برای جدول اصلی هستن، امکان حذف از جدول اصلی بدون حذف شدن سطر متناظر وجود نداره.

    نکته:
    تو دریافت اطلاعات مثلاً موبایل‌ها نیازی نداری که شرط بگذاری که نوع کالا حتماً موبایل باشه. کافیه جدول کالاها رو با جدول موبایل‌ها
    join کنی، فقط فهرست موبایل‌ها رو دریافت می‌کنی.

    راستش دیگه بیشتر نمی‌تونم توضیح بدم. امیدوارم که کاملاً روشن بوده باشه.
    و باز هم متذکر می‌شم که این راه حل همونطور که دوستمون Davidd نوشته بود، فقط وقتی به درد می‌خوره که تنوع محصولات کم و ثابت باشه.
    اگه قراره هر روز محصول جدیدی اضافه بشه و خصیصه‌های جدیدی هم داشته باشه، راه حل همونی هست که قبلاً گفتم. یعنی استفاده از
    MetaData یا نگهداری اطلاعات به صورت Xml یا Json توی یک ستون از جنس ( NVARCHAR( MAX که فقط مشکلش اینه که اطلاعات باید سطر
    به سطر تحلیل بشه. من روش MetaData رو ترجیح می‌دم.

    صبا صبوحی

  13. #13
    کاربر دائمی
    تاریخ عضویت
    فروردین 1387
    محل زندگی
    www
    پست
    741

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

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

  14. #14
    کاربر دائمی
    تاریخ عضویت
    فروردین 1387
    محل زندگی
    www
    پست
    741

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    نقل قول نوشته شده توسط SabaSabouhi مشاهده تاپیک
    سلام
    من دو سه ساعت نیودم، چقدر پست رد و بدل شد

    نوشته‌های دوستمون Davidd کاملاً درسته. من یه کم قضیه رو باز می‌کنم هر چند که این روش به درد صورت مساله‌ی شما نمی‌خوره.

    می‌خوایم یه موبایل رو ذخیره کنیم.
    1. یه سطر به جدول کالاها اضافه می‌کنم که فقط شامل نوع کالا ( موبایل ) نام کالا ( ایفون 6 ) و مثلاً کد کالا هست ( مثلاً بارکد کالا )
    اضافه کردن یک سطر به این جدول یه Id برای من تولید می‌کنه که مثلاً 315 هست. ( چون Id از نوع Identity هست )
    2. حالا به جدول اطلاعات موبایل یه رکورد اضافه می‌کنم شامل Id ( با مقدار 315 )، میزان حافظه ( 64 ) تعداد سیم‌کارت ( 1 ) و غیره

    و حتماً باید هر دو اضافه‌کردن داخل یک Transaction انجام بشه.

    حالا می‌خوایم یه مانیتور رو اضافه کنیم.
    1. یک سطر به جدول کالاها اضافه می‌کنیم که شامل اطلاعات نوع کالا ( مانیتور ) نام کالا ( Asus ) و بارکد کالا هست.
    اضافه کردن این سطر هم یه Id ایجاد می‌کنه ( مثلاً 317 )
    2. یک سطر به جدول مانیتورها اضافه می‌کنیم که شامل Id (با مقدار 317 ) و قطر ( "19 ) و قدرت تفکیک و کنتراست و مثلاً داشتن یا نداشتن Speaker هست.

    توجه کن که تو جدول کالاها هم مانیتور اومده و هم موبایل ( Id های 315 و 317 رو داریم )
    اما تو جدول موبایل‌ها فقط 315 رو داریم و تو جدول مانیتورها هم فقط 317 رو.

    از نظر Relation ها:
    1. چون Idها تو جدول‌های مانیتور و موبایل از نوع Identity نیستن، پس می‌تونیم ( و باید ) بهشون مقدار بدیم
    2. چون Idها Primary Key هستن، پس یکتا هم هستن، پس رابطه با جدول اصلی ( کالاها ) به صورت یک به یک نمایش داده می‌شه.
    اما با توجه به این که فقط برای برخی از سطرهای جدول اصلی تو این جدول سطر متناظر وجود داره، بنابراین نرمال‌سازی رو نقض نمی‌کنه.
    3. چون Idها کلید خارجی برای جدول اصلی هستن، امکان حذف از جدول اصلی بدون حذف شدن سطر متناظر وجود نداره.

    نکته:
    تو دریافت اطلاعات مثلاً موبایل‌ها نیازی نداری که شرط بگذاری که نوع کالا حتماً موبایل باشه. کافیه جدول کالاها رو با جدول موبایل‌ها
    join کنی، فقط فهرست موبایل‌ها رو دریافت می‌کنی.

    راستش دیگه بیشتر نمی‌تونم توضیح بدم. امیدوارم که کاملاً روشن بوده باشه.
    و باز هم متذکر می‌شم که این راه حل همونطور که دوستمون Davidd نوشته بود، فقط وقتی به درد می‌خوره که تنوع محصولات کم و ثابت باشه.
    اگه قراره هر روز محصول جدیدی اضافه بشه و خصیصه‌های جدیدی هم داشته باشه، راه حل همونی هست که قبلاً گفتم. یعنی استفاده از
    MetaData یا نگهداری اطلاعات به صورت Xml یا Json توی یک ستون از جنس ( NVARCHAR( MAX که فقط مشکلش اینه که اطلاعات باید سطر
    به سطر تحلیل بشه. من روش MetaData رو ترجیح می‌دم.

    صبا صبوحی


    اگر درست متوجه شده باشم شما همچین چیزی را میگید


    اونوقت رابطه بین جدول واسط و کالا چه شکلی میشه ؟؟؟؟!!!!
    عکس های ضمیمه عکس های ضمیمه

  15. #15
    کاربر دائمی آواتار Davidd
    تاریخ عضویت
    آذر 1392
    محل زندگی
    تهران
    پست
    391

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    نقل قول نوشته شده توسط IMANAZADI مشاهده تاپیک
    دوست گرامی میتونی یک مثال بزنی که دو موجودیت که نسبت به هم مستقل هستند ولی با هم رابطه یک به یک دارند
    خوب همچین موجودیتی رو میشه دنباله فیلد های جدول اول اضافه کرد و از ساخت جدول دوم پرهیز کرد
    فرض کنید در یک سالن سینما هر صندلی مخصوص یک نفره و هر نفر نیز فقط میتونه یک صندلی انتخاب میکنه. در اینصورت باید مشخصات صندلی و فرد در یک جدول ذخیره بشه؟
    اون چیزی که شما تو ذهنته یه چیز دیگه است و بد برداشت کردی. وقتی ارتباط دو موجودیت 1-1 یا 1-n باشه نیاز به ایجاد جدول سوم نیست کافیه یه فیلد کلید خارجی به یکی از دو جدول اضافه بشه.

  16. #16
    کاربر دائمی آواتار ghasem110deh
    تاریخ عضویت
    اردیبهشت 1393
    محل زندگی
    تهران
    پست
    1,148

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

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

    و حتماً باید هر دو اضافه‌کردن داخل یک Transaction انجام بشه.
    این یعنی چی ، همزمان تو هر دو جدول درج بشن ؟
    در مورد رابطه ها (1-1 ، 1-n و n-n) یکم بیشتر توضیح بدین !!!

  17. #17
    کاربر دائمی
    تاریخ عضویت
    اسفند 1384
    محل زندگی
    تهران
    پست
    1,629

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

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



    این یعنی چی ، همزمان تو هر دو جدول درج بشن ؟
    در مورد رابطه ها (1-1 ، 1-n و n-n) یکم بیشتر توضیح بدین !!!
    سلام
    دقیقاً به همین دلیل هست که من پیش‌نهاد می‌کنم وقتی پروژه‌ای می‌گیری با یک طراح
    دیتامدل همکاری کنی. نباید نگران هزینه‌ی این کار باشی، چون در پایان کار این همکاری به نفعت می‌شه.

    و اما رابطه‌ها:
    رابطه‌ی یک به یک هنگامی معنی داره که دو جدول حاوی اطلاعاتی هستند که به ازای هر سطر از جدول اول
    صفر یا یک سطر در جدول دوم وجود داره و نه بیشتر.
    مثلاً فرض کن یه جدول «اشخاص» داری. و یک جدول «مشتری» و یک جدول «کارمندان».
    یک شخص در جدول اشخاص تعریف می‌شه، مثلاً «صبا صبوحی». حالا اگه این شخص مشتری باشه
    درجدول مشتریان هم یک سطر بهش اختصاص داده می‌شه به همراه اطلاعاتی مثل شماره مشتری،
    کد اقتصادی و نوع مشتری ( دائمی، موردی، . . . ) و اگه مشتری نباشه در جدول مشتریان هیچ سطری
    براش وجود نداره. ممکنه این شخص کارمند باشه، پس تو جدول کارمندان یک سطر می‌گیره و اطلاعات
    کارمندی مثل محل خدمت، شماره پرسنلی، تلفن داخلی براش ثبت می‌شه.

    با این تعریف هر شخص در جدول اشخاص یک سطر داره، و در جدول‌های مشتری و کارمند یک یا صفر
    سطر می‌تونه داشته باشه. این یک ارتباط یک به یک هست.
    اگه دو جدول باشن که وجود هر سطر در جدول اول حتماً معادل یک سطر در جدول دوم باشه، این دو جدول
    باید ادغام بشن. اما با تعریف ما وجود سطر معادل در جدول‌های مشتری و کارمند الزامی نیست.

    ارتباط 1-n خیلی عمومی‌تره. مثلاً یک فاکتور خرید و اقلام اون ارتباط 1-n دارن. یعنی به ازای یک سطر فاکتور
    چند سطر اقلام براش ثبت می‌شه.

    و اما ارتباط n-m که در صورت وجود باید با اضافه کردن یک جدول واسط نرمال بشه.
    مثلاً فرض کن من و شما تو 3 بانک حساب داریم. پس برای هر فرد چند بانک می‌تونه وجود داشته باشه.
    و اما از طرف دیگه هر بانک هم می‌تونه چند تا مشتری مثل من و شما داشته باشه.
    در این حالت بین دو جدول ارتباط n-m برقرار نمی‌کنیم. یه جدول واسط می‌گیریم که شامل
    کلیدهای خارجی به جدول‌های بانک و مشتری هست. این جدول با بانک ارتباط 1-n و با مشتری
    هم به همین صورت ارتباط داره. و به این ترتیب از بروز یک ارتباط n-m بین بانک و مشتری اجتناب می‌کنیم.

    صبا صبوحی

  18. #18
    کاربر دائمی آواتار ghasem110deh
    تاریخ عضویت
    اردیبهشت 1393
    محل زندگی
    تهران
    پست
    1,148

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    سلام و ممنون
    ---------------
    الان با این اوصاف من این رو طراحی کردم (عکس ضمیمه)
    قبلا برای نرم افزار یه فاکتور جدا میزدم و برای مابقی (5 جدول دیگه که به نوعی کالا هستن) یه فاکتور بدون رابطه (یعنی دستی وارد میکردم اطلاعات رو نه با توجه به آیدی)

    الان ظاهرا میشه همه رو توی یک فاکتور آورد ؟
    توی جوین کردن و ... به مشکل نمیخورم ؟ (واسه گزارشات)
    یا واسه حذف و ویرایش (چون دیتابیس قبلی مشکل ویرایش زبان برنامه نویسی رو داشتم) --> که میگفت این کلید خارجی داره (ولی حذف مشکلی نداشت)
    البته گزینه حذف و ویرایش کلید خارجی رو روی cascade گذاشته بودم !
    .
    .
    .
    الان واسه همه جداول که ریلیشن دارن ، این کار رو کردم (cascade)
    عکس های ضمیمه عکس های ضمیمه

  19. #19
    کاربر دائمی
    تاریخ عضویت
    اسفند 1384
    محل زندگی
    تهران
    پست
    1,629

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    سلام
    اتفاقاً تو join خیلی هم راحتی، کافیه جدول فاکتور و نرم‌افزار رو join کنی، فقط فاکتور‌هایی میاد که مربوط به نرم‌افزار باشه. ( چون تو جدول‌های دیگه
    سطری براش تعریف نشده )

    صبا صبوحی

  20. #20
    کاربر دائمی آواتار ghasem110deh
    تاریخ عضویت
    اردیبهشت 1393
    محل زندگی
    تهران
    پست
    1,148

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    نقل قول نوشته شده توسط SabaSabouhi مشاهده تاپیک
    سلام
    اتفاقاً تو join خیلی هم راحتی، کافیه جدول فاکتور و نرم‌افزار رو join کنی، فقط فاکتور‌هایی میاد که مربوط به نرم‌افزار باشه. ( چون تو جدول‌های دیگه
    سطری براش تعریف نشده )

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

  21. #21
    کاربر دائمی
    تاریخ عضویت
    اسفند 1384
    محل زندگی
    تهران
    پست
    1,629

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    نقل قول نوشته شده توسط ghasem110deh مشاهده تاپیک
    پس این ریلیشن نسبتا خوبه ؟
    کیلویی نیست (چون خودم پیادش کردم میگم)
    .
    .
    .
    نمیخوام برم جلو (کد نویسی) باز مشکل دار شه ، برگردم از اول بانک طراحی کنم ... چون برنامه هم واسه خودمه !
    اصل کارم فاکتور و یه سری گزارش گیری معمولیه (فروش کل - فروش هر محصول و ...)
    سلام
    حداقل تو این مورد که صحیح هست و مشکلی نداره،
    این شکل ساخت جدول درست مشابه این هست که شما یک master class داشته باشی و بقیه کلاس‌ها ازش ارث می‌برن.
    گویا تو Code First به صورت رسمی می‌تونی دیتامدل رو این شکلی بسازی، ( من متاسفانه نمی‌تونم Code First استفاده کنم )

    صبا صبوحی

  22. #22
    کاربر دائمی آواتار ghasem110deh
    تاریخ عضویت
    اردیبهشت 1393
    محل زندگی
    تهران
    پست
    1,148

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

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

  23. #23
    کاربر دائمی
    تاریخ عضویت
    اسفند 1384
    محل زندگی
    تهران
    پست
    1,629

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    نقل قول نوشته شده توسط ghasem110deh مشاهده تاپیک
    جناب صبوحی حالا که قراره جداول کالا (که زیر جدول ، جدول کالا هستن) فیلد آیدی شون اتو آیدی نباشه ...
    میشه یه فیلد کد گذاشت که اون هم کلید اصلی باشه ؟
    (منظورم اینه که هر دوشون کلید اصلی باشن)
    سلام
    راستش متوجه منظورت نشدم، اما بر اساس حدس و گمان پاسخ می‌دم.
    هیچ مشکلی پیش نمیاد اگه کلید اصلی، کلید خارجی باشه، فقط مهمه که Unique و Not Null باشه.
    این جدول‌های زیر مجموعه، باید کلید اصلی‌اشون کلید خارجی به جدول والد باشه، و طبعاً Identity هم نباشه.
    بنابراین وقتی یک سطر به جدول اصلی اضافه می‌کنی، مقدار Identity رو با تابع IDENT_CURRENT می‌گیری و
    به عنوان کلید اصلی به جدول زیرین می‌دی. ( البته اگه از SqlCommand استفاده می‌کنی )

    هیچ نیازی به ستون اضافی در جدول زیرین نداری. همون ستون Id که کلید خارجی به Id در جدول والد هست
    رو به عنوان کلید اصلی تو این جدول معرفی کن.

    صبا صبوحی

  24. #24

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    سلام
    بنظر من با یک جدول میشه مشکل و حل کرد.Capture2.PNG
    تصویر اول جدول کالا و جدول خصوصیات است.
    تصویر دوم ترکیب این دو جدول در Query است
    عکس های ضمیمه عکس های ضمیمه

  25. #25

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

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

  26. #26
    کاربر دائمی آواتار ghasem110deh
    تاریخ عضویت
    اردیبهشت 1393
    محل زندگی
    تهران
    پست
    1,148

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    سلام به همه ...
    دوستان یکی در مورد این full text search تضیح میده (من توجیح نمی شم که مزیت هاش چیه)
    فقط سرعت جستجو رو میبره بالا ؟!

    http://ably.ir/post/Full-Text-Search

    ممنون :)

  27. #27

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    سلام
    من وقت نکردم کل تاپیک های ارسال شده رو بخونم شاید دوستان اشاره کرده باشن.


    برای حل مشکلتون می تونید از روش EAV استفاده کنید. Entity Attribute value. توی این روش یکسری خواص داخل یک جدول برای هر گروه کالا تعیین می کنید و بعدش توی یه جدول دیگه مقدار خاصیت اونها رو نگه می دارید. این روش توسط پایگاه دادهای بزرگی مثل magneto هم استفاده می شه. به غیر از این موارد به شما امکان تعریف مقدار دینامیک رو هم می ده که مشکلی هست که خیلی از نرم افزارهای توی بازار نداردن.

  28. #28
    کاربر دائمی آواتار ghasem110deh
    تاریخ عضویت
    اردیبهشت 1393
    محل زندگی
    تهران
    پست
    1,148

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    نقل قول نوشته شده توسط pswin.pooya مشاهده تاپیک
    سلام
    من وقت نکردم کل تاپیک های ارسال شده رو بخونم شاید دوستان اشاره کرده باشن.


    برای حل مشکلتون می تونید از روش EAV استفاده کنید. Entity Attribute value. توی این روش یکسری خواص داخل یک جدول برای هر گروه کالا تعیین می کنید و بعدش توی یه جدول دیگه مقدار خاصیت اونها رو نگه می دارید. این روش توسط پایگاه دادهای بزرگی مثل magneto هم استفاده می شه. به غیر از این موارد به شما امکان تعریف مقدار دینامیک رو هم می ده که مشکلی هست که خیلی از نرم افزارهای توی بازار نداردن.
    ممنون
    این نمونه ساده ای هستش :

    http://www.salimian.me/%D8%A8%D8%B1%...8C%D8%B1%D8%9F

    فقط یه سوال "واسه مشاهده مشخصات کامل کالا اگه یه view ایجاد کنیم سرعت توی جستجو پایین نمیاد ؟"
    بخاطر جداول زیاد (چون من چهار تا جدول دیگه هم دارم : انبار - قفسه - گروه - دسته کالا )
    آخرین ویرایش به وسیله ghasem110deh : جمعه 20 آذر 1394 در 12:56 عصر دلیل: اضافه کردن لینک

  29. #29

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    الزما افزودن جدول و ضرب جدولی به معنی کاهش سرعت نیست. من قبلا روی پایگاه داده یه شرکت برای حسابداری کار می کردم که حدود ۵۰۰ تا جدول داشت و تمام مشتری های اون از سرعت کارایی اون راضی بودن. حتی مشتری هایی داشت که نرم افزار همکاران سیستم رو کنار گذاشته بودن و از نرم افزار اون شرکت استفاده می کردن.

    برای حل مشکل سرعت روشهای خیلی زیادی وجود داره که یه قسمت از اون بر می گرده به طراحی درست پایگاه داده. البته زمانی که می گیم طراحی درست اصلا منظور من نرمالیزه کردن و ... نیست. بلکه روشها و trick هایی هست که برنامه نویسهای استفاده می کنن. یه مورد دیگه توی query گرفتن خیلی مهمه و متاسفانه SQL Server پشتیبانی نمی کنه دستور limit هست. (پایگاه داده هایی مثل اوراکل و یا MySQL ازش پشتیبانی می کنند.)

    و یه قسمت دیگر سرعت به کنترل درست برنامه بر می گرده. متاسفانه روشهای مطرح طراحی برنامه از جمله روش سه لایه و روش MVC نمی تونن گارانتی برای سرعت فراهم کنن. که برعکس با متدهایی که الان دارن پیاده سازی میشن یکی از بدترین کاراییها رو برای سرعت دارن.( اما از نظر انسجام خیلی خوب عمل می کنند) اما شما می تونید با یکسری ابتکارات کوچیک تا حد خیلی زیادی اونها رو بهبود بدید. مثلا من یادم میاد یه کلینیک رفتم که برای ثبت تزریق جدید اپراتور حدود ۲۰ تا ۳۰ ثانیه معطل شد. (افزودن یک رکورد به انتهای جدول) حالا یه همچین موردی رو میشه از طریق thread جداگانه و صف کار به چند میلی ثانیه کاهش داد. البته باید اضافه کنم که ریزه کاریهای همچین سیستم هایی خیلی زیاد هست و برای هماهنگی کامل مابین کلاینت ها باید کار بیشتری رو انجام بدین. من خودم از معماری ابداعی خودم استفاده می کنم که کارایی رو در سطح خیلی زیادی افزایش داده. این معماری از ترکیب چندین روش استفاده می کنه که متاسفانه چون توی طراحی برنامه های کاربردی گوله آخر من حساب میشه نمی تونم اون رو به اشتراک بزارم.

    فقط زمان طراحی مخصوصا وقتی کارایی براتون مهم هست باید از تمام ابزارهای موجود استفاده کنید. و باید یادتون باشه که برای کاربر نهایی هم، چیزی مهمتر از کارایی و انعطاف نیست. وگرنه امروزه بازار پر از نرم افزارهای حسابداری و ... با قابلیت های مختلف هست اما تقریبا همه اونها از نظر کارایی و موارد دیگه لنگ می زنن. مثلا از جمله موارد دیگه که میشه اشاره کرد اینه که خیلی از شرکتها بعد از تهیه برخی از نرم افزارهای معروف حسابداری مجبور هستن که سیستم هاشون رو ارتقا بدن من خودم شرکتی رو دیدم که یه نرم افزار حسابداری ۹ میلیونی خرید و بعد از اون مجبود شد حدود ۲۰ میلیون هم برای به روز رسانی سیستم هاش استفاده کنه. حال اونکه شرکتهایی رو می شناسم که نرم افزارشون راحت حتی با حافظه ۲۵۶ مگ هم کار می کنه. و نرم افزار حسابداریشون هم کمتر از نرم افزار اون شرکت معروف نیست.

  30. #30
    کاربر دائمی آواتار ghasem110deh
    تاریخ عضویت
    اردیبهشت 1393
    محل زندگی
    تهران
    پست
    1,148

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

    برخی از نرم افزارهای معروف حسابداری مجبور هستن که سیستم هاشون رو ارتقا بدن من خودم شرکتی رو دیدم که یه نرم افزار حسابداری ۹ میلیونی خرید و بعد از اون مجبود شد حدود ۲۰ میلیون هم برای به روز رسانی سیستم هاش استفاده کنه. حال اونکه شرکتهایی رو می شناسم که نرم افزارشون راحت حتی با حافظه ۲۵۶ مگ هم کار می کنه. و نرم افزار حسابداریشون هم کمتر از نرم افزار اون شرکت معروف نیست.
    این مورد مستقیم به دات نت که واسه برنامه انتخاب میکنیم ربط داره ؟
    و چه چیزای دیگه ای ؟

    متاسفانه روشهای مطرح طراحی برنامه از جمله روش سه لایه و روش MVC نمی تونن گارانتی برای سرعت فراهم کنن. که برعکس با متدهایی که الان دارن پیاده سازی میشن یکی از بدترین کاراییها رو برای سرعت دارن.
    من کلی حال میکردم که با سه لایه مینویسم
    و در مورد لود اطلاعات تو برنامه هم (روش درست که سرعت پایین نیاد) مشکل دارم ... الان رو سیستم خودم که نسبتا قدیمی ، برای بار اول که یه فرم باز میشه ، حدودا 2 تا 3 ثانیه طول میکشه
    البته از یه فرم نمایشی هم واسه تاریک کردن پشت فرم استفاده میکنم که اونم خودش یه زمانی رو طلف میکنه که به 4 و 5 ثانیه میرسه !

    خیلی هم سعی کردم (یعنی دارم جستجو و تحقیق میکنم) که برسم به سطح کد نویسی تجاری و بالاتر از این چیزی که الان هستم ولی همش میخوره به دیوار (دلیل اصلیش هم زبان ضعیفم هست)

  31. #31

    نقل قول: مشکل در طراحی اصولی یک دیتابیس ساده

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

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

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

    و در مورد لود اطلاعات تو برنامه هم (روش درست که سرعت پایین نیاد) مشکل دارم ... الان رو سیستم خودم که نسبتا قدیمی ، برای بار اول که یه فرم باز میشه ، حدودا 2 تا 3 ثانیه طول میکشه
    تجربه همچین موردی رو داشتم. توی موارد زیادی سرعت کند لود شدن فرم ها خیلی روی کارایی تاثیر بعد میزاره. مثلا یه صرافی رو در نظر بگیرید که مرتبا باید تراکنش های مختلف انجام بده و همین لود شدن ۲ ثانیه ای فرم هم براش مهم هست. یه راه میانبر اینه که اطلاعات صفحه یا فرمی که باید دوباره بارگذاری بشه رو پاک کنید. بدون اینکه فرم جدید باز کنید.

    نکته دیگه اینه که توی دات نت باید از افکتهای گرافیکی جلوگیری کنید. افکتهای گرافیکی برای جند روز کاربرهاتون رو سرگرم می کنه اما بعد از چند روز دیگه مفید نیست و فقط آزار دهنده است. مخصوصا اگر ۵ ثانیه طول بکشه که خیلی زیاد است.
    آخرین ویرایش به وسیله pswin.pooya : جمعه 20 آذر 1394 در 17:40 عصر

تاپیک های مشابه

  1. مشکل در طراحی تاریخ در دیتابیس
    نوشته شده توسط amirshahmoradi در بخش تحلیل و طراحی بانک اطلاعات
    پاسخ: 1
    آخرین پست: شنبه 18 مرداد 1393, 04:28 صبح
  2. مشکل در طراحی ساختار دیتابیس و نمایش اطلاعات در ASP
    نوشته شده توسط reghbali06 در بخش ASP.NET Web Forms
    پاسخ: 3
    آخرین پست: جمعه 24 تیر 1390, 18:54 عصر
  3. پاسخ: 0
    آخرین پست: جمعه 16 اردیبهشت 1390, 13:07 عصر
  4. مشکل در طراحی دیتابیس
    نوشته شده توسط DataMaster در بخش SQL Server
    پاسخ: 5
    آخرین پست: دوشنبه 15 مرداد 1386, 07:54 صبح
  5. مشکل در طراحی دیتابیس
    نوشته شده توسط na3er-faraji در بخش برنامه نویسی در 6 VB
    پاسخ: 2
    آخرین پست: جمعه 18 خرداد 1386, 13:17 عصر

قوانین ایجاد تاپیک در تالار

  • شما نمی توانید تاپیک جدید ایجاد کنید
  • شما نمی توانید به تاپیک ها پاسخ دهید
  • شما نمی توانید ضمیمه ارسال کنید
  • شما نمی توانید پاسخ هایتان را ویرایش کنید
  •