درج اطلاعات بدون محدودیت [بایگانی]

sajaaaaad

شنبه 17 مرداد 1394, 11:57 صبح

با درود خدمت استادان عزیز
.
خیلی از برنامه های حسابداری میزنن که درج اطلاعات بدون محدودیت.! و بانک اطلاعاتیشون اسکیوال هست، سوالی که دارم اینه که چطور اینکار انجام میشه.؟
1- آیا تمام اطلاعات واقعا روی یک دیتابیس ذخیره میشه.؟
2- جدولا با این حجم اطلاعات هنگ نمیکنن.؟
3- آیا میشه کاری کرد که هر سال داده های سال قبل یک گوشه ذخیره بشن و بانک ها از اول شروع بکار کنن.؟ مثلا میگم: من یک جدول دارم که داره سریال های مربوط به محصولات در سال 94 رو ذخیره میکنه، حالا که رفته سال 95 میخوام جدولم از اول شروع بشه و سریال های 95 رو ذخیره کنه! ولی خب از طرفی میخوام اطلاعات سال قبل رو هم هرموقع احتیاج داشتم نگا کنم.! باید چکار کنم.؟
.
با تشکر

SabaSabouhi

شنبه 17 مرداد 1394, 13:14 عصر

با درود خدمت استادان عزیز
.
خیلی از برنامه های حسابداری میزنن که درج اطلاعات بدون محدودیت.! و بانک اطلاعاتیشون اسکیوال هست، سوالی که دارم اینه که چطور اینکار انجام میشه.؟
1- آیا تمام اطلاعات واقعا روی یک دیتابیس ذخیره میشه.؟
2- جدولا با این حجم اطلاعات هنگ نمیکنن.؟
3- آیا میشه کاری کرد که هر سال داده های سال قبل یک گوشه ذخیره بشن و بانک ها از اول شروع بکار کنن.؟ مثلا میگم: من یک جدول دارم که داره سریال های مربوط به محصولات در سال 94 رو ذخیره میکنه، حالا که رفته سال 95 میخوام جدولم از اول شروع بشه و سریال های 95 رو ذخیره کنه! ولی خب از طرفی میخوام اطلاعات سال قبل رو هم هرموقع احتیاج داشتم نگا کنم.! باید چکار کنم.؟
.
با تشکر

سلام
وقتی شما روزی یک سکه بخواهی پس انداز کنی و صندوقی داشته باشی که 10000 سکه گنجایش داشته باشه
می‌تونی بگی صندوقت نامحدود هست یا نه؟
اگه از نظر ریاضی بخوایم جواب بدیم، نه صندوق نامحدود نیست چون محدود به 10000 سکه هست
اما از نظر منطقی حدود 30 سال طول می‌کشه تا این صندوق پر بشه، پس می‌شه اون رو نا محدود دونست.

میزان اطلاعاتی رو که sql server حتا در نسخه‌های express edition که نسخه‌های رایگان هست می‌تونن نگهداری
کنن تا حدی هست که تاریخ مصرف نرم‌افزار شما نمی‌تونه اون رو پر کنه ( با این فرض که نرم‌افزار منطقی نوشته شده باشه )
پس به نوعی می‌شه گفت که عبارت «بدون محدودیت» قابل قبول هست.

1. بله می‌تونه روی یک دیتابیس باشه و منطقی هم اینه که همینطور باشه
2. جدول که اصولاً چیزی نیست که بخواد هنگ کنه، اما اگه منظورتون sql server هست.
باید بگم که خیر sql server هنگ نمی‌کنه، در واقع sql server با اطلاعات خیلی خیلی بیش‌تر از یک سیستم حسابداری هم هنگ نمی‌کنه.
3. بله شدنش می‌شه، اما کار صحیحی نیست. کلی اضافه‌کاری انجام می‌دی برای این که همون نتیجه‌ای رو بگیری که بدون این کارها
می‌گرفتی. درست مثل این می‌مونه که یک بقالی بخوای تو مغازه‌اش دیوار بکشه و قسمت فروش مواد غذایی، بهداشتی، فرهنگی و غیره رو
جدا کنه. شدنش می‌شه، اما خوب که چی!

فقط تصور کن که بخوای یک گزارش مقایسه‌ای بین سه‌ماهه اول سال جاری و سال گذشته رو تولید کنی . . .

صبا صبوحی

sajaaaaad

شنبه 17 مرداد 1394, 14:35 عصر

همون باشه، منم از همیناش میترسم دیگه.! اصلا نمیتونم تصورم کنم چطور سال گذشته رو با سال جدید مقایسه کنم.! پس همرو توی یک دیتا بیس نگهدارم، به مشکلم اگر خوردم پای شماست :لبخندساده:
اون برنامه ای که گفتم سریال هاش قراره از 10000001 شروع بشه و تا 99999999 ادامه پیدا کنه! آیا با این حجم داده مثلا میگم 90 میلیون sql مشکل نمیخوره.؟ جدولمم به اینصورته که، یک شماره محصول هشت رقمی داده و یک شماره سریال، که معلوم میشه هر محصول سریالش چیه، شماره پرسنلی داره، که مشخص میشه چه فردی اون سریال رو پرینت گرفته، و هر محصول سریال کارتن مادرش چیه.!
اینجوری:
1394/05/16 ---- کدمحصول -- کدپرسنل --- شماره سریال --- شماره کارتن مادر --- کدموتور
.
"کد" یعنی کلید خارجی.! از جدول دیگه خونده میشه.! آیا با سه چهارتا کلید خارجی مشکلی بوجود نمیاد.؟
با تشکر

SabaSabouhi

یک شنبه 18 مرداد 1394, 09:13 صبح

همون باشه، منم از همیناش میترسم دیگه.! اصلا نمیتونم تصورم کنم چطور سال گذشته رو با سال جدید مقایسه کنم.! پس همرو توی یک دیتا بیس نگهدارم، به مشکلم اگر خوردم پای شماست :لبخندساده:
اون برنامه ای که گفتم سریال هاش قراره از 10000001 شروع بشه و تا 99999999 ادامه پیدا کنه! آیا با این حجم داده مثلا میگم 90 میلیون sql مشکل نمیخوره.؟ جدولمم به اینصورته که، یک شماره محصول هشت رقمی داده و یک شماره سریال، که معلوم میشه هر محصول سریالش چیه، شماره پرسنلی داره، که مشخص میشه چه فردی اون سریال رو پرینت گرفته، و هر محصول سریال کارتن مادرش چیه.!
اینجوری:
1394/05/16 ---- کدمحصول -- کدپرسنل --- شماره سریال --- شماره کارتن مادر --- کدموتور
.
"کد" یعنی کلید خارجی.! از جدول دیگه خونده میشه.! آیا با سه چهارتا کلید خارجی مشکلی بوجود نمیاد.؟
با تشکر

سلام
دوست من، نگران نباش. Sql Server یک محصول ایرانی نیست، برای یه شرکت ایرانی هم نوشته نشده.
این محصول نتیجه‌ی سال‌ها کار شرکت بزرگ مایکروسافت هست و شرکت‌های بزرگی ازش استفاده می‌کنن.
اگه قرار بود برای 3-4 کلید خارجی یا مثلاً چند میلیون رکورد ( که هرگز تو برنامه‌ی حسابداری بهش نمی‌رسی )
دچار مشکل بشه، مطمئن باش مایکروسافت نمی‌تونست زیر بار شکایت مشتریاش کمر راست کنه.

در ضمن معنی «سریال از 10000000 شروع بشه و تا 9999999999 بره رو نمی‌فهمم.
سعی کن از روش‌های استاندارد تو طراحی دیتابیس استفاده کنی.

صبا صبوحی

gelayor14

جمعه 23 مرداد 1394, 19:42 عصر

با درود خدمت استادان عزیز
.

3- آیا میشه کاری کرد که هر سال داده های سال قبل یک گوشه ذخیره بشن و بانک ها از اول شروع بکار کنن.؟ مثلا میگم: من یک جدول دارم که داره سریال های مربوط به محصولات در سال 94 رو ذخیره میکنه، حالا که رفته سال 95 میخوام جدولم از اول شروع بشه و سریال های 95 رو ذخیره کنه! ولی خب از طرفی میخوام اطلاعات سال قبل رو هم هرموقع احتیاج داشتم نگا کنم.! باید چکار کنم.؟
.
با تشکر
این مورد سوم ، برای من هم پیش اومده -> همرو تو یه دیتابیس میزاریم اما حجم این دیتابیس میره بالا تا جایی که زمانیکه مجبور به جا به جایی دیتابیس به دلیل رخ دادن مشکل ای میشیم
این حجم زیاد رو از طریق اینترنت جابه جا کردن واقعا مشکل میشه!
برای مشکل سنگین شدن دیتابیس هم راه حلی وجود داره آیا؟

SabaSabouhi

یک شنبه 25 مرداد 1394, 12:46 عصر

این مورد سوم ، برای من هم پیش اومده -> همرو تو یه دیتابیس میزاریم اما حجم این دیتابیس میره بالا تا جایی که زمانیکه مجبور به جا به جایی دیتابیس به دلیل رخ دادن مشکل ای میشیم
این حجم زیاد رو از طریق اینترنت جابه جا کردن واقعا مشکل میشه!
برای مشکل سنگین شدن دیتابیس هم راه حلی وجود داره آیا؟

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

به نظر من، چیزی به عنوان جابجا کردن دیتابیس از طریق اینترنت کاملاً تفکر اشتباهی هست چه برسه به این که این تفکر
پیاده‌سازی بشه.
دیتایبس یک شرکت، در حد دفاتر حسابداری اون شرکت اهمیت داره و محرمانه هست. من به شخصه به هیچ عنوان
اجازه نمی‌دم که تو جاهایی که کار می‌کنم یا به عنوان پیمان‌کار یا مشاور همکاری می‌کنم سروری که Sql Server روش
نصب هست به اینترنت دسترسی داشته باشه.
شاید برای اغلب شرکت‌ها این قضیه اهمیت نداشته باشه، اما خود من شاهد و ناظر حملات اینترنتی شکست خورده
از دو کشور آلمان و کره به سرور یک شرکت فعال در صنعت خودرو بودم.
با توجه به این که تو کشور ما اهمیت حفاظت اطلاعات بسیار کم دیده می‌شه و اغلب افراد از اهمیت این امر بی‌خبر هستن
این وظیفه‌ی ما هست که در این حوزه به مشتری‌هامون اطلاعات لازم رو بدیم و خودمون زمینه‌ی لو رفتن اطلاعات رو
فراهم نکنیم.
مطمئن باش که در آینده‌ی نزدیک بزرگ‌ترین دغدغه‌ی پلیس فتا که الان برداشت غیر مجاز پول از حساب‌های بانکی هست
به لو رفتن و دزدیده شدن اطلاعات تبدیل خواهد شد.

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

صبا صبوحی

gelayor14

یک شنبه 25 مرداد 1394, 21:44 عصر

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

به نظر من، چیزی به عنوان جابجا کردن دیتابیس از طریق اینترنت کاملاً تفکر اشتباهی هست چه برسه به این که این تفکر
پیاده‌سازی بشه.
دیتایبس یک شرکت، در حد دفاتر حسابداری اون شرکت اهمیت داره و محرمانه هست. من به شخصه به هیچ عنوان
اجازه نمی‌دم که تو جاهایی که کار می‌کنم یا به عنوان پیمان‌کار یا مشاور همکاری می‌کنم سروری که Sql Server روش
نصب هست به اینترنت دسترسی داشته باشه.
شاید برای اغلب شرکت‌ها این قضیه اهمیت نداشته باشه، اما خود من شاهد و ناظر حملات اینترنتی شکست خورده
از دو کشور آلمان و کره به سرور یک شرکت فعال در صنعت خودرو بودم.
با توجه به این که تو کشور ما اهمیت حفاظت اطلاعات بسیار کم دیده می‌شه و اغلب افراد از اهمیت این امر بی‌خبر هستن
این وظیفه‌ی ما هست که در این حوزه به مشتری‌هامون اطلاعات لازم رو بدیم و خودمون زمینه‌ی لو رفتن اطلاعات رو
فراهم نکنیم.
مطمئن باش که در آینده‌ی نزدیک بزرگ‌ترین دغدغه‌ی پلیس فتا که الان برداشت غیر مجاز پول از حساب‌های بانکی هست
به لو رفتن و دزدیده شدن اطلاعات تبدیل خواهد شد.

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

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

به هرحال ممنونم از نظرتون

pbm_soy

دوشنبه 26 مرداد 1394, 02:43 صبح

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

pbm_soy

دوشنبه 26 مرداد 1394, 02:51 صبح

مثال دیگه ای به ذهنم رسید که چند روز پیش اتفاق افتاده بود
بنده خدا از من میپرسه : برنامه روی دستگاهی که میزان رم و cpu و هارد پایینتری نسبت به دیگری بدون مشکل کار میکند مخصوصا بخش گزارش گیری و پشتیبانگیری و حتی تعداد رکوردهاش هم حدود ۶ برابر بیشتر است ولی بروی دستگاه قویتر دیگری در جای دیگری باتعداد رکوردهای کمتری این کارها را نمیتواند انجام دهد و سیستم قفل میکند حتی بعداز ۲۴ ساعت هم نمیتواند انجام دهد
به شرکت نرم افزاری که میگن مسول فنی میگه سخت افزارتون ضعیف است و دستگاه قویتری تهیه کنید آیا این جواب منطقی است؟!
حداقل کاری که طرف باید‌میکرد یا میگفت این بود که میگفت شاید از ویندوز باشد و شاید از نسخه sql باشد و غیره دلایل خیلی زیادی برای این مشکل میتواند وجود داشته باشد معمولا در آخرین مرحله باید سراغ سخت افزار رفت

SabaSabouhi

دوشنبه 26 مرداد 1394, 08:33 صبح

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

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

اول باید طراحی صحیح و اصولی باشه. سپس باید درست پیاده‌سازی بشه. در این صورت معمولاً با سخت‌افزارهای متعارف
نرم‌افزارها باید درست و بی‌مشکل کار کنن. ( البته با سرعت قابل قبول )

و اما در پاسخ دوستمون Gelayor14

دوست عزیز، حقیقتش اینه که برای کم کردن حجم راه‌حل زیاده، اما اگه فرض کنیم که دیتابیس اصولی طراحی شده باشه و اشکالی
نداشته باشه و فقط به دلیل زیاد بودن رکوردها حجم دیتابیس بالا رفته، من راه حل مناسبی برای کوچک کردن سراغ ندارم و گمان می‌کنم
که اصولی هم نباشه. البته اگه شما قصد ارسال یک backup از دیتابیس رو داری حتماً اون رو فشرده کن، تو تست‌هایی که من داشتم حدود
90% کوچک می‌شن.

صبا صبوحی

golbafan

دوشنبه 26 مرداد 1394, 10:16 صبح

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

مشکل کجا میتونه باشه؟

SabaSabouhi

سه شنبه 27 مرداد 1394, 08:34 صبح

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

مشکل کجا میتونه باشه؟

سلام
معمولاً نرم‌افزارهای مدیریت دیتابیس برای نگهداری اطلاعات از BTree استفاده می‌کنن. راستش نمی‌دونم نسبت به
BTree شناخت داری یا نه. BTree یک درختی هست که هر گره اون بجای یک رکورد یک بلوک از رکوردها هست.
و همیشه بخش بزرگی از این بلوک‌ها خالی هستن. در نتیجه میزان فضای مصرفی یک دیتابیس روی حافظه‌ی جانبی
همیشه بزرگتر از میزان اطلاعات واقعی ثبت شده هست. به علاوه برای نگهداری تک تک اندیس‌ها هم از همین ساختار
استفاده می‌شه.
گمان می‌کنم این تفاوت حجمی که شما مشاهده کردی، باید به تنطیمات BTree مربوط باشه، یعنی اندازه‌ی بلوک‌ها
و میزان خالی بودن بلوک‌ها. ( این قابل تنظیم هست که در چه شرایطی یک بلوک شکسته بشه، مثلاً وقتی پر شد یا
وقتی به 70% گنجایش خودش رسید )
و این رو هم مطمئن هستم که هدف‌گذاری شرکت‌های تولید کننده‌ی DBMS بهینه‌بودن حجم دیتابیس نیست، بلکه سرعت
بالا به‌ویژه در دیتابیس‌های بزرگ و سنگین هست.

صبا صبوحی

golbafan

سه شنبه 27 مرداد 1394, 08:55 صبح

مرسی جناب صبوحی
خب میشه لطفا در مورد حافظه (رم) اشغال شده sqlserver نسبت به اون دو مورد دیگه هم توضیحاتی بفرمایید
گاهی 3 تا 4 گیگ از رم های سرورهام رو اشغال میکنه :افسرده: و پرفورمنس خیلی افت میکنه

این رو هم بگم که من با فضای گرفته شده در هارد دیسک ها مشکلی ندارم. زیاد بشه یه هارد دیگه اضافه میکنم. اما رم رو نمیتونم همیشه اضافه کنم

چه تنظیماتی لازمه که هم پرفورمنس بهینه بشه و هم حافظه رم

SabaSabouhi

سه شنبه 27 مرداد 1394, 11:42 صبح

مرسی جناب صبوحی
خب میشه لطفا در مورد حافظه (رم) اشغال شده sqlserver نسبت به اون دو مورد دیگه هم توضیحاتی بفرمایید
گاهی 3 تا 4 گیگ از رم های سرورهام رو اشغال میکنه :افسرده: و پرفورمنس خیلی افت میکنه

این رو هم بگم که من با فضای گرفته شده در هارد دیسک ها مشکلی ندارم. زیاد بشه یه هارد دیگه اضافه میکنم. اما رم رو نمیتونم همیشه اضافه کنم

چه تنظیماتی لازمه که هم پرفورمنس بهینه بشه و هم حافظه رم

سلام
حقیقتش اینه که من با DBMSهای دیگه کار نکردم که بتونم مقایسه کنم. اما این رو می‌دونم که SQL Server مقدار زیادی
از حافظه اصلی رو اشغال می‌کنه که بالاترین بهره‌وری رو داشته باشه. به همین دلیل برای کارهای بزرگ خوبه که مقدار
حافظه مناسبی رو برای سرور در نظر بگیریم.
البته از این نباید گذشت که کلاً شرکت مایکروسافت در زمینه مصرف بهینه‌ی حافظه در تمام طول تاریخش مشکل
اساسی داشته. :لبخندساده:

صبا صبوحی

bobesfanji

چهارشنبه 28 مرداد 1394, 08:35 صبح

خانم صبوحی من توصیه میکنم سایر dbms ها رو هم تست بفرمایید. ضرر نخواهید کرد.

در مورد امنیت دیتا، متاسفانه sqlserver خیلی جالب نیست (شاید بدلیل عمومیت اون باشه. نمیدونم)

اوراکل رو اول از همه تست کنید