طول رکورد

[morika]

سلام
تو برنامه من وقتی یه فرم پر میشه باید تو بانک ذخیره بشه. حالا این فرم حدودا 44 تا آیتم داره که همش باید ثبت بشه. می خواستم بپرسم که بهتره تمام این 44 تا آیتم کنار هم تو یک Table ذخیره بشه یا اونارو بشکنیم و مثلا تو 2 تا table که هرکدوم 22 تا آیتم رو ذخیره می کنن نگهشون داریم؟
البته این سوال من از نظر سرعت ذخیره و بازیابی اطلاعات بود
ممنون

[araelectronic@ymail.com]

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

[morika]

خب اجازه بدین من سوالم رو واضح تر بیان کنم
ببینید این برنامه ای که من دارم طراحی می کنم از چند بخش تشکیل شده که هر بخش کارش از کار بخش دیگه کاملا جداست. بخش هایی مثل فروش، انبار و ... که البته کار اینها در سیستم من کاملا از هم جداست و هیچ ربطی به هم نداره که تقریبا تعداد این بخش ها 7 یا 8 تا میشه. حالا فقط تو یکی از این بخش ها در روز چیزی حدود 50 رکورد جدید به بانک اضافه میشه. این رکوردی که اظافه میشه 22 تا فیلد داره که به طور مستقیم ثبت میشن و مشکلی ندارن اما یه سری اطلاعات هم هست که خودشون به صورت یک جدول هستن. یک جدول 5*23. یعنی برای هر رکرود جدید ما نیاز داریم که یه جدول 115 فیلدی هم ذخیره بشه. منطقی ترین راهی که به ذهن من میرسه اینکه این جدول تویه table جدا ذخیره بشه و ID رکوردهاش با ID رکورد اصلی در table اول برابر باشه که بعدا بشه select کردشون. اما سوالی که من الان دارم اینکه با این طراحی حدودا روزی 1150 تا رکورد به table دوم اضافه میشه که میکنه سالی 414000 تا رکورد. این تعداد رکورد مشکلی برای سرعت برنامه ایجاد نمی کنه؟ البته قرار نیست با این رکوردها کار خاصی انجام بشه فقط ممکنه گاهی اوقات مدیر سیستم بخواد یه گزارش از فرم ثبت شده تو فلان تاریخ بگیره که اونوقت تمام اطلاعاتی که مربروط به اون رکورد هست علاوه بر اون جدولش (5*23) که تو table دوم ذخیره شده باید لود بشه که دیگه معلوم نیست کجای این 414000 تا رکورد هست. میخواستم بپرسم بعداز 1 سال اگه اون مدیر بخواد گزارش بگیره مشکلی براش پیش نمیاد؟ یا کلا مشکلی خاصی برای نرم افزار وجود داره؟
حالا نمی دونم چقد تونستم منظورم رو به دوستان منتقل کنم
البته این نکته رو هم اضافه کنم که من بانکم رو با SQL Server 2008 طراحی کردم
ممنون

[araelectronic@ymail.com]

با سلام

بنظر میرسه که تحلیل پایگاهتون ایراد داره و شما افزونگی داده دارید. اگر خواستید توضیح بیشتری در مورد جداولتون بدید . 414000 فیلد برای sql 2008 رقم ناچیزی هست ولی بازهم میگم بهتر هست در نرمالسازی پایگاهتون تجدید نظر کنید

[مهدی هادیان2]

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

[morika]

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

[araelectronic@ymail.com]

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

اینها حداقل جداولی هستند که نیاز هست. قطعا به جداول بیشتری برای ارتباط بین جداول نیز نیاز دارید .

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

[morika]

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

[araelectronic@ymail.com]

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