تعداد زیاد رکوردها در بانک

[morika]

سلام
من یه برنامه ای برای شرکت هواپیمایی نوشتم که بانکش SQl Server 2008 هست
با محاسباتی که کردم سالی 2,574,000 رکورد به بانک اضافه میشه که از قرار معلوم اصلا قرار نیست حتی یکیش هم پاک بشه
تا جایی که تونستم سادش کردم ولی دیگه از این ساده تر نمیشه تمام اطلاعات لازمه و باید ثبت بشه. حالا دوتا سوال دارسم از خدمتتون
اول اینکه آیا هنچین تعداد رکوردی استاندارد هست که در بانک ذخیره بشه و مشکلی بوجود نمیاره؟
دوم اینکه وقتی یه رکورد در بانک ثبت میشه حدود 140 تا فیلد داره. حالا من جوری طراحی کردم که این 140 تا فیلد توی 4تا table ذخیره بشن. چون یه جورایی میشه دسته بندیشون کرد و واسه هر کدوم یه table ساخت
می خواستم ببینم اینکه تو 4تا table ذخیره بشن بهتراز اینکه تو یه table باشه یا نه؟
ممنون

[ce_safdari]

سلام


مشکل اینکه، باید استاندارد های نرمال سازی رو خوب انجام داده باشین..

گرید هاتون رو صفحه بندی کنید و مثلا 10 تا 10 تا داده ها رو بخونید.

index گذاری درست جداول رو باید رعایت کنید...

بحث شکستن یک جدول به چندین جدول هم خوبه اما بستگی به داده ها، مقدارهای null و صورت مسئله داره...

مثلا اطلاعات جدول کاربر و مشخصات کاربر رو توی 2 تا جدول می گیرند، یکی برای نام کاربری، کلمه عبور و فعال/غیر فعال و در جدول دیگر نام پدر، و اطلاعات اضافی دیگر.... که ارتباط این دو جدول یک به یک است.

[veniz2008]

سلام.
برای افزایش سرعت یکسری نکات رو مد نظر قرار بدید:
1. کلید جدول رو که معمولا جستجوهای زیادی بر پایه اون انجام میشه، حتی الامکان int در نظر بگیرید. چراکه سرعت در جستجوی فیلدهای عددی نسبت به غیر عددی بیشتر هست.
2. کلید رو تا حد امکان ساده بگیرید و از ابرکلید(کلید ترکیبی) استفاده نکنید.
3. تا حد امکان از nvarchar استفاده نکنید چراکه دو برابر varchar فضای دیتابیس رو اشغال میکنن.
4. تا حد امکان جداول رو به گونه ای بسازید که نیاز به join های بی مورد بین جداول نباشه.
5. به غیر از فیلد کلید که خود sql بصورت اتومات یک clustered index براش میسازه. خودتون با توجه به نیاز پروزتون یک یا چند non clustered index برای جداولتون ایجاد کنید. البته در ایجاد تعداد زیاد این ایندکس ها زیاده روی نکنید. یکی از راه های تشخیص اینکه چه فیلدی رو non clusterd index قرار بدید اینه که روی چه فیلدی بیشتر عملیات جستجو رو انجام می دید. البته معیارهای دیگه ای هم هست که توصیه میکنم حتما درباره ایندکس ها مطالعه بفرمایید. چون ایندکس مناسب بر روی سرعت جستجوها (در تعداد رکوردهای زیاد) قدرت خودش رو به معرض نمایش میزاره.
6. استفاده از کوئری های بهینه. فرض کنید بخوایم بفهمیم که آیا یک شماره شناسایی (کلید) که توسط کاربر وارد شده است در جدولی با تعداد رکوردهای خیلی زیاد وجود داره یا نه. برای این کار دو کوئری زیر رو در نظر بگیرید :
1. استفاده از دستور EXISTS :


if(EXISTS(select UserID from TblUser where UserID = @userid))

2. استفاده از count :

select count(UserID) from TblUser where UserID = @userid




کوئری اول (دستور EXISTS ) به محض پیدا کردن رکورد، دیگه جستجو رو ادامه نمیده ولی کوئری دوم (دستور count) تا آخرین رکورد جدول رو پیمایش میکنه. این فقط یک مثال ساده بود. این مطلب رو در کنار ایندکس مناسب، بسیار جدی در نظر بگیرید.
7. سخت افزار قدرتمند. بدون شک شما برای محاسبه و جابه جایی اطلاعات به cpu و رم مناسب نیاز خواهید داشت.
گذشته از این موارد، طراحی درست و سبک کدنویسی شما میتونه اهمیت زیادی داشته باشه. مثلا استفاده از stored procedure ها در مقایسه با روش های معمولی بسیار کارآمدتر خواهد بود.
اینکه گفتید قرار نیست هیچ اطلاعاتی حذف بشه، بهرحال احتمالش زیاده که بعد از یکی دو سال دیگه اطلاعات قدیمی به درد نخوره یا حداقل برای سال جاری کاربردی نداشته باشه. میتونید برای رکوردها یک فیلد وضعیت از جنس bit داشته باشید که نشون بده ایا رکوردهای سال قبلی فعال هستند یا نه. یا اینکه یک جدول ثانویه داشته باشید و رکوردهای بدون کاربرد رو به اونجا منتقل کنید.
بهرحال باید کاملا باهاشون صحبت کنید و تحلیل دقیقی داشته باشید. چون این تعداد رکورد که فرمودید سالیانه اضافه میشه اگر مدیریت نشه میتونه بر روی سرعت، اثر منفی بذاره.

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

بسم الله الرحمن الرحیم
با سلام
به نظر دوستانی که تجربه کار با بانک رو دارند اگر قرار بر فدا کردن باشد؛ تعداد رکورد زیاد فدا شود یا joinها و تعداد جدوال های بیشتر؟
با سپاس فراوان

[ce_safdari]

پاسخ به آقای هادیان 2

ببینید اگر جداول بانک رو به جداول دیگر بشکنید و تقسیم بندی کنید هیچ اشکالی ندارد که join های زیادی داشته باشید.و اصولا اگر ایندکس گذاری درست باشه و کلید اصلی هم از جنس int باشه هیچ مشکلی نیست، sqlserver دیتابیس قدرتمندی است به شرطی که طراحی اصولی باشه، و غصه رکورد میلیونی هم نباید بخورید.

من منظور سوال شما رو از فدا کردن هم نفهمیدم.

[محمد سلیم آبادی]

اول اینکه آیا هنچین تعداد رکوردی استاندارد هست که در بانک ذخیره بشه و مشکلی بوجود نمیاره؟

استاندارد رو ظرفیت Hard Disk تون مشخص میکنه. مراقب باشید همیشه فضای کافیه روی Drive و یا Hard Disk اتان برای افزایش حجم فایل هایتان باشد.


دوم اینکه وقتی یه رکورد در بانک ثبت میشه حدود 140 تا فیلد داره. حالا من جوری طراحی کردم که این 140 تا فیلد توی 4تا table ذخیره بشن. چون یه جورایی میشه دسته بندیشون کرد و واسه هر کدوم یه table ساخت
می خواستم ببینم اینکه تو 4تا table ذخیره بشن بهتراز اینکه تو یه table باشه یا نه؟
تفکیک کردن جدول در این حالت یکسری معایب داره که به این شرح است:


افزایش عملیات join هنگام واکشی داده ها از چند جدول. نوشتن query های پیچیده تر نسبت به یک select ساده.
افزایش عملیات هنگام حذف داده ها از جدول master هنگامی که cascading referential integrity فعال است. فرض کنید با حذف یک سطر باید سه سطر دیگه از سه جدول دیگه حذف بشن.
پیچیده شدن تراکنش درج، حذف و بروزرسانی. فرض کنید کاربر اطلاعات را داره در یک فرم وارد میکنه با فشردن دکمه ذخیره. باید چهار دستور insert به جای یک دستور insert اجرا بشه.
مشکل در مقید کردن داده هایی که null نمی پذیرند. فرض کنید میخواهید داده هایی در جدول اصلی ذخیره بشن با این شرط که حتما به ازای این سطر در جداول دیگر نیز مقدار درج شده باشد. چطور اینکار انجام میشه؟

شاید هیچ کدام از اینها دلیل بر کاهش performance نباشه. ولی حداقل کار شما را دشوار تر خواهد نمود بنظر میرسه مدیریت یک جدول به مراتب ساده تر از مدریت چهار جدول باشه.


ضمنا راجب Partitioning و مفهوم File Group اگر اطلاعی ندارین تحقیق کنید.

میشه یک جدول رو بدون تفکیک کردن تجزیه کرد. چه افقی (سطرهای جدول) چه عمودی (ستون های جدول). بطور ظاهری تصور میشه همه داده های جدول در یک جا جمع شدن ولی عملا هر کدام در یک Drive یا حتی Hard Disk مستقل ذخیره شدن.