بگذار با یک مثال این مسئله رو پیگیری کنیم تا ببینیم دو حالت استفاده از فایل تصویر و فیلد تصویر چه مزایا یا معایبی دارند.
فرض کن بانکی داریم که حاوی اطلاعات فنی قطعات موجود در هواپیماهای مختلف هست. در این بانک علاوه بر مشخصات فنی قطعات٬ نقشههای فنی هر قطعه هم وجود داره.
تو یک هواپیما گاهی تعداد قطعات به میلیونها قطعه میرسه. حالا ما فرض میکنیم که بطور متوسط در هر هواپیما ده هزار قطعه مختلف وجود داره. همچنین برای هر قطعه با احتساب اصلاحات و بازنگریها تعداد نقشهها ممکنه از صد تا هم تجاوز کنه. حالا این رو هم ما بطور متوسط میگیریم پنجاه تا. تعداد هواپیماهای مختلف رو هم میگیریم بیست تا.
با این فرضیات٬ بطور متوسط تعداد نقشههای موجود در بانک میشه:
10,000 * 50 * 20 = 10,000,000
اگر نقشهها رو بصورت فایل داشته باشیم باید تعداد ده میلیون نقشه رو تو File System قرار بدیم. یعنی ده میلیون مشخصه اضافی شامل نام فایل٬ تاریخ ایجاد٬ تاریخ اصلاح٬ تاریخ دستیابی ٬ خصوصیات٬ سطح دسترسی٬ و غیره. با فرض اینکه برای هر فایل این مشخصات تنها پنجاه بایت رو اشغال کنند٬ کل حجم اشغال شده و بیمصرف برای ما عبارت است از:
10,000,000 * 50 Bytes = 500,000,000 Bytes ~ 0.5 GB
جدا از این هیچ سیستم عاملی دارای یک چنین File System پیشرفتهای نیست که قادر باشه این تعدا فایل رو مدیریت کنه. حتی با داشتن تعداد چند هزار فایل در یک دایرکتوری٬ زمان مورد نیاز برای دستیابی به فایلها به شدت افزایش پیدا میکنه.
حال اگر اندازه هر نقشه رو بطور متوسط صد کیلو بایت بگیریم، اندازه کل نقشهها میشه:
10,000,000 * 100 KB = 1,000,000,000 KB ~ 1,000,000 MB ~ 1,000 GB ~ 1 TB
باز هم هیچ File System پیشرفتهای موجود نیست که بتونه چنین حجمی از اطلاعات رو بر روی خودش جای بده. در صورتیکه بانکهای اطلاعاتی میتونند بخشهای مختلف یک بانک اطلاعاتی رو روی پارتیشنها و حتی کامپیوترهای مختلف قرار بدند.
علاوه بر این وقتی که نقشهها بر روی فایل قرار داشته باشند٬ ابتدا باید نام فایل رو از بانک اطلاعاتی بازیابی کنیم و دوباره یک بار دیگه یک جستجو در دایرکتوری (که توسط File System انجام میشه) بکنیم تا بتونیم تصویر رو تو حافظه بخونیم. اگر تصویر در بانک اطلاعاتی قرار داشته باشه تنها به یک بار بازیابی نیاز هست نه دو بار.
---------------------------------
حالا فرض رو بر این بگذاریم که یک File System معرکه داریم که هیچکدوم از مشکلات بالا رو نداره. خوب٬ دیگه چه مشکلی ممکنه پیش بیاد؟
تصمیم گرفته میشه که برنامه روی شبکه (محلی یا اینترنت) قرار بگیره. اگر نقشهها رو بصورت فایل داشته باشیم دست کم تو بانک اطلاعاتی باید نام تمام فایلها رو تغییر بدیم و نام ماشین رو هم بهش اضافه کنیم.
حالا میگیم دو خط برنامه کار تغییر فیلد نام فایل رو انجام میده. اما مشکل اصلی چیز دیگه هست: برنامههای Client باید به فایلها دسترسی مستقیم داشته باشند و اگر قرار بر اینه که رکوردی رو اضافه و اصلاح هم بکنند٬ به دسترسی نوشتنی نیاز دارند. به عبارتی یا باید یک دایرکتوری رو تو شبکه در اختیار همه قرار داد و به همه هم اعتماد کرد که دستی فایلی رو حذف نکنند یا تغییر نام ندن٬ یا اینکه برنامه رو انداخت دور. حتی اگر تو مدینه فاضله باشیم و به همه هم بشه اعتماد کرد باز باید یک فکری برای Lock کردن فایلها بکنیم تا اگر چند نفر با هم همزمان خواستند نقشهای رو تغییر بدن مشکلی ایجاد نشه.
اگر فایلها در بانک اطلاعاتی ذخیره شده بود چه مشکلی پیش میآمد و چه تغییری نیاز بود؟ واقعا" هیچی.
باز فرض میکنیم که شبکهای در کار نیست و این مشکل بالا هیچوقت برامون پیش نمیاد. یک داستان دیگه: کارفرما تصمیم میگیره که قطعات مربوط به یک هواپیما رو فوق سری اعلام کنه و از این به بعد فقط گروهی از کاربران میتونند به این اطلاعات محرمانه دسترسی داشته باشند. اگر تصاویر در بانک اطلاعاتی بودند تنها با گرفتن دسترسی از بقیه کاربران مشکل حل بود٬ ولی برای تصاویری که در فایل هستند باید برنامه رو تغییر داد و کلی کار کرد تا شاید به نتیجه دلخواه رسید. در نظر داشته باش که در این حالت باید یک بار برای بانک اطلاعاتی سطح دسترسیها رو مشخص کرد و یک بار هم برای File System.
باز اگر فرض رو بر این بگذاریم که هیچوقت مشکل بالا پیش نمیاد٬ هنوز یک مشکل دیگه پیش رومون هست که هیچ ارتباطی هم به کارفرما نداره. مشکل قضا و قدر! هین کار برق میره یا کامپیوتر خراب میشه. حالتی رو در نظر بگیر که اطلاعات مربوط به یک قطعه رو وارد کردیم و یک سری از نقشههای مربوطه رو هم اصلاح و در دایرکتوری ذخیره کردیم٬ اما قبل از (Commit) ثبت شدن بقیه اطلاعات برق میره. اطلاعات اون رکورد قدیمه اما برخی نقشهها به روز شدهاند. با این وضعیت به اطلاعات موجود در بانک اطلاعاتی نمیشه صد در صد اعتماد داشت.
اگر بانک اطلاعاتی از ارتباط موجود بین تک تک اطلاعات (شامل نقشهها) خبر داشت٬ کل اطلاعات رو یکجا ثبت میکرد و اگر در هین کار مشکلی پیش میامد٬ کل اطلاعات مرتبط به هم و هر چند قدیمی رو (Roll Back) برمیگردوند. نصفه نیمه بروز شدن برخی اطلاعات برای ارتباطات Master/Detail پیچیده ممکنه اصلا" قابل تشخیص نباشه.
---------------------------------
در قسمت اول صحبتم دلایلی از بهینه بودن (حجم و سرعت) استفاده از فیلد تصویر به جای فایل تصویر رو گفتم و در ادامه هم برخی مزایای در نظر گرفتن یکپارچگی و روابط بین اطلاعات رو در نگهداری و توسعه یک سیستم اطلاعاتی. امیدوارم با این مثالها چراها بیجواب نمونده باشند.