ما یک دایرکتوری "محصولات" داریم که در ویژگی "داده" اطلاعات آن به شکل داده های باینری ذخیره می شود. خود ویژگی دارای نوع مقدار "Value Storage" است. تصویر زیر ساختار ابرداده دایرکتوری را نشان می دهد.
برای پیوست کردن یک فایل دلخواه از دیسک در قالب یک عنصر، دستور "AttachFile" پیاده سازی شده است. کد برنامه آن در لیست زیر ارائه شده است:
& در رویه کلاینت AttachFile (فرمان) // کنترل کننده فرمان روی کلاینت. انتخاب فایل // گفتگو برای انتخاب فایل از دیسکحالت = FileSelectionDialogMode. افتتاح؛ OpenFileDialog = NewFileSelectDialog(Mode); گفتگوی OpenFile. FullFileName = " " ; گفتگوی OpenFile. MultipleSelect = False ; گفتگوی OpenFile. Title = "انتخاب فایل ها" ; اگر FileOpenDialog. () سپس FilePath = FileOpenDialog را انتخاب کنید. FullFileName; // داده های فایل باینری را دریافت کنید BinaryData = BinaryData جدید (PathToFile) ; // انتقال داده های باینری به سرور AttachFileServer (BinaryData) ; در غیر این صورت متن = "ru = " " فایل (ها) انتخاب نشده است!" " ; en =" " فایل (ها) انتخاب نشده است!" " " ; Warning(NStr(Text) ) ; EndIf ; EndProcedure & OnServer Procedure AttachFileServer(BinaryData) // هندلر روی سرور برای ضبط یک فایل در امنیت اطلاعات // شی فرم را به یک شی مرجع تبدیل کنید ObjectCurrent = FormAttributesValue("Object") ; // یک مقدار جدید به ویژگی "Data" اختصاص دهید ObjectCurrent. داده = NewValueStorage(BinaryData) ; // ذخیره تغییرات ObjectCurrent. نوشتن() ؛ پایان رویهاگر الگوریتم را به صورت کلی توصیف کنیم، ابتدا یک فایل از دیسک روی کلاینت انتخاب می شود. داده های فایل باینری حاصل به سرور ارسال می شود، جایی که در پایگاه اطلاعات، یعنی در ویژگی "داده" عنصر دایرکتوری فعلی ثبت می شود.
در اصل، همه چیز کار می کند. هنگام باز کردن یک عنصر، می توانیم این داده ها را در صورت نیاز بخوانیم. به عنوان مثال، اگر یک تصویر در props ذخیره شده باشد، می توانیم آن را دریافت کرده و در قسمت فرم نمایش دهیم. این راه حل جای خود را دارد، اما در اکثر وظایف استفاده از ویژگی هایی با نوع مقدار "Value Storage" در فهرست ها و اسناد بهینه نیست. و به همین دلیل...
بیایید چند تست عملکرد را اجرا کنیم. آزمون‌ها از دو عنصر دایرکتوری «محصولات» با و بدون فایل پیوست استفاده می‌کنند. حجم فایل پیوست 5 مگابایت می باشد.
تمام تست ها با استفاده از پردازش "GetElement" در پیکربندی تست انجام می شود. می توانید این تنظیمات را از لینک انتهای مقاله دانلود کنید.
بیایید زمان لازم برای باز کردن موارد در فهرست "محصولات" را اندازه گیری کنیم. برای باز کردن یک عنصر، از روش زمینه جهانی "OpenValue()" استفاده می شود که به عنوان یک پارامتر مرجع به عنصر ارسال می شود. بیایید زمان باز شدن را با استفاده از یک ابزار اندازه گیری عملکرد استاندارد اندازه گیری کنیم. نتایج در تصویر زیر ارائه شده است:
همانطور که می بینیم، مدت زمان باز کردن یک عنصر با یک فایل پیوست 10 برابر بیشتر است! بیایید یک آزمایش دیگر انجام دهیم. بیایید روش "GetObject()" را برای ارجاع به عنصر کاتالوگ محصول اجرا کنیم. در تصویر زیر می توانید نتیجه آزمایش را مشاهده کنید.
تفاوت کاملا قابل توجه است. دریافت یک عنصر بدون فایل پیوست 194 برابر سریعتر است!
این به این دلیل اتفاق می‌افتد که متد «GetObject()» تمام داده‌ها را از جزئیات عنصر دایرکتوری با مرجع دریافت می‌کند. بر این اساس، روش نه تنها مقادیر ویژگی های "Code" و "Name"، بلکه مقدار ویژگی "Data" را نیز دریافت می کند. اگر داده های باینری به اندازه 5 مگابایت (مانند مثال ما) را ذخیره می کند، پس از دریافت شی، این داده ها در رم(مانند سایر جزئیات) و سپس به سمت مشتری منتقل می شود. دریافت داده از این ویژگی است که زمان به دست آوردن شی عنصر را افزایش می دهد. اگر از یک کانال ارتباطی نازک استفاده شود، به دلیل انتقال حجم زیادی از اطلاعات از طریق شبکه، زمان باز شدن به میزان قابل توجهی افزایش می یابد.
نکته: هنگام اجرای متد "OpenValue()" شی عنصر دایرکتوری نیز ابتدا به دست می آید و سپس به یک شی فرم تبدیل می شود و به مشتری ارسال می شود (برای فرم های مدیریت شده). یعنی وقتی یک عنصر با مرجع باز می شود، شی نیز بازیابی می شود.
بیایید آزمایش نهایی را در مورد زمان باز کردن و نوشتن یک مورد دایرکتوری با و بدون فایل پیوست انجام دهیم. نتیجه در تصویر زیر نشان داده شده است.
نتیجه طبیعی زمان دریافت و سپس نوشتن برای یک آیتم دایرکتوری با یک فایل پیوست شده 19 برابر بیشتر است. همانطور که در بالا ذکر شد، هنگام دریافت یک شی، مقادیر تمام جزئیات آن، از جمله ویژگی "داده" که در آن 5 مگابایت اطلاعات ذخیره می شود، به دست می آید. هنگامی که یک عنصر نوشته می شود، این مقدار داده دوباره در پایگاه اطلاعاتی نوشته می شود. در نتیجه، ذخیره داده‌ها در یک ویژگی دایرکتوری (یا سند) با نوع «ذخیرهسازی ارزش» بر عملکرد هم هنگام بازیابی یک شی و هم هنگام قرار دادن آن در پایگاه اطلاعات تأثیر منفی می‌گذارد.
صحیح ترین روش برای حل مشکل ذخیره سازی داده ها برای اشیاء پایگاه اطلاعات چیست؟
اگر به اجرای این مکانیزم در تنظیمات معمولی نگاه کنیم، خواهیم دید که برای اشیا اطلاعات اضافی در یک جدول ثبت اطلاعات جداگانه ذخیره می شود. به عنوان مثال، مکانیزم فایل پیوست در پیکربندی استاندارد «مدیریت تجارت» نسخه 11 به این شکل است.
دایرکتوری "Nomenclature" مالک دایرکتوری "NomenclatureAttachedFiles" است. این به نوبه خود با ثبت اطلاعات AttachedFiles مرتبط است که بعد AttachedFile به عنصر آن اشاره دارد. بنابراین، داده های متصل به اشیاء پایگاه اطلاعات در واقع در جدول ثبت اطلاعات ذخیره می شوند، که عملکرد آن عملاً تحت تأثیر میزان داده های ذخیره شده در منبع قرار نمی گیرد. دایرکتوری میانی «نام‌گذاری فایل‌های پیوست» برای ذخیره اطلاعات اضافی برای فایل پیوست و همچنین برای پشتیبانی از دسترسی به فایل پیوست با مرجع ضروری است.
همه موارد فوق یک بار دیگر تأثیر عملکرد عظیم یک ساختار فراداده پیکربندی به درستی طراحی شده را تأیید می کند.
پیکربندی تست با مثالی از مقاله: ارتباط دادن .
// در این مکان همه چیز را نمایش می دهد... Form Elements.PictureField1.Picture = Storage.Get(); CurrentImage.Write();
TabDoc=New TabularDocument; TabDoc.Output(FormElements.TabularDocumentField1); Storage=NewValueStorage(TabDoc); نوشتن()؛
پایان رویه
Procedure RestoreFromStoragePress(Element)
TabDoc=Storage.Get(); اگر TabDoc<>Undefined ThenFormElements.TabularDocumentField1.Output(TabDoc); endIf;
پایان رویه
Eight از فشرده سازی داده های قرار داده شده در ذخیره سازی پشتیبانی می کند:
CompressionRate = NewDataCompression(9); //9 حداکثر PropsStorageType = New StorageValues(New BinaryData("c:\reports\report.epf", Compression Rate));
پایان رویه
Procedure StartProcessingFromStorage(PropsStorageType)
TemporaryFileName = TemporaryFileDirectory()+"report.epf"; BinaryData = PropsStorageType.Get(); BinaryData.Write(TemporaryFileName); ExternalProcessing = ExternalProcessing.Create(TemporaryFileName); ExternalProcessing.GetForm().Open();
پایان رویه
اگر داده‌های باینری بود، می‌توان آن را با استفاده از متد Get از ذخیرهسازی مقدار بازیابی کرد و با استفاده از متد Write() در یک فایل نوشت.
BinaryData = Storage.Get();
BinaryData = ذخیره سازی;
endIf; BinaryData.Write(FileName);
اگر به عنوان مثال، یک سند Word (فایل doc یا نوع فایل ثبت شده دیگر) بود، می توان آن را به صورت زیر باز کرد:
برای پاک کردن یک فیلد از نوع Value Storage، باید آن را Undefined اختصاص دهید:
برنامه مدیریت شده مکانیزم جدیدی را برای کار با فایل ها پیاده سازی می کند. تبادل فایل بین infobase و برنامه مشتری را فراهم می کند. ویژگی این مکانیسم این است که برای استفاده در تین کلاینت و کلاینت وب طراحی شده است و با در نظر گرفتن محدودیت های کار با فایل های اعمال شده توسط مرورگرهای وب طراحی شده است.
مکانیزم مجموعه ای از روش هاست که می تواند برای قرار دادن داده های ذخیره شده به صورت محلی در رایانه کاربر در یک ذخیره سازی موقت پایگاه اطلاعاتی، انتقال این اطلاعات از ذخیره سازی موقت به پایگاه داده و دریافت مجدد آن به رایانه کاربر استفاده شود. رایج ترین مشکلات کاربردی که توسط این مکانیسم حل می شود، ذخیره سازی اطلاعات همراه، به عنوان مثال، تصاویر کالا، اسناد مربوط به قراردادها و غیره است.
ذخیره سازی موقت یک منطقه تخصصی از پایگاه اطلاعاتی است که داده های باینری را می توان در آن قرار داد. هدف اصلی ذخیره سازی موقت اطلاعات در طول تعامل مشتری و سرور قبل از انتقال به پایگاه داده است.
نیاز به ذخیره سازی موقت به این دلیل است که مدل عامل مرورگر وب مستلزم آن است که فایل انتخاب شده توسط کاربر مستقیماً بدون امکان ذخیره آن در مشتری به سرور منتقل شود. هنگامی که یک فایل منتقل می شود، در ذخیره سازی موقت قرار می گیرد و سپس می تواند هنگام نوشتن یک شی در پایگاه داده استفاده شود.
معمولی‌ترین کار کاربردی که با ذخیرهسازی موقت حل می‌شود، فراهم کردن دسترسی به فایل‌ها یا تصاویر قبل از ثبت شی در پایگاه اطلاعاتی، به عنوان مثال، در قالب یک عنصر است.
یک فایل یا داده باینری که در فضای ذخیره سازی قرار می گیرد با یک آدرس منحصر به فرد شناسایی می شود که بعداً می تواند در عملیات نوشتن، خواندن یا حذف استفاده شود. این آدرس با روش هایی برای نوشتن یک فایل در ذخیره سازی موقت داده می شود. یک روش جداگانه در زبان داخلی به شما امکان می دهد تعیین کنید که آیا آدرس ارسال شده آدرسی است که به داده های موجود در ذخیره سازی موقت اشاره دارد یا خیر.
این مکانیسم به شما امکان می دهد به داده های باینری ذخیره شده در ویژگی های نوع Value Storage دسترسی داشته باشید.
همانطور که در مورد ذخیره سازی موقت، دسترسی به اطلاعات از طریق یک آدرس خاص امکان پذیر است. می توانید آن را از طریق یک روش خاص با ارسال پیوند به یک شی یا یک کلید ورود ثبت اطلاعات و نام ویژگی دریافت کنید. در مورد قسمت جدولی، علاوه بر این لازم است که نمایه ردیف قسمت جدولی را منتقل کنید.
روش‌های کار با فایل‌ها هنگام کار با جزئیات پایگاه اطلاعاتی محدودیت‌هایی دارند. برای آنها، بر خلاف ذخیره سازی موقت، فقط خواندن اطلاعات در دسترس است، اما نه نوشتن یا حذف آن.
معمولی ترین سناریو برای استفاده از این مکانیسم شامل قرار دادن ابتدا داده های کاربر در ذخیره سازی موقت است. دو روش برای این کار وجود دارد: PlaceFile() و PlaceFileInTemporaryStorage().
روش اول، PlaceFile()، یک فایل را از سیستم فایل محلی در ذخیره سازی موقت قرار می دهد. این روش می تواند یک آدرس هدف را در فضای ذخیره سازی بپذیرد. اگر تعریف نشده باشد یا یک رشته خالی باشد، یک فایل جدید ایجاد می شود و متد آدرس آن را از طریق پارامتر مربوطه برمی گرداند.
اگر پارامتری که حالت تعاملی عملکرد را تعیین می کند True باشد، روش یک کادر محاوره ای استاندارد انتخاب فایل را نمایش می دهد که در آن می توانید فایلی را برای قرار دادن در ذخیره سازی انتخاب کنید. در این صورت متد آدرس فایل انتخاب شده را نیز برمی گرداند.
در نتیجه، اگر کاربر به طور تعاملی از انجام عملیات در گفتگوی انتخاب فایل امتناع کند، روش False را برمی گرداند. این روش فقط برای مشتری موجود است.
روش دوم، PlaceFileInTemporaryStorage()، مشابه روش قبلی است، با این تفاوت که در سرور موجود است و داده هایی که باید در ذخیره سازی موقت نوشته شوند نه به عنوان یک مسیر در سیستم فایل، بلکه به عنوان یک متغیر از نوع نشان داده می شوند. باینری دیتا. به همین ترتیب، اگر آدرس هدف مشخص نشده باشد، یک فایل جدید در حافظه ایجاد می شود. آدرس آن به عنوان نتیجه تابع برگردانده می شود.
هنگام نوشتن یک شی در پایگاه اطلاعاتی، ممکن است لازم باشد داده ها را از ذخیره سازی موقت استخراج کنید و آن را برای مثال در یک ویژگی قرار دهید. یک روش سرور مربوطه برای این وجود دارد - GetFileFromTemporaryStorage(). این روش داده ها را از ذخیره سازی موقت بازیابی می کند و در نتیجه آن را برمی گرداند. برای انجام این کار، باید آدرس را در حافظه موقت مشخص کنید. اگر با موفقیت اجرا شوند، این آدرس با روش های توضیح داده شده در بالا ()PlaceFile و ()PlaceFileInTemporaryStorage بازگردانده می شود.
پس از ذخیره اطلاعات در جزئیات، فایل موجود در ذخیره سازی موقت را می توان حذف کرد. برای این منظور، یک روش DeleteFileFromTemporaryStorage () وجود دارد که یک فایل را از ذخیره سازی موقت حذف می کند. این روش آدرس یک فایل در ذخیره سازی موقت را به عنوان پارامتر می گیرد. در سرور موجود است.
آدرس فایل می‌تواند هم ذخیرهسازی موقت و هم جزئیات را در پایگاه اطلاعاتی نشان دهد. برای بررسی نوع آن، یک روش This isTemporaryStorageAddress() وجود دارد.
بررسی می کند که آدرس ارسال شده آدرسی است که به فروشگاه اشاره دارد. اگر آدرس به حافظه موقت اشاره داشته باشد، True را برمی‌گرداند. این روش در سرور موجود است.
پس از قرار دادن داده ها در جزئیات در پایگاه اطلاعاتی، ممکن است لازم باشد با استفاده از روش های فایل به آن دسترسی داشته باشید.
اما قبل از دریافت داده ها، مثلاً از یک ملک، باید آدرس این ویژگی را دریافت کنید. برای این منظور، یک متد GetFileAddressInInformationBase () وجود دارد.
هدف آن برگرداندن آدرس فایل در پایگاه اطلاعاتی مطابق با پارامترهای اصلی است. برای انجام این کار، باید کلید شی (این می تواند یک پیوند به شی یا یک کلید ورود ثبت اطلاعات باشد) و نام ویژگی را ارسال کنید. اگر باید آدرس یک فایل ذخیره شده در یک ویژگی بخش جدولی را دریافت کنید، قبل از نام ویژگی در پارامتری که نام ویژگی را مشخص می کند، باید نام قسمت جدولی و یک نقطه "." را اضافه کنید. این روش هم در کلاینت و هم در سرور در دسترس است.
متد GetFile() یک فایل را از infobase دریافت می کند و آن را در محلی ذخیره می کند سیستم فایلکاربر. پارامتر اول آدرس فایل را در props یا ذخیره سازی موقت فایل مشخص می کند. پارامتر دوم محل مقصد فایل حاصل را مشخص می کند. در حالت غیر تعاملی باید مسیر را مشخص کنید. در حالت تعاملی، پارامتر اختیاری است.
به طور پیش فرض، متد در حالت تعاملی اجرا می شود، یعنی آخرین پارامتر True است. این به این معنی است که یک کادر محاوره ای نمایش داده می شود که در آن می توانید یک عمل را با فایل دریافتی مشخص کنید: آن را اجرا کنید یا آن را در مکان مشخص شده توسط کاربر ذخیره کنید. اگر حالت تعاملی فعال باشد و پارامتر مسیر فایل دیسک هدف مشخص نشده باشد، عملیات باز کردن فایل در دسترس نیست. یک مقدار بولی را برمی‌گرداند. نادرست به این معنی است که کاربر انتخاب کرده است که عملیات را در کادر محاوره ای ذخیره فایل تعاملی لغو کند.
متغیر SelectedName; VariableTemporaryStorageAddress; اگر PutFile (TemporaryStorageAddress, SelectedName, True) سپس Object.FileName = SelectedName; PlaceObjectFile(TemporaryStorageAddress)؛ endIf;
پایان رویه
// کپی کردن یک فایل از ذخیره سازی موقت به یک دایرکتوری //، ضبط یک شی، حذف یک فایل از ذخیره سازی موقت // &در رویه سرور محل فایل شی (آدرس ذخیره سازی موقت)
Element Directory = Form AttributesValue("Object"); BinaryData = GetFileFromTemporaryStorage(TemporaryStorageAddress); Directory Element.File Data = NewValueStorage(BinaryData); FilePathOnDisk = فایل جدید (DirectoryItem.FileName); Directory Item.FileName = FilePathOnDisk.Name; عنصر دایرکتوری.Write(); اصلاح شده = نادرست; DeleteFileFromTemporaryStorage(TemporaryStorageAddress)؛ ValueВFormAttributes(Element Directory، "Object");
پایان رویه
// خواندن یک فایل از props و ذخیره آن // روی دیسک محلی در حالت تعاملی &روی رویه کلاینت ReadFileAndSaveToDisk()
آدرس = GetFileAddressInInformationBase(Object.Link، "FileData"); GetFile (آدرس، Object.FileName، True)؛
پایان رویه
کنترل فیلد تصویر از نمایش تصویر مشخص شده توسط آدرس یک فایل در ذخیره سازی موقت یا در پایگاه داده پشتیبانی می کند.
برای انجام این کار، باید یک ویژگی string type را در ویژگی Data عنصر فرم تنظیم کنید. مقدار این ویژگی به عنوان آدرس تصویر تفسیر می شود.
مثال
PlaceFile (PictureAddress, True)
Picture.Data = AddressPictures
عملکرد مکانیسم توصیف شده هنگام استفاده از سرویس گیرنده وب دارای محدودیت هایی است. این محدودیت ها مربوط به مدل امنیتی مرورگر است. بنابراین، برای مثال، کلاینت نمی تواند به طور مستقل یک فایل را در سیستم فایل محلی ذخیره کند، یعنی فقط نسخه تعاملی روش های کلاینت ()PlaceFile و GetFile() موجود است. هنگام تلاش برای استفاده از حالت غیر تعاملی، یک استثنا ایجاد می شود. کادرهای محاوره ای که به صورت تعاملی ظاهر می شوند، مختص نوع مرورگر شما هستند.
مسئله:
وقتی یک Document دارای یک ویژگی از نوع Value Storage در بخش جدولی باشد، اگر این ویژگی حاوی داده های بزرگ باشد، باز شدن فرم سند را کند می کند.
دلیل فرضی:
شاید، هنگام باز کردن یک فرم، پیوند به داده های موجود در Value Store برای مشتری ارسال نمی شود، بلکه خود داده ها برای مشتری ارسال می شوند.
راه حل
استفاده از آن حتی بهتر است ذخیرهسازی موقتبرای انتقال فایل بین کلاینت و سرور
پلت فرم 1C: سازمانیامکانات زیادی برای ذخیره سازی داده ها در انواع مختلف فراهم می کند.
اما اغلب این فرصت ها کافی نیستند. و سپس یک شی خاص به کمک ما می آید - StorageValues. این شی به شما امکان می دهد هم اشیاء استاندارد 1C: Enterprise را در قالبی خاص ذخیره کنید، به عنوان مثال، یک جدول مقادیر، و هم موارد غیر استانداردی را که نوع خاصی برای آنها در پلت فرم ارائه نشده است. انواع غیر استاندارد ممکن است شامل فایل ها باشد. به عنوان مثال، با استفاده از یک ذخیره ارزش در پایگاه داده 1C، می توانید عکس های کارمندان، اسکن اسناد، پردازش خارجی و غیره را ذخیره کنید. مزیت اینجا این است که همه این اشیاء در خود پایگاه داده ذخیره می شوند. بر این اساس، هنگام استقرار یک پایگاه جدید از نسخه پشتیبانتمام این اشیاء نیز در پایگاه داده جدید وجود خواهند داشت. از طرف دیگر، اگر فایل های حجیم را در پایگاه داده ذخیره کنید، این امر می تواند حجم آن را به میزان قابل توجهی افزایش دهد و بر عملکرد آن تأثیر منفی بگذارد. بنابراین، یک تعادل معقول باید در اینجا حفظ شود.
بیایید با استفاده از یک مثال به کار با یک فروشگاه ارزش نگاه کنیم. بیایید یک دایرکتوری خاص در پیکربندی ایجاد کنیم - بیایید آن را صدا کنیم اشیاء خارجی، و به نوبه خود ما ملزومات دایرکتوری را ایجاد خواهیم کرد یک شیبا نوع StorageValues
و اکنون می توانیم عناصر را در این دایرکتوری و در props ایجاد کنیم یک شیهر عنصر در یک فایل نوشته می شود.
کار با یک فروشگاه ارزش بسیار ساده است. اگر به راهنمای نحو نگاه کنیم، خواهیم دید که این شی تنها یک متد و یک سازنده دارد. 
اکنون، برای نمایش، ساده‌ترین کدی را می‌نویسیم که فایلی را روی props می‌نویسد یک شییک عنصر دایرکتوری که قبلا ایجاد شده بود، و سپس این فایل را از روی props بخوانید و روی دیسک بنویسید، اما با نام دیگری.
&روی رویه سرور LoadUnloadFile(عنصر دایرکتوری)شئ دایرکتوری =عنصر دایرکتوری. GetObject(); //تصویر را در فروشگاه ارزش قرار دهید LabelDownload = تصویر جدید("g:\musor\favicon.ico") NewValueStorage; //یک عنصر دایرکتوری بنویسیدشی دایرکتوری. شی DirectoryObject. نوشتن() ؛ //تصویر را از ذخیره ارزش در یک فایل آپلود کنید FileName = "g:\musor\favicon_1.ico" ; LabelUpload = شی دایرکتوری. یک شی. گرفتن() ؛ LabelUpload. نوشتن (نام فایل) ; پایان رویهو چند توضیح برای کد.
برای ذخیره انواع دیگر فایل ها به غیر از تصاویر در ذخیره سازی، می توانید از شی استفاده کنید باینری دیتا. صرفاً از نظر تئوری، حتی می‌توانید عناصر دایرکتوری، اسناد و غیره را در ذخیرهسازی ارزش ذخیره کنید. اما در عمل این هیچ معنایی ندارد. اما گاهی اوقات می توان از یک ذخیره ارزش برای ذخیره جدول مقادیر، درخت ارزش ها و سایر مجموعه های جهانی استفاده کرد.
در 1C:Enterprise 8 امکان ذخیره داده های مختلف در زمینه هایی از نوع Value Storage وجود دارد. این فیلدها می توانند مقادیری از نوع ValueStorage را ذخیره کنند. نوع ValueStorage خود عمدتاً برای ذخیره مقادیر در نظر گرفته شده است. انواع مختلفبه صورت سریالی، یعنی به شکلی که به شما امکان می دهد داده ها را ضبط کرده و سپس آن ها را بازیابی کنید. در اسناد زبان داخلی، در توضیحات اشیاء، امکان سریال سازی با علامت "Serializable" نشان داده شده است. این مقادیر و همچنین مقادیر انواع اولیه را می توان در یک ذخیره ارزش قرار داد و بنابراین می توان در فیلدهای پایگاه داده از نوع ValueStorage نوشت. یکی از ویژگی های مهم ذخیره ارزش، توانایی ذخیره داده ها به صورت فشرده است. این به شما امکان می دهد تا میزان اطلاعات ذخیره شده برای اشیاء بزرگ را به میزان قابل توجهی کاهش دهید.
بنابراین، با استفاده از فیلدهایی از نوع Value Storage، می‌توان فهرست گسترده‌تری از انواع داده‌ها را در پایگاه داده ذخیره کرد، در مقایسه با آنچه که می‌توان به صراحت برای فیلدها مشخص کرد. با این حال، باید در نظر داشت که این روش ذخیره سازی و توانایی دستکاری چنین داده هایی به طور قابل توجهی با ذخیره سازی معمول داده ها در فیلدهای پایگاه داده متفاوت است. برای چنین فیلدهایی، سیستم عملاً از هیچ عملکردی غیر از نوشتن و خواندن واقعی پشتیبانی نمی کند. برای چنین فیلدهایی نمی توان از نمایه سازی استفاده کرد، داده ها را نمی توان توسط آنها در پرس و جوها و انتخاب ها مرتب کرد، چنین فیلدهایی را نمی توان جمع کرد و غیره. در این حالت می توان موتور پایگاه داده را برای ذخیره برخی از اطلاعات بدون اطلاع از ماهیت آن در نظر گرفت.
بر این اساس، فیلدهای نوع ذخیره ارزش فقط در مواردی باید مورد استفاده قرار گیرند که با هدف و ویژگی های تکنولوژیکی آنها مطابقت دارد.
یکی از کاربردهای اصلی فیلدهای نوع Value Storage ذخیره تصاویر و تصاویر فایل است. برای این منظور از نوع Image و Binary Data استفاده می شود. این به شما امکان می دهد عکس های کارکنان، اسناد ایجاد شده در فرمت های مختلف و غیره را در پایگاه داده ذخیره کنید. هنگام اجرای ذخیره سازی چنین اطلاعاتی، می توان توصیه کرد که ساختارهای داده ای ایجاد کنید که ذخیره سازی جداگانه این فیلدها از اطلاعات اصلی را تضمین می کند. به عنوان مثال، برای ذخیره عکس‌های کارمندان، می‌توانید به جای قرار دادن فیلدهایی از نوع Value Storage در خود اشیایی که فهرست افراد را ذخیره می‌کنند، یک فهرست راهنمای یا ثبت اطلاعات جداگانه پیاده‌سازی کنید. باید در نظر گرفت که اشیا (به عنوان مثال، عناصر دایرکتوری) همیشه توسط سیستم به عنوان یک کل خوانده می شوند. بنابراین، ذخیره مقادیر زیادی از اطلاعات به طور مستقیم در فیلدهای شی می تواند به طور قابل توجهی سرعت سیستم را کاهش دهد.
در فیلدهای نوع ValueStorage، به عنوان مثال، امکان ذخیره جداول مقادیر و ساختارها وجود دارد. در عین حال، هر نوع داده، از جمله انواع مرجع، می تواند در جداول و ساختارهای مقدار ذخیره شود. توجه داشته باشید که اگر مجموعه‌ای فقط حاوی مقادیر قابل سریال‌سازی باشد، می‌توان آن را در فروشگاه ارزش قرار داد. با این حال، باید در نظر گرفت که این گزینه برای ذخیره داده ها به طور قابل توجهی با ذخیره صریح مقادیر در فیلدهای جداگانه و با ذخیره اطلاعات در قطعات جدولی یا ثبت اطلاعات متفاوت است. این سیستم یکپارچگی ارجاعی را برای چنین فیلدهایی حفظ نمی کند، جستجوی داده ها را در پرس و جوها و غیره ارائه نمی دهد. بنابراین، ذخیره مجموعه‌ها در چنین زمینه‌هایی را نمی‌توان برای پیاده‌سازی بخش‌های ضروری یک راه‌حل کاربردی که مسئولیت منطق تجاری را بر عهده دارد، استفاده کرد. چنین ذخیره سازی ممکن است فقط برای داده های کمکی مجاز باشد که برای منطق تجاری راه حل برنامه ضروری نیستند، به عنوان مثال، برای ذخیره تنظیمات کاربر.
اگرچه سیستم محدودیت صریحی برای اندازه داده های ذخیره شده در فیلدهای ValueStorage ندارد، اما همچنان باید مراقب میزان اطلاعات ذخیره شده باشید. باید در نظر داشت که قرار دادن حجم های زیاد در این گونه فیلدها حجم کلی پایگاه اطلاعاتی را افزایش می دهد و این امر بر عملکرد سیستم در انجام عملیات های مختلف اداری مانند ایجاد پشتیبان از پایگاه داده تاثیر منفی خواهد گذاشت. به عنوان مثال، هنگام ذخیره تصاویر فایل، می توان توصیه کرد که داده هایی را که واقعاً در کار ضروری هستند در چنین فیلدهایی ذخیره کنید، اما از آنها برای ذخیره حجم زیادی از فایل هایی که در مشکل برنامه در حال حل استفاده نمی شوند استفاده نکنید.
