آیا استفاده از یک جدول بزرگ به جای چند جدول صحیح است؟ [بایگانی]

mehdi_naghdi

یک شنبه 29 اردیبهشت 1392, 10:54 صبح

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

مهدی هادیان2

یک شنبه 29 اردیبهشت 1392, 14:04 عصر

بسم الله الرحمن الرحیم
با سلام
فیلدهایی که مربوط به یک جدول است و از نظر منطقی یک Entity به حساب میایند؛ بنده ندیدم به چند جدول بشکنند.
موفق باشید.

benyaminrahimi

یک شنبه 29 اردیبهشت 1392, 20:54 عصر

همون یه جدول درسته شما با سلکت در زمان نیاز میتونی چند فیلدو داشته باشی

mehdi_naghdi

دوشنبه 30 اردیبهشت 1392, 09:27 صبح

با توجه به اینکه تعداد فیلدهای جدول زیاد است و همچنین تعداد رکوردهایی که در این جدول ثبت می شود نسبتاً زیاد است، تراکنش روی این جدول کند نمی شود؟

rasoul_par

دوشنبه 30 اردیبهشت 1392, 09:35 صبح

بستگی داره که آیا تمام فیلدها باید پر بشن یا نه، اگر بعضی فیلدها هستن که ممکنه پر نشن یا به نحوی تعداد Null ها رو زیاد کنن بهتر یک جدول دیگه بسازی به نظر من!

mehdi_naghdi

دوشنبه 30 اردیبهشت 1392, 09:49 صبح

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

حمیدرضاصادقیان

دوشنبه 30 اردیبهشت 1392, 22:18 عصر

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

mehdi_naghdi

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

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

مهدی هادیان2

سه شنبه 31 اردیبهشت 1392, 15:19 عصر

بسم الله الرحمن الرحیم

پیشنهاد میشه حتی المقدور جدول ها تعداد فیلدهای کمتری داشته باشند تا تعداد Page های کمتری مصرف بشه و در نتیجه میزان I/O کاهش پیدا کنه و در نهایت باعث افزایش سرعت شما بشه.
با سلام
برنامه ای که تحلیل می کنم بدین صورت است که هم داوطلبان موسسه و هم اعضای عادی می توانند از آنجا خرید داشته باشند. که اطلاعاتی که در مورد داوطلب و اعضای عادی ثبت می شود متفاوت است. پس برای هر کدام باید جداولی جداگانه در نظر بگیرم.
سوال از اینجا شروع می شود؛
2 نوع نگاه می توان به این مسئله داشت. یا 2تا جدول فروش داشته باشیم؛ یکی برای داوطلب و دیگری برای اعضای عادی.
و یا می توان 1جدول داشت و هم کلید خارجی جدول داوطلب و هم اعضای عادی در ان وجود داشته باشد و اگر داوطلب خرید داشت کلید داوطلب پر شود و کلید عضو عادی نال باشد. و بالعکس
به نظر شما کدام اصولی تر است؟
با تشکرhttp://forum.p30world.com/images/New-smile/N_aggressive%20%2817%29.gif

rasoul_par

چهارشنبه 01 خرداد 1392, 02:18 صبح

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

مهدی هادیان2

پنج شنبه 02 خرداد 1392, 08:09 صبح

بسم الله الرحمن الرحیم

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

rasoul_par

پنج شنبه 02 خرداد 1392, 10:15 صبح

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

Sell(CustomerID, Date, MutualField1, MutualField1, ...)
Volunteer_Sell(VolPk, VolField1, ...)
NotMember_Sell(NotMemberPK, NotMemberField1, ...)

که توی این مثال CustomerID میتونه هم VolPk باشه هم NotMemberPK.
امیدوارم درست فهمیده باشم مساله رو!

مهدی هادیان2

شنبه 04 خرداد 1392, 09:35 صبح

بسم الله الرحمن الرحیم
با سلام
نمیدونم؛ تردید بنده تا الان بین این بود که یک جدول استفاده کنم یا دو تا؟
به 3 تا جدول فکر نکرده بودم!
بنده شنیده بودم اگر جدول ها بزرگتر باشد بهتر است از اینکه تعداد جدول ها بیشتر باشد. و در صورت صحت این مطلب عمل درج و ویرایش و ... برای یک جدول راحت تر از 2 جدول است و برخی از اضافه کاری ها رو ندارد.
از طرفی آقای صادقیان در صحبت هاشون فرمودند:
پیشنهاد میشه حتی المقدور جدول ها تعداد فیلدهای کمتری داشته باشند تا تعداد Page های کمتری مصرف بشه و در نتیجه میزان I/O کاهش پیدا کنه و در نهایت باعث افزایش سرعت شما بشه. .
به نظر دوستان کدوم نظر صحیح است؟
با سپاس فراوان

rasoul_par

یک شنبه 05 خرداد 1392, 15:34 عصر

هیچکس قطعا نمیتونه بگه کدوم صحیحه، باید با توجه به شرایط مساله، حجم داده ها در آینده و ... تصمیم بگیری!

حمیدرضاصادقیان

دوشنبه 06 خرداد 1392, 08:58 صبح

قطعا موردی که عرض کردم صحیحتره با توجه به گفته بزرگان طراحی Database .برای مثال میتونید به کتاب Inside T-SQL Querying نوشته Itzik Ben Gan فصل 4 مراجعه کنید.
ولی این وسط استثنائاتی نیز بوجود خواهد آمد که صورت مسئله و حلش رو تغییر میده.

مهدی هادیان2

دوشنبه 06 خرداد 1392, 14:59 عصر

بسم الله الرحمن الرحیم

قطعا موردی که عرض کردم صحیحتره با توجه به گفته بزرگان طراحی Database .برای مثال میتونید به کتاب Inside T-SQL Querying نوشته Itzik Ben Gan فصل 4 مراجعه کنید.
ولی این وسط استثنائاتی نیز بوجود خواهد آمد که صورت مسئله و حلش رو تغییر میده.
با سلام
با مشخصاتی که فرمودید چند تا کتاب پیدا کردم؛ لطفا بفرمائید کدوم مورد نظر شماست؟
http://bookos.org/s/?q=Itzik+Ben-Gan+Inside+T-SQL+Querying&e=1&t=0
با سپاس فراوان

programer97

سه شنبه 07 خرداد 1392, 14:32 عصر

بستگی داره که آیا تمام فیلدها باید پر بشن یا نه، اگر بعضی فیلدها هستن که ممکنه پر نشن یا به نحوی تعداد Null ها رو زیاد کنن بهتر یک جدول دیگه بسازی به نظر من!

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

programer97

سه شنبه 07 خرداد 1392, 14:41 عصر

بسم الله الرحمن الرحیم
سوال از اینجا شروع می شود؛
2 نوع نگاه می توان به این مسئله داشت. یا 2تا جدول فروش داشته باشیم؛ یکی برای داوطلب و دیگری برای اعضای عادی.
و یا می توان 1جدول داشت و هم کلید خارجی جدول داوطلب و هم اعضای عادی در ان وجود داشته باشد و اگر داوطلب خرید داشت کلید داوطلب پر شود و کلید عضو عادی نال باشد. و بالعکس
به نظر شما کدام اصولی تر است؟
با تشکرhttp://forum.p30world.com/images/New-smile/N_aggressive%20%2817%29.gif

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

programer97

سه شنبه 07 خرداد 1392, 14:51 عصر

بسم الله الرحمن الرحیم
با سلام
به نظر دوستان کدوم نظر صحیح است؟
با سپاس فراوان

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

مهدی هادیان2

دوشنبه 13 خرداد 1392, 14:35 عصر

بسم الله الرحمن الرحیم

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