سوال: یک فرم با کلی داده (ComboBox هایی با داده های متفاوت) [بایگانی]

hojjatshariffam

سه شنبه 01 مرداد 1392, 00:00 صبح

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

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

حالا پیشنهاد شما چیه ؟
از کدوم روش استفاده کنم بهتره
و یا اینکه روش دیگه ای (و بهینه تری) پیشنهاد می کنید؟

shadi khanum

سه شنبه 01 مرداد 1392, 08:10 صبح

بهترین راه به نظ من(کاری که خودم تو پروژه هام میکنم و کاملا کارم رو راه انداخته و پشتیبانی کار راحت تره) راه سومتونه، یعنی برای اطلاعات هر کمبو یه جدول داشته باشی که مثلا یه آیدی داره و یه Value . حالا id همه این جداول رو بیار تو جدول اون موجودیتت. یعنی این جداول کمبوها بالای جدول موجودیتت باشن

hojjatshariffam

سه شنبه 01 مرداد 1392, 12:33 عصر

بهترین راه به نظ من(کاری که خودم تو پروژه هام میکنم و کاملا کارم رو راه انداخته و پشتیبانی کار راحت تره) راه سومتونه، یعنی برای اطلاعات هر کمبو یه جدول داشته باشی که مثلا یه آیدی داره و یه Value . حالا id همه این جداول رو بیار تو جدول اون موجودیتت. یعنی این جداول کمبوها بالای جدول موجودیتت باشن
حب اون موقع سرعت رو چی کار کنم ، سلکت هام به شدت سرعتش میاد پایین و هزینه بر می شده چون مثلا در یک ویو باید سی جدول رو با هم جوین کنم ، حالا فکر کنید که هر کدوم از جداول 100 تا ردیف و جدول اصلی 10000 تا ردیف داشته باشه
موقع لود یه نمایش کاربر این زمان رو متوجه خواهد شد و اذیت کننده خواهد بود.

hojjatshariffam

سه شنبه 01 مرداد 1392, 16:25 عصر

کسی نظری نداره؟

hojjatshariffam

سه شنبه 01 مرداد 1392, 18:14 عصر

به نظرتون همه دیتا ها رو بریزم تو یه جدول و جدول اصلی رو با جدول دوم به تعداد کامبو ها جوین کنم (روش اولو دوم)بهتره
یا اینکه به تعداد کامبو هام جدول داشته باشم و جدول اوم رو با همشون جوین کنم (روش سوم)

hojjatshariffam

سه شنبه 01 مرداد 1392, 23:05 عصر

من می خوام این جداولو پیاده سازی کنم ، کسی نظری نداره ، چون بعد پیاده سازی و کد نویسی عوض کردنش سخته ، من می خوام بهترین روش رو پیاده سازی کنم

khokhan

سه شنبه 01 مرداد 1392, 23:14 عصر

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

hojjatshariffam

چهارشنبه 02 مرداد 1392, 00:03 صبح

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

hojjatshariffam

چهارشنبه 02 مرداد 1392, 13:00 عصر

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

hojjatshariffam

چهارشنبه 02 مرداد 1392, 22:35 عصر

یعنی هیچ کس نمی تونه هیچ کمکی بکنه؟
هیچ کس تا حالا با همچین پیاده سازی مواجه نشده؟

hojjatshariffam

پنج شنبه 03 مرداد 1392, 03:50 صبح

یعنی تو این فروم هیچ کس تا حالا با همچین فرم و داده هایی کار نکرده
یعنی اینقدر عجیب و دور از ذهنه؟

hojjatshariffam

پنج شنبه 03 مرداد 1392, 14:28 عصر

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

hojjatshariffam

جمعه 04 مرداد 1392, 13:57 عصر

کسی نیست مارو یه رانمائی کنه؟

hojjatshariffam

جمعه 04 مرداد 1392, 16:22 عصر

دارم نا امید میشم
کسی نیست بدونه قضیه چیه ؟ یا کسی نمی خواد کمک کنه؟

veniz2008

جمعه 04 مرداد 1392, 21:07 عصر

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

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

hojjatshariffam

جمعه 04 مرداد 1392, 22:13 عصر

سلام.
روش اول که برخلاف اصول طراحی دیتابیس ها هست. هر جدول باید توصیف کننده یک موجودیت یا یک رابطه باشه، قرار دادن فیلدهای متفاوت که هر کدومشون یک مفهوم جدا هستند اشتباه هست. کما اینکه مقادیر این فیلدها در این جدول بصورت همزمان پر نمیشه. این میتونه یک معیار برای تشخیص جداول باشه، معمولا عباراتی که در طی چند مرحله گرفته میشن، در جداول جداگانه ذخیره میشن.
روش دوم رو متوجه نشدم.
روش سوم همونطور که دوستمون هم گفتن روش استاندارد هست. منم همین روش رو پیشنهاد میکنم. البته این حرف شما هم درسته که هزینه join بین 30 جدول بسیار بالا هست. من تا حالا به چنین حالتی برنخوردم که نیاز بوده باشه این همه join وجود داشته باشه. بهتره در تحلیل و طراحی خودتون یه بار دیگه از نو، فکر کنید. شاید تحلیل درستی نکرده باشید. چون 30 تا join اصلا مقرون به صرفه نیست ولی روش ، روش استانداردی هست.
روش چهارم هم که خودتون گفتید اصلا بهینه نیست. ما خود مقادیر رو ذخیره نمی کنیم، ارزش هر مقدار (همون کلید) رو ذخیره می کنیم.
منظورم از روش دوم این بود که یه فیلددیگه برای گروه بندی داده های همون جدول داشته باشم خب اونم با این تفاصیر که هر جدول برای یک موجودیت باید بکار رود ، رد می شود
پس باید از روش یک جدول برای هر کامبو باکس استفاده کنم
که اون موقع هم تعداد جدولام میره بالا
تازه یکم رو طراحی هم فکر کردم دیدم اگه یه ذره بیشتر دقت کنم میشه همه اونا یه موجودیت بشن ولی باید گروه بندی بشوند و اون هم میشه باز روش دوم ، ولی چی کار کنم که همه اینها باید برای موجودیت اصلی ثبت شود
بزارید یک مثال بزنم (فقط یه مثال برای درک موضوع ، کاربرد خودم این نیست)
شما فکر کنید که برای یک شخص باید 30 تا خصوصیت ثبت کنی ، مثل اسم ، فامیل ، نام پدر ، شهر ، شماره شناسنامه
بعد باید بدونی که برای هر کدام از این خصوصیات مقادری محدودی انتخاب داری مثل برای اسم باید از بین 20 اسم یکی و انتخاب کنی ، برای فامیل باید از بین 40 تا فامیل یکی و انتخاب کنی ، برای نام پدر باید از بین 30 تا اسم یکی رو انتخاب کنی ، برای شهر باید از بین 200 تا شهر یکی و انتخاب کنی
یکم ناملموسه ولی خواستم موضوع بهتر جا بیافته
حال برای لیست اسم کوچک یک کامبو باکس برای انتخاب و بطبع یک جدول تو دیتا بیس
برای لیست فامیل های مجاز یک جدول ، برای نام پدر ها یک جدول ، برای شهر ها یک جدول و ....
خب پیاده سازی این ها درست
ولی وقتی که قراره یک ویو درست کنیم و یک شخص رو نشون بدیم که اسمش چیه ، فامیلش چیه ، شهرش چیه و .... باید جدول شخص رو با همه اونا جوین کنیم
بازم میگم من اینا رو بای اسم و فامیل نیم خوام ، چون غیر اصولیه ، برای کاربرد دیگست.این فقط یک مثال بود
حالا روش شما چیه برای چنین داده هایی؟

veniz2008

جمعه 04 مرداد 1392, 23:57 عصر

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

hojjatshariffam

شنبه 05 مرداد 1392, 01:26 صبح

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

hojjatshariffam

شنبه 05 مرداد 1392, 01:52 صبح

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

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

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

Mahmoud.Afrad

شنبه 05 مرداد 1392, 03:59 صبح

در مورد جداول بهتره یک جدول برای گروه یک جدول برای اعضای گروه و یک جدول هم برای دیتا داشته باشی. در اینصورت نهایتا دو بار join لازم داری. یعنی حالت دوم.

باز هم اگر مشکلی داشتی بهتره یک نمونه از اطلاعات واقعی که قراره ثبت بشه رو بزاری.

در مورد ثبت در جداول اصلی و فرعی هم که فرقی نمیکنه. طبق اصول عمل کنید. یعنی روش اول. هر جدول یک کلیداصلی و در صورت نیاز استفاده از کلید خارجی. در مورد جامعیت هم میتونید آپدیت رو خودتون کنترل کنید و یا Update Rule را روی Cascade قرار بدید تا در صورت تغییر کلیداصلی ، کلیدخارجی متناظرش هم تغییر کنه. برای Delete هم باید یک ستون درنظر بگیرید تا اطلاعاتی از سیستم جذف نشه بلکه سطر را غیرفعال کنید.

veniz2008

شنبه 05 مرداد 1392, 04:37 صبح

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

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

در روش اول باید کلید تک فیلدی اصلی باید عددی باشد که هی بزرگتر می شود ، ولی در روش دوم این عدد به اضای هر کد بالاتر بزرگتر می شود
در روش اول آخرین سطح از این درخت (حساب جزء) را می توان به هر زیر شاخه ای منتقل کرد (فقط با تغییر یک کد تفضیلی) سطوح میانی از درخت رو هم یا تغییر یک کد میشه به برگ های دیگر منتل کرد و بقیه زیر شاخه ها هم منتقل می شوند ، ولی در روش دوم باید همه کد های کلید اصلی رو تک تک عوض کنیم سطوح میانی هم قابل انتقال نیستند .
در روش دوم یه جور افزونگی هم ایجاد میشه در عوض یک جور انسجام هم وجود دارد
(مهمترین مزیتی که در روش دوم می بینم در این مورد است)در استفاده از روش اول اگر قرار باشد که مثلا یک سند داشته باشیم که هم در آن کد کل هم در آن کد معین ، هم کد تفضیلی و هم کد جزء ثبت شود (با توجه به اینکه ممکن است یک معینی اصلا تفضیلی نداشته باشد و یا یک تفضیلی اصلا جزء نداشته باشد) با نرم افزار چک می کنیم که کد ها بصورت سلسه مراتبی و صحیح ثبت شوند ، ولی یک نفر بیاید و از دیتا بیس مثلا کد تفضیلی یک سند را عوض کند ، در حالی که کد تفضیلی وارد شده مربوط به آن کد معین نباشد و زیر شاخه کد دیگری باشد ، دیتا بیس هیچ خطایی نمی دهد ولی در روش دوم حتما خطا خواهد داد ، یعنی دیتابیس خودش کنترل می کند که سلسله مراتب رعایت شود. چون که در روش اول در جدول سند چهار فیلد داریم که تک تک به جدول های کل ،معین ، تفضیلی و جزء در ارتباط است
در روش دوم ، اینجاشم برام گنگه که آیا مثلا در جدول سوم (حساب تفضیلی) غیر ارتباط دو فیلده کلید اصلی با جدول حساب معین ، نیاز هست که فیلد اول با جدول حساب کل هم ارتباط داشته باشد یا نه؟
آیا روش اول بهتر است یا روش دوم ، مزایا و معایبشان چیست؟
همونطور که دوستمون هم گفتن روش اول روش مناسب هست.
چند دلیل برای این کار وجود داره :
1. در زمان درج رکورد، خود اس کیو ال بصورت اتوماتیک و بدور از چشم شما، روی فیلد کلید یک کلاستر ایندکس (مرتب سازی فیزیکی رکوردها) رو قرار میده. این ایندکس گذاری تاثیر بسزایی رو در هنگام جستجوی یک رکورد بر اساس اون فیلد داره. اگر شما یک کلید ترکیبی ( ابر کلید) رو برای جدول در نظر بگیرید، اونوقت اس کیو ال باید زمان بیشتری رو صرف مرتب سازی رکوردها کنه. توجه داشته باشید زمانیکه یک رکورد حذف یا درج یا مقدار کلید یک رکورد ویرایش میشه این مرتب سازی فیزیکی رکوردها ممکنه خیلی زمان بر باشه(با توجه به تعداد رکوردها و کلیدی که حذف یا درج یا که ویرایش میشه). به همین خاطر هست که توصیه میکنن کلاستر ایندکس رو بر روی 4 یا بیشتر از 4 فیلد قرار ندیم.
2. در زمان جستجو (یا آپدیت یا حذف)، برای جدولی مثل جدول چهارم، شما باید در شرط کوئری، همزمان چهار فیلد رو AND کنید تا بتونید یک رکورد خاص رو پیدا کنید ولی اگر تک فیلدی باشه، دیگه این مشکلات رو ندارید.
فقط اگر کلید تک صفتی داشتید،مثلا برای جدول حساب معین دو فیلد کد کل و کد معین رو یونیک کنید. یونیک کردن این دو فیلد باعث میشه تا رکورد تکراری ثبت نشه (یونیک رفتاری شبیه به کلید رو برای این دو فیلد پیاده سازی میکنه) یا مثلا برای جدول حساب تفضیلی سه فیلد کد کل ، کد معین و کد تفضیلی رو یونیک قرار میدید. بصورت ساده بگم : اون فیلدهایی که قرار بود نقش کلید ترکیبی رو بازی کنن، بعنوان یونیک قرار میدید تا اجازه درج تکراری رو نداشته باشه.
کلیدهای خارجی هم که کاملا مشخصه برای این روش به چه صورت خواهد بود.

hojjatshariffam

شنبه 05 مرداد 1392, 05:26 صبح

در مورد جداول بهتره یک جدول برای گروه یک جدول برای اعضای گروه و یک جدول هم برای دیتا داشته باشی. در اینصورت نهایتا دو بار join لازم داری. یعنی حالت دوم.

باز هم اگر مشکلی داشتی بهتره یک نمونه از اطلاعات واقعی که قراره ثبت بشه رو بزاری.

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

Mahmoud.Afrad

شنبه 05 مرداد 1392, 13:44 عصر

30 ضرب در 3 جوین از کجا میاد؟ کدوم 30 جدول؟ یک مثال از دیتاهای کمبوباکس ها و کلا یه نمونه اطلاعاتی از این 30 تا جدولی که هی داری میگی مثال بزن.

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

hojjatshariffam

شنبه 05 مرداد 1392, 14:29 عصر

30 ضرب در 3 جوین از کجا میاد؟ کدوم 30 جدول؟ یک مثال از دیتاهای کمبوباکس ها و کلا یه نمونه اطلاعاتی از این 30 تا جدولی که هی داری میگی مثال بزن.

اگر منظورت اینه که برای هر سطری یک جوین بزنی که دید اشتباهی هستش یا حتی برای هر کمبو هم نیاز به سلکت جداگانه نیست چون دیتاهای این کمبوباکس ها در یک جدول هست
پس همه اطلاعات همه کمبوباکس ها رو یکدفعه سلکت جوین(نهایتا 2 تا جوین) میکنی میریزی توی یک دیتاتیبل. حالا برای هر کمبوباکس یک DataView میسازی و وصلش میکنی به دیتاتیبل. حالا برای هر DataView یک فیلتر مناسب قرار میدی متناسب گروهی که در هر کمبوباکس باید باشه. دیتاویوها رو وصل میکنی به کمبوباکس ها.
بله درسته پست قبلی رو یکم گنگ فرستادم ، خودمم نفهمیدم چی نوشتم ، اون دید در صورتی بود که اطلاعات هر کامبودر جدول جداگانه ای باشد ، در روش پیشنهادی شما که تو دیاگرام هم مشهوده ، لیست گروه ها در جدول physicalExam مقادیر همه چک باکس ها در جدول های sign , Symptom (چون دو نوع موجودویت متفاوته) قرار دارد ، اطلاعات ثبتی هم در جدول PersonnelExam و مقادیر چک باکس ها (درج ردیف به منظله چک کرد چک باکسه) در جدول های PersonnelSign و PersonnelSuymptom درج میشه برای اینکه بفهمیم در هر گروهی از ردیف های جدول PersonnelExam روی چه گزینه هایی تیک خوره باید جدول PersonnelExam و physicalExam و sign وSymptom و PersonnelSuymptom و PersonnelSign باهم جوین شود یک جوین هم باید به جدول PersonnelExamTerm و Person_Table برای نمایش مشخصات شناسنامه ای شخص با کل جدواول قبلی انجام شود
اینها جداول فقط یک فرم سیستم بود یعنی اطلاعات از هفت جدول واکشی شد ، یعنی هفت تا جوین
اطلاعات جداول رو هم توضیح میدم که یکم واضح تر بشه
Person_Table : جدول مشخصات شناسنامه ای
PersonnelExamTerm : جدول انجام آزمایشات
وphysicalExam : نوع آزمایشات (گزوه آزمایشات)
Symptom : علائم (زیر گروه اول آزمایشات یا همون علائم هر گروه آزمایشات)
sign : نشانه ها (زیر گروه دوم آزمایشات یا همون نشانه هر گروه آزمایشات)
PersonnelExam : آزمایشات ثبت شده برای شخص در جدول ازمایشات
PersonnelSuymptom : علائمی که در آزمایشات ثبت شده تیک زده شده است
PersonnelSign : نشانه هایی که در آزمایشات ثبت شده تیک زده شده است

این دیاگرام فقط قسمتی از داده های سیستم هست.
حالا نظرتون چیه

hojjatshariffam

شنبه 05 مرداد 1392, 15:05 عصر

اینم یه تصویر از فرم
شماره 5 یعنی معاینات در جدول PersonnelExamTerm
برسی ارگانها در physicalExam
علائم در Symptom نشانه ها درsign
علائم تیک خورده در PersonnelSuymptom
نشانه های تیک خورده در PersonnelSign
و ردیف های هر آزمایش (شامل عمومی چشم و ... ) دز PersonnelExam
108006
حالا شماره های دیگر (5- معاینات)طراحی و جداول مجزا دارند چون ماهیتشون فرق می کنه

hojjatshariffam

شنبه 05 مرداد 1392, 17:56 عصر

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

من تیک ها رو بردم در جدول Sign و Symptom که اگر در جدول های معادل داده اینها ، اگر ردیفی ثبت شد یعنی تیک خورده و اگر ردیفی به ازای همون علامت و شخص مورد نظر و آزمایش مورد نظر ثبت نشده باشد ،پس تیک نخورده است
حالا هم گزینه ها قابل افزایش هستند ، هم افزونگی نداریم و هم فلکسبل می باشد
ولی بنظرم به گفته veniz2008 (http://barnamenevis.org/member.php?155296-veniz2008) کلید های اصلی من فعلا تا 4 فیلد پیش رفته است (بیشتر از این هم نیاز ندارم )، ولی آیا این روش هیچ مزیتی ندارد؟

hojjatshariffam

دوشنبه 07 مرداد 1392, 16:23 عصر

کسی ایده و نظری در رابطه با توضیحاتی که دادم نداره؟

hojjatshariffam

سه شنبه 29 مرداد 1392, 15:18 عصر

اینم هم فرم نهائی من در مورد این قسمت از برنامه بعد از کلی چالش ها
109390
در این فرم از پنج کامپوننت که همه در یک کامپوننت تجمیع و یک کامپوننت رو تشکیل داده اند و بصورت ردیفی در FlowLayoutPanel لیست شده اند استفاده شده است

neron1509

یک شنبه 30 فروردین 1394, 19:46 عصر

سلام به همه
من یه فرم دارم که یه کمبو باکس روش هست و که به یکی از جدول های دیتا بیس متصلش کردم حالا می خوام وقتی اطلاعات رو ذخیره می کنم اطلاعاتش بره داخل یدونه ویو که اونم دخل فرم قرار دادم و می خواستم بدونم چطوری و با چه دستوری می شه این کار رو انجام داد که مثلا وقتی روی کمبو باکس کلیک می کنم اطلاعات دیگه کمبو باکسم مثل id و price بره داخل جداول دیگه که با هم ارتباط دارن ذخیره بشه و توی ویو هم نمایش داده بشه ممنونم