در بسیاری از پروژههای سازمانی که با SQL Server کار میکنند، یکی از نیازهای همیشگی تیم توسعه این است که بدانند دقیقاً چه دادهای در نتیجه یک عملیات INSERT، UPDATE یا DELETE تغییر کرده است. این نیاز میتواند از یک سناریوی ساده مثل بازگرداندن شناسه رکورد تازه ثبتشده شروع شود و تا سناریوهای پیچیدهتری مانند Audit Trail، همگامسازی داده بین سیستمها یا پیادهسازی Soft Delete ادامه پیدا کند.
پیش از معرفی بند OUTPUT، معمولاً توسعهدهندگان برای رسیدن به این هدف مجبور بودند از Triggerها یا Queryهای اضافی استفاده کنند که هم پیچیدگی کد را افزایش میداد و هم از نظر Performance هزینه اضافهای به همراه داشت. بند OUTPUT دقیقاً برای حل همین مشکل طراحی شده و به توسعهدهنده اجازه میدهد در همان لحظه اجرای عملیات DML، به مقادیر قبل و بعد از تغییر دسترسی داشته باشد.
در این مقاله بهصورت کامل بررسی میکنیم که بند OUTPUT چگونه کار میکند، جداول مجازی INSERTED و DELETED چه نقشی دارند، چگونه میتوان نتیجه OUTPUT را در جدول دیگری ذخیره کرد و در نهایت چه محدودیتها و Best Practiceهایی باید در پروژههای سازمانی رعایت شود.
تعریف بند OUTPUT در SQL Server
بند OUTPUT قابلیتی در SQL Server است که امکان بازگرداندن اطلاعات مربوط به ردیفهای تحت تأثیر یک عملیات INSERT، UPDATE، DELETE یا MERGE را فراهم میکند. برخلاف روشهای قدیمیتر که برای دسترسی به دادههای تغییریافته نیاز به یک Query جداگانه یا Trigger داشتند، OUTPUT این اطلاعات را مستقیماً در همان دستور DML در اختیار قرار میدهد.
نکته مهمی که در بسیاری از تیمهای توسعه نادیده گرفته میشود این است که OUTPUT یک قابلیت مستقل از Trigger است. یعنی حتی اگر روی جدول هیچ Triggeری تعریف نشده باشد، OUTPUT همچنان کار میکند، زیرا مستقیماً از جداول مجازی INSERTED و DELETED که توسط موتور SQL Server در حین اجرای عملیات DML ساخته میشوند، داده میخواند.
تفاوت OUTPUT با Trigger از نظر معماری
Triggerها در SQL Server مکانیزمهایی هستند که پس از اجرای عملیات منطقی INSERT، UPDATE یا DELETE فعال میشوند و همچنان در همان Transaction اصلی فعالیت میکنند. به همین دلیل، اگر اجرای Trigger با خطا مواجه شود، امکان Rollback شدن کل عملیات DML وجود دارد.
در مقابل، OUTPUT بخشی از همان دستور DML است و به توسعهدهنده اجازه میدهد اطلاعات مربوط به ردیفهای تحت تأثیر عملیات را در همان Query دریافت یا در جدول دیگری ذخیره کند. تفاوت اصلی این دو قابلیت در نحوه استفاده است؛ Trigger برای اجرای خودکار منطق واکنشی مستقل از Queryهای اجراشده مناسب است، در حالی که OUTPUT زمانی کاربرد دارد که توسعهدهنده بخواهد نتیجه تغییرات یک عملیات مشخص را مستقیماً مدیریت کند.
از نظر Performance نیز نمیتوان یک قانون کلی برای برتری OUTPUT نسبت به Trigger بیان کرد، زیرا هزینه نهایی به منطق اجراشده، حجم تغییرات، عملیات نوشتن اضافی و طراحی جدول مقصد بستگی دارد.
جداول مجازی INSERTED و DELETED
برای درک عمیق OUTPUT باید ابتدا با دو جدول مجازی INSERTED و DELETED آشنا شد. این دو جدول شبیه جداولی هستند که در Triggerها نیز استفاده میشوند، اما در OUTPUT بهصورت مستقیم و بدون نیاز به تعریف Trigger در دسترساند.
جدول INSERTED مقادیر جدید ردیفها را پس از اعمال تغییر نگه میدارد. جدول DELETED مقادیر قبلی ردیفها را پیش از تغییر یا حذف نگه میدارد. رفتار این دو جدول بسته به نوع عملیات متفاوت است.
رفتار INSERTED و DELETED در عملیات INSERT
در عملیات INSERT فقط جدول INSERTED مقداردهی میشود و شامل تمام ردیفهای تازه درجشده است. جدول DELETED در این حالت خالی است، زیرا هیچ ردیفی حذف نشده است.
CREATE TABLE Orders
(
OrderID INT IDENTITY(1,1) PRIMARY KEY,
CustomerID INT NOT NULL,
OrderDate DATETIME2 NOT NULL DEFAULT SYSDATETIME(),
Amount DECIMAL(18,2) NOT NULL
);
INSERT INTO Orders (CustomerID, Amount)
OUTPUT INSERTED.OrderID, INSERTED.OrderDate, INSERTED.Amount
VALUES (1024, 4500.00);
در این مثال، بلافاصله پس از درج رکورد، مقدار OrderID که توسط IDENTITY تولید شده، همراه با تاریخ ثبت و مبلغ سفارش بازگردانده میشود. این الگو در سیستمهای فروش سازمانی که نیاز دارند بلافاصله پس از ثبت سفارش، شناسه آن را برای پردازشهای بعدی مانند صدور فاکتور یا اطلاعرسانی به سرویسهای دیگر استفاده کنند، بسیار پرکاربرد است.
پیش از معرفی OUTPUT، برای رسیدن به همین نتیجه معمولاً از تابع SCOPE_IDENTITY استفاده میشد که تنها شناسه آخرین رکورد درجشده را برمیگرداند و در عملیاتهای Batch با چند ردیف کاربرد نداشت. OUTPUT این محدودیت را کاملاً برطرف میکند.
رفتار INSERTED و DELETED در عملیات DELETE
در عملیات DELETE فقط جدول DELETED مقداردهی میشود و شامل مقادیر ردیفهایی است که حذف شدهاند. جدول INSERTED در این حالت خالی است.
DELETE FROM Orders
OUTPUT DELETED.OrderID, DELETED.CustomerID, DELETED.Amount
WHERE OrderDate < DATEADD(YEAR, -3, SYSDATETIME());
این Query تمام سفارشهای قدیمیتر از سه سال را حذف میکند و همزمان اطلاعات کامل ردیفهای حذفشده را بازمیگرداند. این الگو در فرآیندهای Archiving اهمیت زیادی دارد، زیرا میتوان داده حذفشده را مستقیماً در همان عملیات به جدول Archive منتقل کرد، بدون آنکه نیاز به Query جداگانه برای خواندن داده پیش از حذف باشد.
رفتار INSERTED و DELETED در عملیات UPDATE
عملیات UPDATE تنها سناریویی است که هر دو جدول INSERTED و DELETED بهصورت همزمان مقداردهی میشوند. جدول DELETED مقدار قبل از تغییر و جدول INSERTED مقدار بعد از تغییر را نگه میدارد.
UPDATE Orders
SET Amount = Amount * 1.1
OUTPUT
DELETED.OrderID,
DELETED.Amount AS OldAmount,
INSERTED.Amount AS NewAmount
WHERE CustomerID = 1024;
این قابلیت دقیقاً همان چیزی است که در سناریوهای Audit سازمانی حیاتی است، زیرا امکان مقایسه مستقیم مقدار قبل و بعد از تغییر را در یک Query واحد فراهم میکند، بدون آنکه نیاز به دو Query جداگانه یا Snapshotگیری دستی باشد.
ذخیره نتیجه OUTPUT در جدول مقصد
یکی از قابلیتهای مهم OUTPUT این است که نتیجه آن را میتوان مستقیماً در یک جدول دیگر ذخیره کرد، بدون آنکه این خروجی به Client بازگردانده شود. این کار با استفاده از عبارت OUTPUT INTO انجام میشود و در سناریوهای Audit Trail یکی از پرکاربردترین الگوهای طراحی است.
فرض کنید در یک سیستم سفارشگیری سازمانی نیاز داریم هر تغییری روی جدول Orders را در یک جدول تاریخچه ثبت کنیم.
CREATE TABLE OrdersAuditLog
(
AuditID INT IDENTITY(1,1) PRIMARY KEY,
OrderID INT NOT NULL,
OldAmount DECIMAL(18,2) NULL,
NewAmount DECIMAL(18,2) NULL,
ChangeType VARCHAR(10) NOT NULL,
ChangeDate DATETIME2 NOT NULL DEFAULT SYSDATETIME()
);
حال عملیات بهروزرسانی را بهگونهای مینویسیم که نتیجه تغییر مستقیماً در جدول Audit ثبت شود.
UPDATE Orders
SET Amount = Amount * 1.1
OUTPUT
DELETED.OrderID,
DELETED.Amount,
INSERTED.Amount,
'UPDATE'
INTO OrdersAuditLog (OrderID, OldAmount, NewAmount, ChangeType)
WHERE CustomerID = 1024;
در این Query، همزمان با اجرای UPDATE روی جدول اصلی، یک رکورد کامل شامل مقدار قبل و بعد از تغییر در جدول OrdersAuditLog ثبت میشود. این الگو در مقایسه با استفاده از Trigger برای همین هدف، از نظر خوانایی کد و کنترل مستقیم روی منطق Audit، برتری قابل توجهی دارد، زیرا منطق ثبت تغییرات دقیقاً در همان محل اجرای عملیات اصلی قابل مشاهده است.
استفاده از OUTPUT INTO برای Archive کردن دادههای حذفشده
الگوی دیگری که در پروژههای سازمانی بسیار رایج است، انتقال داده حذفشده به جدول Archive بهجای حذف کامل آن است.
CREATE TABLE OrdersArchive
(
OrderID INT PRIMARY KEY,
CustomerID INT NOT NULL,
OrderDate DATETIME2 NOT NULL,
Amount DECIMAL(18,2) NOT NULL,
ArchivedDate DATETIME2 NOT NULL DEFAULT SYSDATETIME()
);
DELETE FROM Orders
OUTPUT DELETED.OrderID, DELETED.CustomerID, DELETED.OrderDate, DELETED.Amount
INTO OrdersArchive (OrderID, CustomerID, OrderDate, Amount)
WHERE OrderDate < DATEADD(YEAR, -3, SYSDATETIME());
این روش باعث میشود در یک Transaction واحد، هم حذف از جدول اصلی و هم انتقال به جدول Archive انجام شود. از منظر یکپارچگی تراکنشی، این رویکرد بسیار قابل اعتمادتر از نوشتن دو Query جداگانه در دو Transaction مجزا است، زیرا در صورت بروز خطا، کل عملیات Rollback میشود و امکان از دست رفتن داده در میانه راه وجود ندارد.
استفاده از OUTPUT در MERGE
بند OUTPUT در دستور MERGE نیز قابل استفاده است، اما با یک تفاوت مهم. از آنجا که MERGE میتواند همزمان شامل عملیات INSERT، UPDATE و DELETE باشد، برای تشخیص اینکه هر ردیف خروجی مربوط به کدام نوع عملیات است، باید از تابع $action استفاده کرد.
MERGE INTO Orders AS Target
USING StagingOrders AS Source
ON Target.OrderID = Source.OrderID
WHEN MATCHED THEN
UPDATE SET Target.Amount = Source.Amount
WHEN NOT MATCHED BY TARGET THEN
INSERT (CustomerID, OrderDate, Amount)
VALUES (Source.CustomerID, Source.OrderDate, Source.Amount)
WHEN NOT MATCHED BY SOURCE THEN
DELETE
OUTPUT
$action AS ActionType,
INSERTED.OrderID,
DELETED.OrderID,
INSERTED.Amount,
DELETED.Amount;
در این Query، ستون ActionType مشخص میکند که هر ردیف نتیجه یک عملیات INSERT، UPDATE یا DELETE بوده است. این قابلیت باعث میشود OUTPUT در سناریوهای همگامسازی داده و فرآیندهای ETL قابل استفاده باشد.
با این حال، استفاده از MERGE در SQL Server باید با دقت انجام شود. در برخی نسخههای SQL Server مشکلات و رفتارهای پیشبینینشدهای برای MERGE گزارش شده است و بسیاری از تیمهای توسعه در پروژههای حساس ترجیح میدهند عملیات INSERT، UPDATE و DELETE را بهصورت جداگانه مدیریت کنند.
بنابراین اگرچه OUTPUT در MERGE قابلیت مفیدی برای ثبت تغییرات فراهم میکند، انتخاب MERGE باید بر اساس نسخه SQL Server، شرایط پروژه و تستهای عملکردی و صحت داده انجام شود.
سناریوی سازمانی: پیادهسازی Change Data Capture سبک با OUTPUT
در بسیاری از سازمانها، پیادهسازی کامل Change Data Capture یا Change Tracking به دلیل پیچیدگی پیکربندی یا محدودیت نسخه SQL Server امکانپذیر نیست. در چنین شرایطی، ترکیب OUTPUT INTO با یک جدول Staging میتواند جایگزین سبکتری برای ردیابی تغییرات باشد.
فرض کنید در یک سیستم انبارداری سازمانی، هر تغییر در موجودی کالا باید برای سیستم گزارشگیری BI ارسال شود. بهجای پیادهسازی CDC کامل، میتوان جدولی بهعنوان صف تغییرات طراحی کرد.
CREATE TABLE InventoryChangeQueue
(
ChangeID INT IDENTITY(1,1) PRIMARY KEY,
ProductID INT NOT NULL,
OldQuantity INT NULL,
NewQuantity INT NULL,
ChangeType VARCHAR(10) NOT NULL,
ChangeDate DATETIME2 NOT NULL DEFAULT SYSDATETIME(),
IsProcessed BIT NOT NULL DEFAULT 0
);
UPDATE Inventory
SET Quantity = Quantity - 50
OUTPUT
DELETED.ProductID,
DELETED.Quantity,
INSERTED.Quantity,
'UPDATE'
INTO InventoryChangeQueue (ProductID, OldQuantity, NewQuantity, ChangeType)
WHERE ProductID = 3021;
یک سرویس جداگانه یا Job زمانبندیشده میتواند بهصورت دورهای رکوردهای IsProcessed برابر با صفر را از جدول InventoryChangeQueue بخواند، به سیستم BI ارسال کند و سپس آنها را بهعنوان پردازششده علامت بزند. این الگو، بدون نیاز به فعالسازی CDC در سطح دیتابیس، امکان ردیابی تغییرات را برای مصرفکنندگان پاییندستی فراهم میکند.
محدودیتهای بند OUTPUT
با وجود قابلیتهای گسترده، بند OUTPUT محدودیتهای مشخصی دارد که باید در طراحی سیستم در نظر گرفته شوند.
عدم پشتیبانی از Triggerهای INSTEAD OF بهصورت همزمان با OUTPUT INTO یک جدول با Trigger
اگر جدول مقصدی که در OUTPUT INTO استفاده میشود دارای Trigger باشد، این ترکیب در برخی نسخهها با محدودیت مواجه است. توصیه میشود جدول مقصد OUTPUT INTO ساده و بدون Trigger پیچیده طراحی شود.
عدم امکان استفاده مستقیم از OUTPUT برای فیلتر کردن داده
بند OUTPUT بهتنهایی امکان اعمال شرط WHERE روی خود جدول INSERTED یا DELETED را ندارد. اگر نیاز به فیلتر کردن نتیجه OUTPUT باشد، معمولاً باید از یک Common Table Expression یا جدول موقت برای نگهداری خروجی و سپس فیلتر کردن آن استفاده کرد.
DECLARE @ChangedRows TABLE
(
OrderID INT,
OldAmount DECIMAL(18,2),
NewAmount DECIMAL(18,2)
);
UPDATE Orders
SET Amount = Amount * 1.1
OUTPUT DELETED.OrderID, DELETED.Amount, INSERTED.Amount
INTO @ChangedRows
WHERE CustomerID = 1024;
SELECT * FROM @ChangedRows WHERE NewAmount > 5000;
در این روش، ابتدا تمام تغییرات در متغیر جدولی @ChangedRows ذخیره میشود و سپس با یک SELECT جداگانه، فیلتر موردنظر روی نتیجه اعمال میشود.
محدودیت در ترکیب با برخی ویژگیهای خاص جدول
در جداولی که دارای ستونهای محاسباتی پیچیده یا برخی انواع Indexed View هستند، ممکن است رفتار OUTPUT با محدودیتهای اضافی مواجه شود. بررسی مستندات رسمی مایکروسافت پیش از پیادهسازی OUTPUT روی جداول با ساختار پیچیده توصیه میشود.
تأثیر OUTPUT بر Performance در عملیاتهای حجیم
یکی از سؤالات مهم در استفاده از OUTPUT این است که آیا دریافت اطلاعات تغییرات باعث ایجاد سربار اضافی روی عملیات DML میشود یا خیر. پاسخ به این سؤال به نحوه استفاده از OUTPUT بستگی دارد.
در حالتی که OUTPUT فقط برای بازگرداندن چند ستون از رکوردهای تغییرکرده به لایه برنامه استفاده شود، معمولاً سربار محدودی ایجاد میکند. اما زمانی که از OUTPUT INTO برای ذخیره حجم زیادی از تغییرات در یک جدول Audit یا Queue استفاده میشود، عملیات نوشتن اضافی، افزایش مصرف I/O و رشد Transaction Log میتواند روی Performance تأثیرگذار باشد.
SQL Server هنگام اجرای عملیات DML اطلاعات موردنیاز برای مدیریت تغییرات و قابلیتهایی مانند Trigger و OUTPUT را نگهداری میکند، اما INSERTED و DELETED بهعنوان جداول مجازی برای دسترسی منطقی به مقادیر قبل و بعد از تغییر استفاده میشوند و بخشی از ساختار دائمی Transaction Log نیستند.
در سناریوهای حجیم توصیه میشود جدول مقصد OUTPUT INTO دارای طراحی ساده، Index مناسب و فرآیند Batch بندی مناسب باشد تا ثبت تغییرات به یک نقطه گلوگاه در سیستم تبدیل نشود.
Best Practiceهای استفاده از OUTPUT در پروژههای سازمانی
پیش از استفاده گسترده از OUTPUT در یک سیستم سازمانی، رعایت چند اصل طراحی توصیه میشود.
نامگذاری ستونهای خروجی OUTPUT باید واضح و گویا باشد، بهخصوص در عملیات UPDATE که هر دو جدول INSERTED و DELETED همزمان استفاده میشوند. استفاده از Aliasهایی مانند OldAmount و NewAmount خوانایی کد را بهطور محسوسی افزایش میدهد.
جدول مقصد در OUTPUT INTO باید از قبل با ساختار مشخص طراحی شده باشد و شامل ستونهایی برای زمان تغییر و نوع عملیات باشد، تا در تحلیلهای بعدی امکان بازسازی دقیق تاریخچه تغییرات وجود داشته باشد.
در سناریوهایی که نیاز به فیلتر کردن نتیجه OUTUT وجود دارد، استفاده از متغیر جدولی یا جدول موقت بهجای تلاش برای اعمال شرط مستقیم روی OUTPUT توصیه میشود.
در عملیاتهای MERGE، استفاده از $action برای تشخیص نوع عملیات الزامی است و نباید فرض شود که صرفاً بررسی خالی یا پر بودن INSERTED و DELETED برای تشخیص نوع تغییر کافی است، زیرا در برخی سناریوهای پیچیده MERGE این تشخیص میتواند نادرست باشد.
پیش از پیادهسازی OUTPUT بهعنوان جایگزین کامل CDC یا Change Tracking، باید نیاز واقعی پروژه سنجیده شود. OUTPUT برای ردیابی تغییرات در سطح Query مناسب است، اما برای سناریوهای پیچیدهتر مانند ردیابی تغییرات در سطح کل دیتابیس یا نیاز به Replication، ابزارهای تخصصیتر SQL Server گزینه مناسبتری هستند.
مقایسه OUTPUT با Trigger و CDC
انتخاب بین OUTPUT، Trigger و Change Data Capture به نیاز واقعی پروژه بستگی دارد. OUTPUT برای سناریوهایی مناسب است که نیاز به دسترسی فوری به داده تغییریافته در همان Query وجود دارد و منطق مربوطه محدود به همان عملیات است.
Trigger برای سناریوهایی مناسبتر است که منطق واکنش به تغییر باید مستقل از نحوه اجرای عملیات DML باشد، یعنی صرفنظر از اینکه تغییر از کدام اپلیکیشن یا Query اعمال شده، منطق مشخصی باید اجرا شود.
Change Data Capture برای سناریوهای سازمانی که نیاز به ردیابی کامل و پیوسته تمام تغییرات یک جدول دارند، بدون وابستگی به نوشتن OUTPUT در هر Query، گزینه مناسبتری است، هرچند پیکربندی و نگهداری آن پیچیدهتر از OUTPUT است.
در بسیاری از پروژههای سازمانی، ترکیبی از این سه ابزار بر اساس نیاز هر بخش از سیستم استفاده میشود. برای مثال ممکن است OUTPUT برای بازگرداندن شناسه رکورد تازه درجشده به لایه اپلیکیشن استفاده شود، در حالی که برای Audit کامل سطح دیتابیس از Change Data Capture بهره گرفته شود.
جمعبندی
بند OUTPUT در SQL Server یکی از ابزارهای کارآمد برای دسترسی مستقیم به داده تحت تأثیر عملیات INSERT، UPDATE، DELETE و MERGE است. جداول مجازی INSERTED و DELETED که در پسزمینه توسط موتور SQL Server مدیریت میشوند، امکان دسترسی به مقادیر قبل و بعد از تغییر را بدون نیاز به Trigger فراهم میکنند.
استفاده از OUTPUT INTO برای ذخیره تغییرات در جداول Audit یا Archive، یکی از الگوهای رایج و قابل اعتماد در پروژههای سازمانی است، بهخصوص از این جهت که کل عملیات در قالب یک Transaction واحد انجام میشود و ریسک ناهماهنگی داده را کاهش میدهد. با این حال، OUTPUT جایگزین کامل ابزارهای تخصصیتری مانند Change Data Capture نیست و انتخاب صحیح ابزار باید بر اساس نیاز واقعی هر پروژه صورت گیرد.
سوالات متداول FAQ
آیا بند OUTPUT نیاز به تعریف Trigger روی جدول دارد؟
خیر. بند OUTPUT مستقل از Trigger عمل میکند و مستقیماً از جداول مجازی INSERTED و DELETED که در حین اجرای عملیات DML توسط موتور SQL Server ساخته میشوند، داده میخواند.
در عملیات UPDATE چه تفاوتی بین جدول INSERTED و DELETED وجود دارد؟
جدول DELETED مقدار ردیف پیش از اعمال تغییر را نگه میدارد و جدول INSERTED مقدار ردیف پس از اعمال تغییر را. استفاده همزمان از هر دو امکان مقایسه مستقیم مقدار قبل و بعد از تغییر را در یک Query فراهم میکند.
آیا میتوان روی نتیجه OUTPUT شرط WHERE اعمال کرد؟
بهصورت مستقیم خیر. برای فیلتر کردن نتیجه OUTPUT باید ابتدا خروجی را در یک متغیر جدولی یا جدول موقت ذخیره کرد و سپس شرط موردنظر را روی همان جدول اعمال نمود.
تفاوت اصلی OUTPUT و Change Data Capture چیست؟
OUTPUT در سطح یک Query مشخص عمل میکند و نیاز به نوشتن صریح در هر دستور DML دارد، در حالی که Change Data Capture بهصورت پیوسته و مستقل از نحوه اجرای Query، تمام تغییرات یک جدول را در سطح دیتابیس ردیابی میکند.
استفاده از OUTPUT چه تأثیری روی Performance عملیات حجیم دارد؟
هزینه خواندن داده از جداول INSERTED و DELETED معمولاً کم است، اما اگر از OUTPUT INTO برای نوشتن در جدول دیگر استفاده شود، هزینه I/O اضافی روی جدول مقصد ایجاد میشود که باید با طراحی مناسب Index و در صورت نیاز تقسیم عملیات به Batchهای کوچکتر مدیریت شود.
طراحی Audit و مدیریت تغییرات داده در SQL Server با کمک متخصصان لاندا
در سیستمهای سازمانی، از دست رفتن قابلیت ردیابی تغییرات داده میتواند باعث مشکلات جدی در کنترل اطلاعات، گزارشگیری و تصمیمگیری شود. طراحی صحیح Audit، مدیریت Change Data و بهینهسازی SQL Server نیازمند شناخت عمیق معماری دیتابیس و رفتار موتور اجرا است.
توسعه فناوری اطلاعات لاندا با ارائه خدمات تخصصی SQL Server، Database Performance Tuning و طراحی راهکارهای مدیریت داده، همراه سازمانها در ایجاد زیرساختهای دادهای پایدار، سریع و قابل اعتماد است.
No comment