همگام‌سازی داده‌ها در SQL Server با استفاده از row version

 یکی از وظایف هر متخصص پایگاه داده هماهنگ‌سازی داده‌های میان دو جدول است. برای این منظور روش‌های مختلفی ازجمله تغییر ثبت داده‌ها، تغییر ردیابی داده‌ها، تکرار، استفاده از تریگر ها و… وجود دارد. اگرچه در برخی شرایط این راهکارها مناسب به نظر نمی‌رسند. برای مثال هنگامی‌که جداول مبدأ و مقصد در پایگاه داده‌های مختلفی مانند Sybase, SQL Server قرار می‌گیرند.

 فرض کنید ما دو جدول از پایگاه داده‌های مختلف داریم که داده‌های این جداول به‌طور کامل نیاز به همگام‌سازی دارند. ما امکان مقایسه کردن این داده‌ها، بروز رسانی سطرهای موجود و هم‌چنین اضافه کردن سطرهای جدید راداریم. اگرچه مقایسه تمامی داده‌های جداول روش مناسب و مؤثری نیست، به همین منظور، بهتر است تغییرات این داده‌ها را در جدول اصلی تشخیص دهیم و تنها این تغییرات را در جدول مقصد اعمال کنیم. چنین راه‌حلی از طریق نوع داده‌ی row version در SQL Server امکان‌پذیر است. در این مقاله ما به بررسی نوع داده‌ی row version و کاربرد آن در همگام‌سازی داده‌ها را خواهیم پرداخت.

 مقدار منحصربه‌فردی که برای این نوع داده در پایگاه داده‌ها به‌صورت پیش‌فرض در نظر گرفته می‌شود، اعداد باینری که در ۸ بایت از فضای حافظه قرار می‌گیرند، است. مقادیر null برای ستون row version از نوع (binary(8 و مقادیری که null نباشند، برابر با (varbinary(8 می‌باشند. ستون‌هایی با نوع داده row version برای تشخیص تغییرات یک سطر به کار می‌روند. شما می‌توانید تنها یک ستون row version داشته باشید. هنگامی‌که داده در یک جدول حاوی ستون row version مقداردهی می‌شود و یا به‌روزرسانی می‌شود، شمارنده‌ی پایگاه داده که row version پایگاه داده است، افزایش می‌یابد. درواقع این مقدار افزایشی، مقدار ستون row version به ازای سطرهای مقداردهی شده یا بروز رسانی شده است.

 مروری بر row version در SQL Server

برای شروع یک پایگاه داده ایجاد می‌کنیم:

مقدار فعلی row version مربوط به پایگاه داده را می‌توان با این query محاسبه کرد:

 در زیر نتیجه را مشاهده می‌کنید:

در اینجا چندین نکته را یادآور می‌شویم. نوع داده‌ی timestamp با row version مترادف است. هنگامی‌که ما یک جدول حاوی یک ستون با نوع داده‌ی row version را با T-SQL ایجاد می‌کنیم، آن ستون را در SSMS با نوع داده‌ی timestamp مشاهده می‌کنید.

 هنگامی‌که ما بخواهیم یک ستون حاوی نوع داده‌ی row version را در SSMS اضافه کنیم، در میان تمامی نوع داده‌های مربوط به هر ستون، مقدار نوع داده‌ی row version وجود ندارد، ازاین‌رو مقدار نوع داده‌ی timestamp را انتخاب می‌نماییم.

 ممکن است شما یک جدول حاوی ستون timestamp ایجاد نمایید، بدون اینکه نام این ستون را ذکر نمایید، در این صورت این ستون به‌صورت خودکار ایجاد می‌شود.

درحالی‌که اگر بخواهیم ستونی حاوی نوع داده‌ی row version را بدون ذکر نام ایجاد کنیم، با خطا روبرو می‌شویم.

 استفاده از timestamp در نسخه‌های جدید مناسب نیست، ازاین‌رو مایکروسافت استفاده از row version را به‌جای timestamp در عبارات DDL پیشنهاد می‌دهد.

مثالی از استفاده از row version در sql server:
می‌توانیم از جدول Test Table A ایجادشده برای نشان دادن عملکرد row version استفاده کنیم. مقادیر داده را به جدول اضافه می‌کنیم و مقادیر را در ستون LastChange مشاهده می‌کنیم. این مقادیر به‌طور خودکار تولید می‌شوند همچنین آخرین مقدار از این ستون با مقدار row version فعلی پایگاه داده برابر است.

زمانی که ما یک سطر را تغییر دهیم می‌توانیم این تغییرات را در ستون last change ببینیم. لازم است به این نکته توجه کنیم که حتی اگر مقدار داده در این جدول تغییری نکند، مقدار row version تغییر می‌کند.

تشخیص تغییرات و بروز رسانی جدول نهایی:

حال می‌خواهیم داده‌ها را با بهره‌گیری از این نوع داده‌ی row version با استفاده از یک مثال ساده همگام‌سازی کنیم. فرض کنید ما دو جدول مبدأ (source) و مقصد (target) داریم، داده‌های جدول مقصد نیاز به هماهنگ‌سازی با داده‌های جدول اولیه رادارند. (با این فرض که داده‌های جدول اصلی را حذف نمی‌کنیم، پیش می‌رویم.)
در جدول اصلی ستونی به نام last change با نوع داده‌ی row version ایجاد می‌شود، در جدول نهایی نیز به همین منظور ستونی با نوع داده‌ی binary(8) ایجاد می‌شود. کد زیر داده‌ها را به جدول اصلی وارد می‌کند:

می‌خواهیم داده‌های جدول اولیه (source) و نهایی (target) را هماهنگ کنیم. به‌منظور اینکه همه‌ی مقادیر داده‌ها مورد مقایسه قرار نگیرند، تنها تغییرات داده‌ها پس از همگام‌سازی از جدول اصلی (source)، در جدول نهایی (target) ثبت می‌کنیم.
برای اینکه این تغییرات را تشخیص دهیم از داده‌های ستون last change به این صورت استفاده می‌کنیم:
بیشترین مقدار داده در ستون LastChange را از جدول target مشخص می‌کنیم.
در مرحله بعد تنها سطرهایی از جدول source را انتخاب می‌کنیم که مقدار ستون LastChange در آن سطرها از بیشترین مقدار داده در ستون LastChange جدول target بزرگ‌تر باشد.
درنهایت ما جدول target را با استفاده از این مقادیر از جدول source بروز رسانی می‌کنیم.
لازم به ذکر است که ما تنها سطرهایی از جدول نهایی را بروز رسانی می‌کنیم که مقدار ستون LastChange در آن سطرها پس از همگام‌سازی دچار تغییر شده باشد. از دستور Merge برای پیاده‌سازی فرآیند همگام‌سازی استفاده می‌کنیم.

هنگامی‌که برای اولین بار این دستور را اجرا کنیم تمامی مقادیر از جدول اولیه به جدول نهایی اضافه می‌شوند، دلیل چنین پیشامدی، خالی بودن جدول target است.

 اکنون می‌خواهیم جدول source را update کنیم:

 تمامی تغییرات جدول source به جدول target اضافه می‌شوند و درنهایت تمام داده‌های این دو جدول هماهنگ‌سازی می‌شوند.

 برای اینکه فرآیند هماهنگ‌سازی به‌صورت خودکار انجام شود، می‌توانیم یک اسکریپت، procedure و یا پکیج SSIS که بر روی برنامه‌ی از پیش تعریف‌شده‌ای قابل‌اجرا است، داشته باشیم. با همه‌ی این تفاسیر row version(timestamp) به راهکار مطلوب برای تشخیص تغییرات داده‌ها است. نوع داده‌های مشابه ای وجود دارند که تنها ازلحاظ پیاده‌سازی از یکدیگر متمایز هستند. حال‌آنکه مایکروسافت نوع داده‌ی row version را به‌عنوان جایگزینی برای timestamp در ورژن های آینده پیشنهاد می‌کند؛ بنابراین استفاده از این نوع داده یک‌راه حل مناسب است، به‌ویژه هنگامی‌که راه‌حل‌های دیگر قابل‌اجرا نباشند. از row version در انبارهای داده (datawarehouse) در حال بارگذاری نیز استفاده می‌شود.

از طریق این لینک می توانید کدها را دانلود کنید:row version

4 پاسخ
  1. مسعود محمودی
    مسعود محمودی گفته:

    سلام
    ممنون من اینو که جدول tamp ایجاد کردن اینقدر نکته داره نمیدونستم ، واقعا ممنون از مقاله بسیار عالیتون به دوستان هم پیشنهاد میکنم سایت شما رو
    تشکر فراوان

    پاسخ

دیدگاه خود را ثبت کنید

تمایل دارید در گفتگوها شرکت کنید؟
در گفتگو ها شرکت کنید.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *