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

IMANAZADI

دوشنبه 07 اردیبهشت 1394, 16:13 عصر

با سلام

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

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

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

Davidd

دوشنبه 07 اردیبهشت 1394, 17:24 عصر

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

IMANAZADI

دوشنبه 07 اردیبهشت 1394, 20:08 عصر

SabaSabouhi

سه شنبه 08 اردیبهشت 1394, 06:36 صبح

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

سلام
دو تا مطلب:

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

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

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

صبا صبوحی

IMANAZADI

سه شنبه 08 اردیبهشت 1394, 07:59 صبح

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

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

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

میشه بیشتر توضیح بدید یا اگر براتون ممکن است یک دیاگرام sample واسم بزارید (تو برنامه paint بکشید کفایت میکنه)

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

IMANAZADI

سه شنبه 08 اردیبهشت 1394, 09:40 صبح

:افسرده::افسرده: :گریه: چی شد دوستان

Davidd

سه شنبه 08 اردیبهشت 1394, 10:47 صبح

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

IMANAZADI

سه شنبه 08 اردیبهشت 1394, 10:50 صبح

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

Davidd

سه شنبه 08 اردیبهشت 1394, 10:56 صبح

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

IMANAZADI

سه شنبه 08 اردیبهشت 1394, 11:28 صبح

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

Davidd

سه شنبه 08 اردیبهشت 1394, 11:35 صبح

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

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

SabaSabouhi

سه شنبه 08 اردیبهشت 1394, 12:29 عصر

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

سلام
من دو سه ساعت نیودم، چقدر پست رد و بدل شد :متعجب:

نوشته‌های دوستمون 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 رو ترجیح می‌دم.

صبا صبوحی

IMANAZADI

سه شنبه 08 اردیبهشت 1394, 13:03 عصر

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

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

IMANAZADI

سه شنبه 08 اردیبهشت 1394, 13:17 عصر

سلام
من دو سه ساعت نیودم، چقدر پست رد و بدل شد :متعجب:

نوشته‌های دوستمون 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 رو ترجیح می‌دم.

صبا صبوحی

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

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

Davidd

سه شنبه 08 اردیبهشت 1394, 13:33 عصر

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

ghasem110deh

یک شنبه 31 خرداد 1394, 19:22 عصر

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

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

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

SabaSabouhi

دوشنبه 01 تیر 1394, 10:08 صبح

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

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

سلام
دقیقاً به همین دلیل هست که من پیش‌نهاد می‌کنم وقتی پروژه‌ای می‌گیری با یک طراح
دیتامدل همکاری کنی. نباید نگران هزینه‌ی این کار باشی، چون در پایان کار این همکاری به نفعت می‌شه.

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

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

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

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

صبا صبوحی

ghasem110deh

دوشنبه 01 تیر 1394, 12:42 عصر

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

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

SabaSabouhi

دوشنبه 01 تیر 1394, 18:43 عصر

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

صبا صبوحی

ghasem110deh

دوشنبه 01 تیر 1394, 19:28 عصر

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

صبا صبوحی

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

SabaSabouhi

سه شنبه 02 تیر 1394, 09:32 صبح

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

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

صبا صبوحی

ghasem110deh

پنج شنبه 04 تیر 1394, 18:28 عصر

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

SabaSabouhi

شنبه 06 تیر 1394, 10:04 صبح

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

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

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

صبا صبوحی

mprogram

دوشنبه 09 آذر 1394, 10:35 صبح

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

reza_ali202000

دوشنبه 09 آذر 1394, 13:09 عصر

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

ghasem110deh

سه شنبه 17 آذر 1394, 17:59 عصر

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

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

ممنون :)

pswin.pooya

جمعه 20 آذر 1394, 01:37 صبح

ghasem110deh

جمعه 20 آذر 1394, 12:55 عصر

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

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

ممنون
این نمونه ساده ای هستش :

http://www.salimian.me/%D8%A8%D8%B1%D8%B3%DB%8C-%DB%8C%DA%A9-%D9%85%D8%B4%DA%A9%D9%84-%D8%AF%D8%B1-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%AF%DB%8C%D8%AA%D8%A7%D8%A8%DB%8C%D8%B3%D8%8C%D A%86%D9%86%D8%AF-%D9%85%D8%AD%D8%B5%D9%88%D9%84-%D8%A8%D8%A7-%D9%88%DB%8C%DA%98%DA%AF%DB%8C-%D9%87%D8%A7%DB%8C-%D9%85%D8%AA%D8%BA%DB%8C%DB%8C%D8%B1%D8%9F

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

pswin.pooya

جمعه 20 آذر 1394, 15:38 عصر

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

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

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

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

ghasem110deh

جمعه 20 آذر 1394, 16:34 عصر

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

این مورد مستقیم به دات نت که واسه برنامه انتخاب میکنیم ربط داره ؟
و چه چیزای دیگه ای ؟

متاسفانه روشهای مطرح طراحی برنامه از جمله روش سه لایه و روش MVC نمی تونن گارانتی برای سرعت فراهم کنن. که برعکس با متدهایی که الان دارن پیاده سازی میشن یکی از بدترین کاراییها رو برای سرعت دارن.

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

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

pswin.pooya

جمعه 20 آذر 1394, 16:53 عصر

این مورد مستقیم به دات نت که واسه برنامه انتخاب میکنیم ربط داره ؟
و چه چیزای دیگه ای ؟

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

من کلی حال میکردم که با سه لایه مینویسم :قهقهه:

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

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

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

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

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