مقایسه Access و SQL Server !؟

[nabeel]

سلام

مسیر رو به صورت معکوس بریم تا ببنیم توی سرمنشاً این گفتگو چه چیزی حاصل میشه

با اشاره به یه داستان و خلاصه وار شروع میکنم :

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

سهم اون فرد از اون همه زمین تنها یک متر شد !

ولیکن ارتباط این داستان به ظاهر بی ربط با موضوع این تاپیک !؟
کم نیستن کاربرانی که با این شاخه به اون شاخه پریدن , هم زمان رو از دست میدن و هم از اینجا رونده و از اونجا مونده میشن
سعی بشه , در انتخاب یک مسیر و یا یک رویه از این شاخه به اون شاخه پریدن به حداقل ممکن تقلیل پیدا کنه . و هدف با توجه به سطح عملیات در نظر گرفته بشه .
...........................
موضوع تقابل بین Access و SQL Server بارها و بارها تکرار شده ، قیاسی که شاید بشه گفت در بسیاری موارد موضوعیت نداره !
جالب اینکه این قیاسها غالباً توسط افرادی انجام میشه که در بخش اکسس فعالیت نمیکنن ( حداقل به صورت حرفه ای )
Access و SQL Server هر دو به عنوان پایگاه داده مورد استفاده قرار میگیرن ، و امکان اتصال به بسیاری محیطهای IDE رو دارن ، به طور مثال یک شرکت ممکنه برای طراحی یک سیستم انبار از تلفیق VB و Access و یا VB و SQL Server استفاده کنه .
غالب این مقایسه ها مربوط به محیطهای توسعه دیگه به غیر از خود اکسس هستند و این ضعف و قوتها وقتی معنی پیدا میکنه که شما از محیط IDE دیگه ای به غیر از اکسس , میخواید به یک دیتابیس وصل بشید .
تمامی قابلیتهای عمومی اکسس بسیار فراتر از حد نیاز 99 درصد توسعه دهنده ها هستند
بسیاری برتریهای SQL Server آرمانی بوده و عملاً در مقوله کارکردی Access قرار نمی گیرن
برخی از محدودیتهای Access رو بررسی میکنیم تا ببینیم چه طیف افرادی که با Access کار میکنند رو دچار مشکل میکنه ( با اکسس به عنوان محیط توسعه و نه تنها محل ذخیره سازی اطلاعات )
حجم 2 گیگابایت هر فایل
چه تعداد از شما با سیستمهایی کار میکیند که از این حد فراتر میره ، آیا مشکل شما رو Linked Tables حل نمیکنه ، چرا که این روش این محدودیت رو هم رفع میکنه
تعداد کاربر 255 نفر
محدودیت تعداد کاربر در داخل اکسس 255 عنوان میشه ( جدا از میزان واقعیت داشتن اون و سطح دستیابی به اون ) ، برنامه های شما چند کاربره هستند ؟ در بسیاری شرکتها تنها بخش اندکی از این قابلیت فرانیازی SQL Server مورد استفاده قرار میگیره ، در SQL محدودیتی در این خصوص وجود نداره ! و منوط به میزان حافظه سیستم شده ، ولی واقعیتها قابل لمس هستند ، تعداد کاربرهای سیستمهای شما با تقریب خوبی قابل تخمین بوده و غالباً در محدوده یک عدد Byte قرار میگیرن .
تعداد جداول شرکت داده شده در Query
در اکسس 32 جدول و در SQL 255 جدول !
شما تا حالا توی پیچیده ترین Query هاتون از چند جدول استفاده کردید ، به نظر شما این تفاضل شماتیک نیست و فاصله زیادی با کاربردهای واقعی نداره !
تعداد آبجکتهای قابل پذیرش
در اکسس 32768 و در SQL این مقدار 2147483647 آبجکت ! ( مقایسه نکنیم سنگین تریم ! )
اگه یه پروسیجر بنویسید که اقدام به ایجاد آبجکت به صورت رندوم کنه اونهم بدون هدف ، باید در هر ثانیه 24855 آبجکت ایجاد کنه تا کار پس از 24 ساعت تموم بشه !! واقعاً دیتا بیسی با این تعداد آبجکت وجود داره و یا اینکه جمع کل آبجکتهای تمام دیتابیسها از آدم تا خاتم , اینقدر میشه !!؟
و همین طور مابقی قیاسهایی که در خصوص مقایسه های عددی این دو جاریه
ولیکن در خصوص مباحث فنی ترشون :
بعضی مقایسه ها با توجه به اینکه اکسس Client Base هستش و SQL Server از نوع ، Client/Server Base مقایسه بی معنی میشه
مقایسه وقتی مصداق پیدا میکنه که هر دو دارای یک قابلیت باشن ، نه اینکه یکی از دو طرف داشته باشه و دیگری نه ! در این حالت این ابهام بوجود میاد که مقایسه بر سر چیه ؟
حیطه عملکردی SQL Server و مبانی کاربرد اون کاملاً با اکسس متفاوته و این دو در یک جایگاه قرار نمیگیرن و هر گونه مقایسه این دو ، بدون جانبداری ، منجر به برنده عنوان شدن هیچ یک از این دو نمیشه !

ولیکن در ادامه پرسشهایی مطرح میشه که شاید پاسخ به اونها مطلب رو روشنتر کنه :

1 – آیا محدودیتهای تئوریک Access برای سیستمی که شما طراحی میکنید ، مشکلی ایجاد کرده و به چه میزان ؟
2 – آیا نحوه طراحی شما ، مزید بر علت نبوده تا به ناحق خط بطلانی بر یک قابلیت اکسس کشیده بشه ( خیلیهامون دیدیم که طرف با وانت مسافر کشی میکنه و با پراید ناچ بک باربری !! ، اگه نیاز شد برای همین مورد هم توی اکسس مثال میزنم ! کم نیست ! )
یک مشکل وجود داره ، کسانی که با قابلیتهای ذاتی اکسس نتونن کار کنن و از این محیط یکپارچه نتونن به درستی و راحتی استفاده کنن ، با قطعیت 100 % در اتصال و استفاده ازServer SQL دچار مشکل میشن . ( در همونهای گامهای اولیه )

البته باید توجه داشته باشید که شما برای استفاده تئوریک از کلیه برتریهای SQL Server در داخل Access هم باید از Access Project استفاده کنید و نه خود Access Database ، که اونهم مشکلات فنی دیگه ای رو اضافه میکنه .

فقط در خصوص SMP support بودن SQL Server یه توضیح بدم ، چونکه این قابلیت به طور کامل در Access وجود نداره

SMP و یا همون symmetric multiprocessor در حالتی که چند CPU بر روی سیستم نصب باشه ، اجازه عملکرد موازی رو میده و در واقع سرعت پردازش رو بالا میبره ، گلوگاه اصلی بسیاری سیستمهای نرم افزاری CPU نیست تا حالا SMP بتونه تغییر زیادی رو در این خصوص بده ، گلوگاه شبکه ، همچنان پابرجاست . ( گو اینکه سیستمهای چند CPU به دلیل افزایش کارایی کلی سیستم میتونن منجر به افزایش سرعت نسبی تمامی نرم افزارها بشن ، ولیکن با نسبتهای متفاوت ، که به نظر میاد نیازی به توضیح بیشتری در این رابطه نباشه )
آیا Server شما از گونه Multiprocessor هستش ، اگر جواب خیره ، پس اولین قابلیت و برتری فنی Server SQL رو خط بزنید
در اکثر سیستمهای اطلاعاتی ، سیستم متکی به محدودیت توان پردازشی CPU نیست و در واقع حجم اطلاعات هستش که منجر به افت و خیز در این امر میشه . فی المثل در یک سیستم انبار داری , غالب گزارشات مبتنی بر چهار عمل اصلی بوده ( یعنی مبانی محاسبات و به دور از پییچدگی ) ولیکن نکته حائز اهمیت همون تعدد رکورد میتونه باشه .
در خصوص مابقی برتریهای فنی SQL Server تصور میکنم با توجه به جایگاه فعلی نیازی به بحث نباشه ، برخی قابلیتها اگه در اکسس وجود ندارن و یا به ظاهر و بر اساس اعداد ضعیفتر هستند ، به دو دلیله :

1 - روش حل مساله در اکسس به گونه ای دیگه هستش ( فراموش نکنید Access یک IDE هستش ) ، و در واقع دقیقاً اون قابلیت با توجه به نقصان موجود در SQL Server و یا IDE مربوطه ، به گونه ای متناسب با حال و هوای خود اونها طراحی شدن که حالا جالبه به عنوان نقطه قوت مطرح میشن !؟
2 – اون قابلیت برای اکسس موضوعیتی نداره ، حیطه عملکردی اون دو متفاوته و در دو مسیر جدا قرار دارن ( وگرنه اسم یکیش Access و اون یکی SQL نمیشد )
تصور غلطی ظاهراً حاکمه که شاید خیلیها SQL Server رو نسخه ارتقا یافته Access فرض میکنن و در واقع متصورن آپشن دیگه اونه و در صدد تلقین و مقایسه دو سیستم متفاوت هستند .
این دو قابل مقایسه نیستن و در واقع در دو پلت فرم و الگوی مجزا پیاده سازی میشن .

مایکروسافت در هیچ جایی این ادعا رو نداره که این دو زوجهایی مناسبی برای هم هستند ( SQL Server و اکسس )
قابلیت اتصال در راستای سازگاری بیشتر و به نوعی برای بازتر گذاشتن دست برنامه نویسان اکسس به اون اضافه شده

موفق باشید

[ali190]

باسلام
باتشکر فراوان از راهنماییها و مطالب ارزنده جناب nabeel که همیشه با راهگشای سایر عزیزان هست.(ممنون و متشکر)
میخواستم بدونم با توجه به مسئله شبکه و همه گیر شدن اون در بسیاری از اداره جات آیا اساتید صلاح میدونن که برنامه نوشته شده توسط دوستان ، از طریق قابلیت ذاتی اکسس(database spliter) جهت استفاده سایر کاربران در شبکه (حداکثر 10 کاربر ) استفاده بشه؟
من یک سئوال دیگه هم داشتم اونم اینه که آیا استفاده از عکسها در فرم جهت زیباسازی و حرفه ای تر کردن کار و نیز تعداد خود فرمها و گزارشات ، جداول ، کوئریها و تعداد خط کد نوشته شده در برنامه میتواند منجر به سنگین شده برنامه شود ؟ یا نه اصولاً تعریفی که از سنگین شدن برنامه مطرح میشود مربوط میشود به تعداد رکوردهای ذخیره شده در جداول(منظورم اینه که یک برنامه ممکنه 30 تا جدول داشته باشه ولی در این 30 جدول 1000 رکورد ذخیره باشه و برعکس یک برنامه باشه 3 جدول داشته باشه و 1000 رکورد داشته باشه؟کدوم یک از این دوعامل بر هم مقدم تر است؟ تعداد آبجکت یا حجم رکورد)
اگر من خواستم فایلم رو در شبکه بذارم فایل front end من که بر روی سیستم یوزر ها میشینه از نظر حجم محدودیتی نداره(منظور همون سنگسن شدنه برنامه به لحاظ استفاده از عکسها هستش)آخه وقتی یه عکس 100 کیلوبایتی در فرم میذارین حجم برنامه یهو چند برابر میشه.
ممنونم از شما

[nabeel]

سلام

... صلاح میدونن که برنامه نوشته شده توسط دوستان ، از طریق قابلیت ذاتی اکسس(database spliter) جهت استفاده سایر کاربران در شبکه (حداکثر 10 کاربر ) استفاده بشه؟

ببنیند ali190 , سئوال شما با قطعیت امکان جوابگویی نداره
در مورد بانکی که توسط شما طراحی شده , نمیدونم ( از کم و کیفش اطلاع ندارم ) ولی در حالت کلی بله امکان پذیره و هیچ مشکلی نداره

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

آخه وقتی یه عکس 100 کیلوبایتی در فرم میذارین حجم برنامه یهو چند برابر میشه.

این که امکان پذیر نیست مگه اینکه حجم خود تصویره چند برابر فایل بوده باشه ! ضمناً گزینه Compact On Close رو فعال کنید

استفاده از عکسها در فرم جهت ....

اگر تصویر به صورت Embeded به برنامه اضافه بشه , شما با افزایش حجم مواجه میشید ولی در حالت Linked این امر رخ نمیده , استراتژی استفاده از این دو روش به خود طراح بستگی داره
در خصوص سنگین شدن , هر دو حالت تاثیر گذار هستن ولی سئوال شما چند پهلو هستش
شما ممکنه یه تصویر 5 کیلوبایتی به پس زمینه یه فرم اضافه کنید و از اون طرف هم یه فیلد OLE داشته باشید که در اون فرضاً تصویر یک کاربر رو با حجم 300 کیلوبایت به برنامه اضافه کنید و همین طور به صورت معکوس

ولی در مجموع , برتری فنی برنامه مقدم هستش بر ظاهر فریبنده

ظاهر جذاب تنها چند روز برای کاربر جالبه , ولی یک برنامه حتی زیبا ولی با عملکرد ضعیف به قطع سرنوشتی بهتر از Uninstall پیدا نمیکنه

و یک توصیه : دوست من داستان بالا رو نخوندید مگه , بنده ازتون خواستم که زیاد از این شاخه به اون شاخه نکنید , تنها زمان رو از دست میدید و بس .
برنامتون رو در نسخه یک با هسته ای قدرتمند ارائه کنید و بعدها در نسخه بعدی اون رو هم به قول معروف Face Lift کنید ( به هر حال باید دلیلی برای عرضه نسخه های بعدی وجود داشته باشه دیگه )

لطفاً در صورتی که ابهامی در خصوص سئوالهای مطرح شده داشتید موضوع رو در این تاپیک ادامه ندید و اجازه بدید موضوع حول موضوع اصلی بگرده

موفق باشید

[Ali_Fallah]

با تشکر از آقای پیروز مهر
فرض کنیم در جدولی در اکسس و SQL حدود 1000 رکورد داریم (دریک جدول حقوق و دستمزد) و میخواهیم
10 درصد به حقوق همه اضافه کنیم(بصورت مجزا در هر دو پایگاه داده)
کد مخصوص را نوشته و آن را اجرا می کنیم بعد از حدود 50 در صد از اجرای دستور , سیستم از کار می افتد
(به هر دلیل) حالا وضعیت بعد از اصلاح سیستم
در این دو پایگاه داده چگونه خواهد بود ؟

[nabeel]

سلام

فرض کنیم در جدولی در اکسس و SQL حدود 1000 رکورد ...

فرض رو بر این میذارم که سئوال رو در راستای همون تاپیک اصلی مطرح فرمودید و بعد از نظر بنده , شما هم اقدام به ارائه رویکرد در SQL Server میکنید

ولیکن در پاسخ :

سیستم از کار می افتد

نوع از کار افتادگی مهمه , ممکنه حتی تا حد از بین رفتن کامل فایل هم پیش رفته باشه ( در SQL Server هم به همین شکله , و قاعدتاً در کلیه فایلها )
برق میره , برنامه هنگ میکنه و خارج میشه و یا ....

در خصوص وضعیت اطلاعات ( با فرض سالم بودن فایل )
این موضوع به نحوه طراحی شما ربط داره
اگه فرضاً از یک Update Query استفاده کرده باشید , با توجه به اینکه این آبجکت پذیرای Interrupt نیست دچار مشکل میشید ولیکن اگر سیستم بر مبانی فرضاً DAO تبادلات رو انجام بده و شما روالها رو توسط کنترلهای لازم تحت مدیریت قرار بدید , هیچ مشکلی پیش نمیاد
به طور مثال در یک عملیات Transaction ( عملیات مورد نظر شما در این حیطه قرار میگیره ) میتونید با اتکا به BeginTrans و Commit Trans بر روی اینگونه عملیاتی کنترل لازم رو داشته باشید و در هنگام مواجه با خطاهای مدیریت شده هم با کمک Rollback اطلاعات رو به وضعیت قبلی خودشون برگردونید
البته به روشی مشابه همین عملیات هم در داخل SQL Server به انجام میرسه

منتظر اعلام نظر در خصوص نحوه اعمال این کار در SQL Server هستم

توضیح : بنده با SQL Sever کار میکنم و اطلاعاتی خیلی جزئی در این خصوص دارم , تنها میخوام اگر نظری در خصوص نقصان Access در مساله مطرح شده خودتون دارید عنوان بفرمایید .

البته نمیدونم , شاید من خوب متوجه نشدم و شما قصد مقایسه نداشتید و تنها قصدتون سئوال بوده , به هر حال چون این مبحث وارد مقوله آموزشی نخواهد شد , امیدوارم اشاره کلی کفایت لازم رو داشته باشه .

موفق باشید

[Ali_Fallah]

باتشکر از آقای پیروز مهر
البته قصد من مقایسه و آنهم قدرت مانور SQL در مقایسه با اکسس بود
و اینکه فکرکنم SQL برای کارهای بزرگ خصوصاً (برنامه هایی که تحت شبکه بوده و چند دیتا بیس با هم در ارتباط هستند) در نظر گرفته شده و برای پروژه های کوچک البته اکسس مناسبتر هست
و فکر کنم هدف مایکروسافت هم همین باشه
واما در SQL...
تقسیم یک دیتا بیس به چند فایل Data و Log و توزیع آن در جاهای مختلف هارد
افزایش و یا جلوگیری از افزایش حجم بانک به صورتهای مختلف
Back Up از بانک اطلاعاتی در زمان دلخواه
امنیت بالا در SQL !
جلوگیری از کپی یا حذف دیتا بیس در حالت Attach
عدم دسترسی مستقیم به دیتا بیس توسط کاربر
Data Type مختلف و متنوع
پذیرش و ذخیره رکورد به هر تعداد
ارتباط با سایر SQL Server ها در شبکه
عدم تخریب و خراب شدن فایل (همین جوری و بدون دلیل)
امکان گزارش گیری از اطلاعات در نسخه های جدید ( و احتمال بازنشستگی سایر برنامه ها نظیر کریستال رپورت و اکتیو رپورت و...)
--
و اما در اکسس
ضعف در امنیت و اینکه رمز عبور اون از Word وExcel هم راحتتر بدست میاد
Link یا Emport جداول و queri به راحتی آب خوردن
سنگین شدن برنامه در حجم بالا (منظور انجام عملیات و پردازش)
کپی دیتابیس توسط همه کاربرا
مشکل در استفاده از اکسس در شبکه برای تعداد کاربر زیاد (هر چند اکسس برای شبکه در نظر گرفته نشده)
--و اما مجدداً در SQL
1-سختی طراحی جداول و view ها و ایجاد ارتباط !!
2- تولید پیغامهای اعصاب خرد کن وپشت سرهم !!!
3-عدم وجود شی ء فرم و ... جهت استفاده کاربر (اصلاً برایش چنین چیزی ذاتاً تعریف نشده) برای راحتی برنامه نویس عین اکسس
و...
و اما مجدداً در اکسس
1- راحت بودن طراحی همه اشیاء در اکسس
2- وجود ماکرو برای کسانی که مبتدی هستند و کد نویسی بلد نیستند
3- وجود ماژول برای کسانیکه حرفه ای بوده و کد نویسی خیلی بلد هستند
4- امکان طراحی فرم و گزارش بصورت ویزارد برای کسانیکه بلد نیستند و یا مبتدی هستند
5- طراحی برنامه از ابتدا تا تکمیل آن در عرض یکروز و تحویل آن به مشتری (برنامه متوسط)
6- یادگیری اکسس و طراحی برنامه جهت برطرف کردن نیازها بمدت یک هفته
7- محبوب ترین پایگاه داده در دنیا(بخاطر راحتی کار با آن )
---
البته این مقایسه از نگاه یک کاربر و یک مشتاق یادگیری(مثل خودم) در شروع کارهست
وگرنه مقایسه علمی نیست

[nabeel]

ضمن سلام
در ابتدا یه مقدمه کوتاه و غیر مرتبط میام و بعد ادامه گفتگو
بنده بعد از یک عمر کار کردن , به معنای عامیانه اون دم لای تله نمیدم و توی هر تله ای هم نمیفتم ! و این مورد رو سعی میکنم توی ریز ترین بخش جوابم هم رعایت کنم , گاهاً با خلاصه گویی تا در صورتی که نیاز داشته باشه بعداً باز تر شه .

عنوان تاپیک اینه :

مقایسه Access و SQL Server !؟

جمله هم سئوالی هستش و هم تعجبی

یعنی در واقع در بطن کار موافق با مقایسه نیستم اونهم به دلایلی که خلاصه وار در تاپیک اول عرض کردم

این بخش رو عرض کردم تا کلیت نحوه پاسخگویی بنده رو دوستان متوجه بشن .

و لیکن نکته کلی دوم :

بنده در بعضی مباحث زیاد وارد نمیشم و جوابی هم به سئوالاتش نمیدم حتی اگه اطلاع داشته باشم
برخی دلایلش به شرح زیره :

سئوال خیلی کلیه و خارج از حوصله و یا سئوال خیلی فنی هستش و در واقع نمیشه با توجه به اینکه تنها یه کاربر این سئوال رو پرسیده , الزاماً جواب اون سئوال رو داد , این امر میتونه ناشی از رقابتی بودن نحوه حل اون مساله هم بوده باشه ( تمام گروههای نرم افزاری مشکلات رو به یک شکل حل نمیکنن , و همین امر دلیل تنوع محصولات و ایجاد سلایق متفاوت در انتخاب محصولات میشه که در نهایت منجر به فروش بهتر یک محصول میشه )

بنده شخصاً هم در راستای دادن ذکات هستم ( همون جمله معروف ذکات علم در .... )

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

دوست گرامی , جناب آقای فلاح ممنون از اینکه نظرات خودتون رو اعلام کردید , خیلی از اونها وارده و بعضی ها , به نظر بنده وارد نیست و دلایلم رو هم عرض خواهم کرد

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

امنیت بالا در SQL !
ضعف در امنیت و اینکه رمز عبور اون از Word وExcel هم راحتتر بدست میاد
Link یا Emport جداول و queri به راحتی آب خوردن
عدم دسترسی مستقیم به دیتا بیس توسط کاربر
عدم تخریب و خراب شدن فایل (همین جوری و بدون دلیل)

تمام این موارد رو در مقوله امنیت قرار میدم

واژه امنیت در حیطه نرم افزاری و خصوصاً دیتا بیس دارای چند شاخه هستش :
به طور مثال امنیت میتونه به معنای حفظ موجودیت کلی خود اطلاعات بوده باشه ( از بین نرفتنشون ) و یا به معنای حفظ صحت اطلاعات
در خصوص امنیت اطلاعات با توجه به اینکه در SQL Server لایه امنیتی دو گانه بوده ( بر مبانی امکانات امنیتی ویندوز NT و امکانات امنیتی خود SQL ) و به صورت یکپارچه و درون ساختاری هستش ( جزو موئلفه های داخلیشه ) در مقوله امنیت در جایگاهی جلوتر از اکسس قرار داره البته این به معنای نفی عدم امکان نفوذ نیست , نحوه نفوذ متفاوت و سخت تر از اکسس هستش ( همه گاو صندوقها با یه کلید باز نمیشن – شاه کلید یک داستانه , دستان سارق هنر اصلی رو به خرج میده )

ولی در مجموع چون بخشی ازاین امنیت هم بر مبنای گذر واژه ها پیاده سازی شده , دارای نقطه شکست هم هستش , نحوه حملات به این دو در بخشایی مشابه و در بخشهایی متفاوته ولی در مجموع هر دو قابل نفوذ هستند
ولیکن در اکسس هم این مقوله رویکردی دو وجهی , هم به امکانات داخلی خود اکسس داره و هم نحوه طراحی برنامه نویس

نگاهی به اون بندازیم :

در اکسس 2007 داستان شکسته شدن رمز عبور اونهم به سادگی به فراموشی سپرده شده , الگوریتم مورد استفاده در این بخش به تلفیق SHA1 و AES سپرده شده , ترکیبی قدرتمند که جانشین الگوریتم ضعیف قبلی شده
توضیحات بیشتر در مقاله ای با عنوان ایمنی بیشتر در Access 2007 نوشته شده در 25 اردیبهشت 88

البته این تغییر و فعال سازی اون , محدودیتهایی رو در زمینه برنامه نویسی ایجاد میکنه , از جمله اینکه شما باید از تکنیک ADOX جهت اتصال به این نوع از دیتا بیس استفاده کنید .

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

در خصوص دسترسی مستقیم به دیتا بیس , من نمیتونم این مورد رو ایراد اکسس بدونم , این مورد دقیقاً حکایت از عدم توانایی طراح در خصوص نحوه جلوگیری از این امر داره
البته بسیاری رویکردهای امنیتی اکسس بر مبانی برنامه نویسی بوده ( رابطه تنگاتنگی با این امر دارن ) و نیاز به استفاده از یکی از تکنیکهای اتصال دارن همچون َADO,DAO,ODBC,ADOX,… و بر مبنای تکنیکها و آبجکتهای رایج ( همچون جداول و پرس و جوها ) به سادگی و با اطمینان خاطر کامل قابل اعمال نیستن
به طور مثال شما در صورتی که به صورت مستقیم در داخل یک فرم به یک Query و یا جدول متصل میشید , در واقع دارید به گونه ای امنیت اطلاعات رو هم به چالش میکشید , البته در این حالت هم با استفاده از رمز نگاری اطلاعات و خارج کردن اونها از حالت رمز نگاری میشه به نتایجی دست پیدا کرد که ماحصل اون کاهش سرعت به همراه ارتقاء مطلوب امنیت اطلاعات بوده باشه
در رابطه با تخریب فایل در اکسس , سلسله مطالبی که در بخش اعلانات این تالار درج شده رو اگر مطالعه نفرمودید , مطالعه بفرمایید " راههای جلوگیری از تخریب فایلهای Access"
در این خصوص هم , با شما موافقم از این جهت که اکسس پتانسیل تخریب شدن بالاتری نسبت به SQL ُServer داره ولی در ضمن مخالف هم , هستم که اکسس :

همین جوری و بدون دلیل ..

... هم این اقدامات رو انجام نمیده

شما در اکسس با یک محیط یکپارچه مواجهید که مجموعه ای از تمامی انواع آبجکتهاست و نه فقط یک دیتابیس محض
جهت مثال دیداری واضحتر , در علم مکانیک یک رابطه معکوس , بین پیچیدگی ( به معنای خاص اون تعدد قطعات ) و خرابی وجود داره , نمونه واضح این مقایسه یک موتور گازوئیلی ( متاسفانه در اینجا این نقش رو باید SQL Server بازی کنه ) و یک موتور بنزینی ( در اینجا اکسس ) , هستش
همه میدونید که یکی از دلایل خرابی پایین تر موتورهای گازوئیلی عدم وجود پیچیدگی در نقاط کلیدی اون هستش ( علاوه بر دلایل دیگه , اگر کسی خواست برای توضیح بیشتر در خدمتشون هستم – برآیند کلی مثال مطلب مورد نظر بنده رو القاء خواهد کرد )
به نوعی در گذشته به همین موارد هم , با جملاتی ولیکن با انشا متفاوت اشاره شده بود از جمله اینکه تعدد آبجکتها میتونه منجر به افزایش احتمال تخریب بشه و یا مقاله ای همچون : مروری کوتاه بر دلایل استفاده از Atcive'X ها درج شده در 27 فروردین 88
و بسیاری مسائل دیگه که امیدوارم که یا خودتون هم بررسی کنید و یا اینکه دیگر دوستان صاحب نظر هم بیان و مشارکت کنن و فقط بنده متکلم وجده نباشم ( و در صدد تلقین تفکرات خودم که احتمال اشتباه بودنشون هم به قطع صفر نیست , بر نیام )
این در خصوص بخشی از مساله امنیت

چند موردی که اصلا دقیقاً متوجه نشدم که منظورتون چیه ( و به همین دلیل هم جواب نمیدم – رجوع شود به داستان دم لای تله ! ) :

ارتباط با سایر SQL Server ها در شبکه
امکان گزارش گیری از اطلاعات در نسخه های جدید ( و احتمال بازنشستگی سایر برنامه ها نظیر کریستال رپورت و اکتیو رپورت و...)
- تولید پیغامهای اعصاب خرد کن وپشت سرهم !!!
سختی طراحی جداول و view ها و ایجاد ارتباط !!

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

در تاپیک اول اشاره کردم که بسیاری از موارد که اونها رو نقصان مینامیم و یا برتری , این موارد نباید مطرح بشه و اصلاً جایگاهی نداره .

مثلاً :

-عدم وجود شی ء فرم و ... جهت استفاده کاربر (اصلاً برایش چنین چیزی ذاتاً تعریف نشده) برای راحتی برنامه نویس عین اکسس

با این اوصاف کم کم باید مایکروسافت به دنبال ترویج نامی دیگه برای SQL Server باشه مثلاً Access – Ultimate و یا یک چیزی مشابه اون
بنده اسم این رو نقصان SQL Server نمیذارم , اینجوری باشه بنز الگانس هم در مقابل یه هواپیمای ملخی , ناقصه , چرا که اولی نمیتونه پرواز کنه ولی دومی میتونه ! ( به این کار فعلی بنده میگن سفسطه ! که کار درستی هم نیست ! و نباید انجام داده بشه )
اگر کسی به دنبال پروازه , که دیگه مقایسه لازم نیست , یه گزینه دارید اون هم یک هواپیمای ملخی , سوارش بشید و ....
ایجاد مرز در بین حیط عملکردی این دو الزامیه
اگر بخوایم وارد ریز بشیم که باید به قول داریوش , سور عزای SQL رو باید به جشن بشینیم !
تنوع امکانات موجود در اکسس در حدی هست که مقایسه SQL Server با اکسس در اون بخشها به حق نیست در واقع نباید مقایسه این در بخش به انجام برسه که به ناحق به یکی از این دو امتیازی منفی داده بشه ( مثل همین مورد نداشتن فرم در SQL Server )
باز هم تاکید میکنم مطالب تاپیک یک با دقت بیشتری مطالعه بشه , تا احیاناً منظور بنده به اشتباه تداعی نشده باشه
ولیکن یک توضیح در خصوص اینکه , هر سخن جایی و هر نکته مکانی دارد :

ببینید , در همین اول اکسس رو به عنوان یک محیط توسعه کامل فرض کنید ( جدا از همه نقصانهایی که در ذهن شماست , که اگر این کار رو هم میتونست انجام بده , چقدر خوب میشد )
اکسس تمامی ابزارهای توسعه رو در یکجا جمع کرده
ولیکن در بسیاری محیطهای توسعه دیگه مطلب بدین گونه نیست
در اینجا به نزدیکترین محیط توسعه که نسبت خانوادگی بسیار خوبی هم با Access داره اشاره میکنم
Visual Basic در واقع یک محیط برنامه نویسی رو با مشخصه های خاص خودش در اختیار شما قرار میده
این زبان برنامه نویسی نیز همچون تمامی زبانهای برنامه نویسی دیگه دارای نقائصی هستش که البته این نقائص شاید بشه گفت که عمداً از سوی خود تولید کننده در اون گنجانده شده تا بتونه تنوع و فروش دیگر محصولات خودش رو هم بالا ببره
VB یکی از بهترین محیطهای توسعه جهت Application ها هستش , شما به کمک این زبان برنامه نویسی میشه گفت قادر به انجام هر کار در مقوله نرم افزاری هستید ( در برخی مقوله ها هم که کمتر در حیطه عملیاتیش مورد نیاز بوده , نقصانهایی هم داره )
از طراحی ماشین حساب ساده گرفته تا نوشتن یک سیستم حسابداری بسیار کامل توسط VB امکان پذیره
ولی در این میان نقیصه ای بارز وجود داره , و اون هم اینکه Visual Basic قاعدتاً جهت طراحی نمای کاربر یعنی اون بخشی که شما در حال کار با اون هستید , به کار میره و فاقد امکانی قابل توجه جهت ذخیره سازی اطلاعات در قالبی که ما به اون دیتابیس میگیم هستش
در این حالت باید دست به دامان یکی از دیتا بیس ها بشیم که در اینجا بحث بر سر اکسس و SQL Sever به نمایندگی از این طیف هستش ( یه توضیح بدم که البته خود SQL Server هم اونطوری نیست که قدرت بلامنازع باشه بلکه در اون حیطه هم در مقابل رقبای هم مسلک خودش جزو نمونه های پیش و پا افتاده به نظر میاد ! که در بسیاری مقایسه ها همینطوری که طرفداری SQL Server در مقام مقایسه با اکسس میگن که : SQL Server اکسس رو له میکنه ! اونها هم با فرغون از روی SQL Server رد میشن !!! و آخرش هم روش یه ماله میکشن ! این تیکه رو گفتم که یه SQL Server کار زیاد هم خوشحال نباشه و خلاصه در محافل لهو و لعب سینه ندن جلو و شکمشون رو تو .... دوستان SQL Server کار میدونن دارم در مورد کدوم یکیش حرف میزنم )
برگردیم سر اصل موضوع :
Visual Basic فاقد بسیاری از رویدادهای مرتبط با Database هستش ( بر خلاف اکسس ) از این رو این نقیصه و رفع بخشی از اون به SQL Server محول شده ( به طور مثال بحث Trigger ها )
در تاپیک یک هم عرض کرده بودم که :

روش حل مساله در اکسس به گونه ای دیگه هستش ( فراموش نکنید Access یک IDE هستش ) ، و در واقع دقیقاً اون قابلیت با توجه به نقصان موجود در SQL Server و یا IDE مربوطه ، به گونه ای متناسب با حال و هوای خود اونها طراحی شدن که حالا جالبه به عنوان نقطه قوت مطرح میشن !؟

توضیحی که در بالا دادم مرتبط با همین موضوعه

مطلب داره بی دلیل طولانی میشه


توضیحات پایانی :
متاسفانه قادر به کمک در زمینه ارائه توضیحات کامل در خصوص بسیاری مطالب مطرح شده فوق نیستم ( رجوع شود به بحث شیرین خمس و ذکات علم و دانش !! بسه دیگه امشب خیی شیرینی پخش کردیم الان یه سری فکر میکنن بابت 22 بهمنه ! و کار میدن دستمون , یک ساعتی هست دارم مینویسم و شیرینی درست میکنم که پخش کنم )

بنده فقط نظرات خودم رو دادم , و الزامی در صحتشون نیست

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

خدانگهدار
موفق باشید

[vaezhasan]

با سلام.
خدمت دوستان عزيز.
در جواب همه دوستان بايد بگم كه اينقدر از دست MS ACCESS عصباني هستم كه ....
به نظر من اگه بانك اطلاعاتي شما غير از فيلد متني يا عددي فيلدي نداره از MS ACCESS استفاده كنيد ولي بايد مطمئن باشيدكه حجمش از 2GB بالاتر نميره. ولي اگه غير از اينه كه به نظر من برنامه نويسان روزي به فيلدهاي OBJ مثل تصوير هم نياز دارند چه بهتر كه از همون ابتدا انرژي بيشتري بذاريد و از يك بانك اطلاعاتي غير از اكسس استفاده كنيد.