آموزش جامع تابع DB_ID در SQL Server؛ Syntax، خروجی و ۱۰ مثال کاربردی

آموزش جامع تابع DB_ID در SQL Server

توسط admin | گروه SQL Server | 1405/05/03

نظرات 0

آموزش جامع تابع DB_ID در SQL Server با ۱۰ مثال عملی

در پروژه‌های واقعی، ارزش یک تابع سیستمی زمانی مشخص می‌شود که خروجی آن در کنترل استقرار، پایش یا مستندسازی به‌کار رود. در این مقاله، DB_ID از سطح مقدماتی تا سناریوهای حرفه‌ای بررسی می‌شود و هر مثال با خروجی نمونه ارائه شده است.

برای فیلتر DMVها، ارجاع به توابع مدیریتی و کنترل وجود پایگاه داده از DB_ID استفاده می‌شود. تمرکز آموزش بر این است که DB_ID در چه Contextی اجرا شود، نتیجه آن چگونه تفسیر شود و چه زمانی باید از یک DMV یا کاتالوگ‌ویوی جایگزین کمک گرفت.

برای مشاهده جایگاه DB_ID میان سایر توابع و شمارنده‌ها، راهنمای جامع توابع کمکی کارایی و Metadata در SQL Server را نیز مطالعه کنید.

تعریف و کاربرد اصلی DB_ID

تابع DB_ID نام یک پایگاه داده را به شناسه عددی آن تبدیل می‌کند و بدون پارامتر شناسه پایگاه داده جاری را برمی‌گرداند. این تعریف در ظاهر کوتاه است، اما استفاده درست از DB_ID به درک مفاهیمی مانند database name، database_id و sys.databases وابسته است.

قاعده عملی DB_ID: ابتدا ورودی و Context را معتبر کنید، سپس خروجی را با نوع داده و معنای واقعی آن تفسیر کنید.

Syntax تابع یا متغیر DB_ID

SELECT DB_ID ( [ N'database_name' ] ) AS Result;

پارامترهای DB_ID

پارامترتوضیح
database_nameنام اختیاری پایگاه داده؛ در صورت حذف، Context فعلی استفاده می‌شود.

نوع خروجی و رفتار NULL در DB_ID

int یا NULL اگر نام یافت نشود یا کاربر امکان مشاهده Metadata مربوط را نداشته باشد. در کد تولیدی بهتر است نوع مقصد به‌صورت صریح تعیین شود؛ زیرا تبدیل ضمنی می‌تواند مقایسه، مرتب‌سازی یا ذخیره نتیجه DB_ID را مبهم کند.

مفاهیم کلیدی مرتبط با DB_ID

  • database name
  • database_id در مبحث DB_ID
  • sys.databases در مبحث DB_ID
  • DMV filtering
  • current context
  • NULL در مبحث DB_ID
  • permissions در مبحث DB_ID
نقشه مفهومی DB_ID در SQL Serverنمودار فنی اختصاصی DB_ID شامل database name، database_id، sys.databases، DMV filtering، current contextDB_IDdatabase namedatabase_idsys.databasesDMV filteringcurrent contextبرای فیلتر DMVها، ارجاع به توابع مدیریتی و کنترل وجود پایگاه داده از DB_ID استفاده می‌شود.

تصویر نخست، ارتباط DB_ID را با مفاهیم اختصاصی database name، database_id، sys.databases و DMV filtering نشان می‌دهد؛ این روابط مبنای انتخاب ورودی و تفسیر خروجی هستند.

سناریوهای واقعی استفاده از DB_ID

سناریوی 1 برای DB_ID، «فیلتر گزارش ایندکس» است. در این حالت باید نتیجه همراه Context پایگاه داده، زمان نمونه‌برداری و در صورت نیاز شناسه نشست ثبت شود تا داده برای عیب‌یابی بعدی ارزش داشته باشد.

سناریوی 2 برای DB_ID، «کنترل وجود Database» است. در این حالت باید نتیجه همراه Context پایگاه داده، زمان نمونه‌برداری و در صورت نیاز شناسه نشست ثبت شود تا داده برای عیب‌یابی بعدی ارزش داشته باشد.

سناریوی 3 برای DB_ID، «ثبت شناسه Context» است. در این حالت باید نتیجه همراه Context پایگاه داده، زمان نمونه‌برداری و در صورت نیاز شناسه نشست ثبت شود تا داده برای عیب‌یابی بعدی ارزش داشته باشد.

سناریوی 4 برای DB_ID، «ارسال شناسه به DB_NAME» است. در این حالت باید نتیجه همراه Context پایگاه داده، زمان نمونه‌برداری و در صورت نیاز شناسه نشست ثبت شود تا داده برای عیب‌یابی بعدی ارزش داشته باشد.

مثال‌های عملی DB_ID از ساده تا حرفه‌ای

مثال 1: شناسه پایگاه جاری

بدون پارامتر شناسه Context فعلی را می‌گیریم. این سناریو به‌طور اختصاصی برای درک رفتار DB_ID طراحی شده است.

SELECT DB_ID() AS CurrentDatabaseId;
CurrentDatabaseId
7

این شناسه در بسیاری از DMVهای پایگاه داده کاربرد دارد. هنگام استفاده سازمانی از DB_ID، خروجی نمونه را با داده واقعی محیط خود تطبیق دهید.

مثال 2: شناسه از روی نام

نام Unicode را به DB_ID تبدیل می‌کنیم. این سناریو به‌طور اختصاصی برای درک رفتار DB_ID طراحی شده است.

SELECT DB_ID(N'a00b') AS DatabaseId;
DatabaseId
7

برای نام فارسی یا غیرلاتین حتماً پیشوند N استفاده شود. هنگام استفاده سازمانی از DB_ID، خروجی نمونه را با داده واقعی محیط خود تطبیق دهید.

مثال 3: کنترل وجود Database

پیش از منطق وابسته، نام پایگاه را اعتبارسنجی می‌کنیم. این سناریو به‌طور اختصاصی برای درک رفتار DB_ID طراحی شده است.

IF DB_ID(N'a00b') IS NULL
            SELECT N'پایگاه داده وجود ندارد' AS Result;
        ELSE
            SELECT N'پایگاه داده موجود است' AS Result;
Result
پایگاه داده موجود است

این کنترل جای مجوز و بررسی State را نمی‌گیرد. هنگام استفاده سازمانی از DB_ID، خروجی نمونه را با داده واقعی محیط خود تطبیق دهید.

مثال 4: فیلتر DMV ایندکس در آموزش DB_ID

DB_ID جاری را به تابع فیزیکی ایندکس می‌دهیم. این سناریو به‌طور اختصاصی برای درک رفتار DB_ID طراحی شده است.

SELECT TOP (10)
               ips.object_id,
               ips.index_id,
               ips.avg_fragmentation_in_percent
        FROM sys.dm_db_index_physical_stats
        (
            DB_ID(),
            NULL,
            NULL,
            NULL,
            N'LIMITED'
        ) AS ips
        WHERE ips.index_id > 0;
object_idindex_idavg_fragmentation_in_percent
24557591313.25

در پایگاه بزرگ، object_id را نیز محدود کنید تا اسکن سنگین نشود. هنگام استفاده سازمانی از DB_ID، خروجی نمونه را با داده واقعی محیط خود تطبیق دهید.

جریان اجرا DB_ID در SQL Serverنمودار فنی اختصاصی DB_ID شامل database name، database_id، sys.databases، DMV filtering، current contextdatabase nameمرحله 1database_idمرحله 2DB_IDمرحله 3sys.databasesمرحله 4DMV filteringمرحله 5ورودی تا خروجی DB_IDcurrent contextNULLint یا NULL اگر نام یافت نشود یا کاربر امکان مشاهده Met

تصویر دوم، جریان اجرای DB_ID را از ورودی و اعتبارسنجی تا تولید خروجی نمایش می‌دهد و نشان می‌دهد که current context در کدام مرحله باید کنترل شود.

ادامه مثال‌های پیشرفته DB_ID

مثال 5: مدیریت نام اشتباه

NULL حاصل از نام نادرست را قبل از استفاده مهار می‌کنیم. در این مثال، هدف تنها اجرای Query نیست؛ بلکه نشان دادن یک تصمیم فنی صحیح پیرامون DB_ID است.

DECLARE @DatabaseId int = DB_ID(N'a00bb');
        SELECT CASE
                   WHEN @DatabaseId IS NULL THEN N'نام پایگاه داده نامعتبر است'
                   ELSE CONVERT(nvarchar(20), @DatabaseId)
               END AS ValidationResult;
ValidationResult
نام پایگاه داده نامعتبر است

اشتباه تایپی نباید به Query گسترده یا Context ناخواسته منجر شود. این نکته از تفسیر سطحی یا استفاده تکراری و بی‌هدف از DB_ID جلوگیری می‌کند.

مثال 6: مقایسه نام و شناسه

رفت‌وبرگشت DB_ID و DB_NAME را کنترل می‌کنیم. در این مثال، هدف تنها اجرای Query نیست؛ بلکه نشان دادن یک تصمیم فنی صحیح پیرامون DB_ID است.

DECLARE @DatabaseName sysname = N'a00b';
        SELECT @DatabaseName AS InputName,
               DB_ID(@DatabaseName) AS DatabaseId,
               DB_NAME(DB_ID(@DatabaseName)) AS ResolvedName;
InputNameDatabaseIdResolvedName
a00b7a00b

این الگو برای اعتبارسنجی Mapping مناسب است. این نکته از تفسیر سطحی یا استفاده تکراری و بی‌هدف از DB_ID جلوگیری می‌کند.

مثال 7: ثبت شناسه در Snapshot

شناسه و زمان Capture را در جدول موقت نگه می‌داریم. در این مثال، هدف تنها اجرای Query نیست؛ بلکه نشان دادن یک تصمیم فنی صحیح پیرامون DB_ID است.

CREATE TABLE #DatabaseSnapshot
        (
            DatabaseId int NOT NULL,
            CapturedAt datetime2(0) NOT NULL
        );
        
        INSERT INTO #DatabaseSnapshot
        VALUES (DB_ID(), SYSDATETIME());
        
        SELECT * FROM #DatabaseSnapshot;
DatabaseIdCapturedAt
72026-07-25 00:10:00

شناسه را همراه نام یا زمان نگه دارید؛ به‌تنهایی شناسه کسب‌وکاری نیست. این نکته از تفسیر سطحی یا استفاده تکراری و بی‌هدف از DB_ID جلوگیری می‌کند.

مثال 8: جلوگیری از اجرای اشتباه

اسکریپت فقط در Database مورد انتظار ادامه می‌یابد. در این مثال، هدف تنها اجرای Query نیست؛ بلکه نشان دادن یک تصمیم فنی صحیح پیرامون DB_ID است.

IF DB_ID() <> DB_ID(N'a00b')
            THROW 51002, N'Context اجرای اسکریپت صحیح نیست.', 1;
        
        SELECT N'شناسه Context تأیید شد' AS Result;
Result
شناسه Context تأیید شد

کنترل نام و شناسه هر دو می‌توانند در Migration حساس استفاده شوند. این نکته از تفسیر سطحی یا استفاده تکراری و بی‌هدف از DB_ID جلوگیری می‌کند.

مثال 9: روش ناکارا و نسخه بهتر

برای فهرست همه Databaseها از ستون آماده sys.databases استفاده می‌کنیم. در این مثال، هدف تنها اجرای Query نیست؛ بلکه نشان دادن یک تصمیم فنی صحیح پیرامون DB_ID است.

SELECT d.database_id, d.name
        FROM sys.databases AS d
        WHERE d.database_id = DB_ID(N'a00b');
database_idname
7a00b

DB_ID برای یک نام مناسب است؛ برای تبدیل ردیف‌به‌ردیف، ستون کاتالوگ بهتر است. این نکته از تفسیر سطحی یا استفاده تکراری و بی‌هدف از DB_ID جلوگیری می‌کند.

مثال 10: پارامتر ایمن برای رویه مدیریتی

نام ورودی را به شناسه معتبر تبدیل و سپس Query را اجرا می‌کنیم. در این مثال، هدف تنها اجرای Query نیست؛ بلکه نشان دادن یک تصمیم فنی صحیح پیرامون DB_ID است.

DECLARE @RequestedDatabase sysname = N'a00b';
        DECLARE @RequestedId int = DB_ID(@RequestedDatabase);
        
        IF @RequestedId IS NULL
            THROW 51003, N'پایگاه داده درخواستی یافت نشد.', 1;
        
        SELECT database_id, name, state_desc
        FROM sys.databases
        WHERE database_id = @RequestedId;
database_idnamestate_desc
7a00bONLINE

اعتبارسنجی شناسه از ساخت SQL پویا برای این گزارش جلوگیری می‌کند. این نکته از تفسیر سطحی یا استفاده تکراری و بی‌هدف از DB_ID جلوگیری می‌کند.

خطاهای رایج در کار با DB_ID

خطای 1 در استفاده از DB_ID

قبل از ارسال نتیجه به DMVهای پرهزینه، NULL بودن آن را بررسی کنید. برای رفع این مشکل، ورودی و Context را از منبع معتبر بخوانید و نتیجه DB_ID را پیش از ادامه منطق با شرط صریح کنترل کنید.

خطای 2 در استفاده از DB_ID

نام پایگاه داده را به صورت Unicode و با پیشوند N بنویسید. برای رفع این مشکل، ورودی و Context را از منبع معتبر بخوانید و نتیجه DB_ID را پیش از ادامه منطق با شرط صریح کنترل کنید.

خطای 3 در استفاده از DB_ID

شناسه پایگاه داده پس از حذف و ایجاد مجدد می‌تواند تغییر کند؛ آن را به‌عنوان شناسه کسب‌وکاری ذخیره نکنید. برای رفع این مشکل، ورودی و Context را از منبع معتبر بخوانید و نتیجه DB_ID را پیش از ادامه منطق با شرط صریح کنترل کنید.

ملاحظات Performance برای DB_ID

از نظر کارایی، DB_ID زمانی کم‌هزینه باقی می‌ماند که روی یک مقدار هدفمند یا مجموعه محدود اجرا شود. فراخوانی آن روی هزاران ردیف بدون Predicate اولیه می‌تواند CPU و زمان گزارش را افزایش دهد.

اگر گزارش به چند Property از چندین شیء نیاز دارد، استفاده Set-based از کاتالوگ‌ویو یا DMV مرتبط با database name معمولاً بهتر از تکرار DB_ID برای هر سلول است.

در Jobهای دوره‌ای، نتیجه DB_ID را همراه Timestamp ذخیره کنید، اما Frequency نمونه‌برداری را متناسب با سرعت تغییر داده انتخاب کنید. جمع‌آوری بیش از حد، جدول تاریخچه را بدون ارزش تحلیلی بزرگ می‌کند.

برای محاسبات عددی پیرامون DB_ID، نوع داده را قبل از ضرب یا تفریق ارتقا دهید و در سناریوهای تجمعی، Restart و بازنشانی Baseline را در نظر بگیرید.

Best Practiceهای اختصاصی DB_ID

  1. ورودی DB_ID را از نام یا شناسه معتبر و دارای Schema یا Context روشن تأمین کنید.
  2. نتیجه NULL در DB_ID را از مقدار صفر، false یا رشته خالی جدا نگه دارید.
  3. نوع خروجی DB_ID را پیش از ذخیره یا مقایسه به نوع مقصد مناسب تبدیل کنید.
  4. در گزارش‌های بزرگ، گزینه Set-based مرتبط با database name را ارزیابی کنید.
  5. زمان Capture، نام Database و در صورت نیاز @@SPID را کنار نتیجه DB_ID ثبت کنید.
  6. مجوز مشاهده Metadata یا DMV را با حداقل سطح دسترسی لازم تنظیم کنید. در مبحث DB_ID
  7. مثال‌های DB_ID را روی نسخه و Edition واقعی محیط هدف آزمایش کنید.
  8. برای SQL پویا، خروجی نامی DB_ID را با QUOTENAME و پارامترسازی ایمن مصرف کنید.
سناریوی عملی و بهینه‌سازی DB_ID در SQL Serverنمودار فنی اختصاصی DB_ID شامل database name، database_id، sys.databases، DMV filtering، current contextروش پرخطرBest PracticeDB_IDقبل از ارسال نتیجه به DMVهای پرهزینه، NULL بودنام پایگاه داده را به صورت Unicode و با پیشوندتفسیر خام DB_IDفیلتر گزارش ایندکسdatabase namecurrent context

تصویر سوم، تفاوت روش پرخطر و Best Practice در استفاده از DB_ID را مقایسه می‌کند؛ هدف آن جلوگیری از خطاهای مربوط به قبل از ارسال نتیجه به DMVهای پرهزینه، NULL بودن آن را بررسی کنید. و بهبود تصمیم‌گیری فنی است.

سؤالات متداول اختصاصی DB_ID

DB_ID دقیقاً چه مسئله‌ای را در SQL Server حل می‌کند؟

تابع DB_ID نام یک پایگاه داده را به شناسه عددی آن تبدیل می‌کند و بدون پارامتر شناسه پایگاه داده جاری را برمی‌گرداند. در عمل، برای فیلتر DMVها، ارجاع به توابع مدیریتی و کنترل وجود پایگاه داده از DB_ID استفاده می‌شود. بنابراین استفاده از DB_ID زمانی ارزشمند است که خروجی آن در یک تصمیم فنی روشن مصرف شود، نه اینکه فقط برای نمایش عدد یا نام به کار رود.

نوع خروجی DB_ID چیست و چگونه باید آن را مدیریت کرد؟

نوع خروجی این ابزار چنین است: int یا NULL اگر نام یافت نشود یا کاربر امکان مشاهده Metadata مربوط را نداشته باشد. بهتر است پیش از تبدیل نوع، مقایسه یا درج در جدول گزارش، حالت NULL و محدوده مقدار را صریح کنترل کنید تا رفتار DB_ID قابل پیش‌بینی بماند.

آیا DB_ID در گزارش‌های سازمانی کاربرد تجاری دارد؟

بله. در سناریوهایی مانند فیلتر گزارش ایندکس و کنترل وجود Database، خروجی DB_ID می‌تواند کیفیت گزارش مدیریتی را بالا ببرد. ارزش تجاری زمانی ایجاد می‌شود که این داده به هشدار، ظرفیت‌سنجی یا کاهش زمان عیب‌یابی متصل شود.

استفاده از DB_ID در پروژه‌های بزرگ چه مزیتی دارد؟

در پروژه بزرگ، استانداردسازی نحوه استفاده از DB_ID باعث می‌شود تیم توسعه، DBA و پشتیبانی یک تعریف مشترک از database name و database_id داشته باشند. این هماهنگی خطاهای تفسیر و دوباره‌کاری را کاهش می‌دهد.

تفاوت DB_ID با گزینه نزدیک آن چیست؟

DB_ID از نام به شناسه می‌رود و DB_NAME از شناسه به نام. انتخاب صحیح باید بر اساس حجم داده، نیاز به خروجی Set-based و سطح جزئیات گزارش انجام شود؛ یک تابع scalar همیشه جایگزین کاتالوگ‌ویو یا DMV کامل نیست.

برای طراحی اسکریپت حرفه‌ای مبتنی بر DB_ID چه خدماتی لازم می‌شود؟

در پروژه‌های حساس می‌توان منطق DB_ID را در قالب رویه مانیتورینگ، Dashboard، گزارش زمان‌بندی‌شده یا کنترل Deployment پیاده کرد. تحلیل نیاز، تست روی نسخه واقعی SQL Server و مستندسازی خروجی، بخش‌های مهم خدمات مشاوره و انجام پروژه هستند.

رایج‌ترین خطا هنگام کار با DB_ID چیست؟

یکی از خطاهای مهم این است که قبل از ارسال نتیجه به DMVهای پرهزینه، NULL بودن آن را بررسی کنید. همچنین نادیده گرفتن NULL یا Context اجرای Query می‌تواند نتیجه‌ای ظاهراً معتبر ولی از نظر عملیاتی اشتباه تولید کند.

آیا فراخوانی زیاد DB_ID بر Performance اثر می‌گذارد؟

یک فراخوانی منفرد معمولاً سبک است، اما اجرای DB_ID روی مجموعه بسیار بزرگ یا در شرطی که برای هر ردیف محاسبه شود می‌تواند هزینه ایجاد کند. ابتدا ردیف‌ها را محدود کنید و در گزارش‌های وسیع، جایگزین Set-based را ارزیابی کنید.

بهترین روش استفاده از DB_ID چیست؟

بهترین روش این است که ورودی DB_ID اعتبارسنجی، نوع خروجی صریح، حالت NULL مدیریت و نتیجه همراه زمان و Context ثبت شود. همچنین باید مشخص باشد که خروجی برای نمایش، کنترل ایمنی یا تصمیم کارایی مصرف می‌شود.

DB_ID با کدام نسخه‌های SQL Server سازگار است؟

رفتار پایه در نسخه‌های SQL Server ثابت است؛ محدودیت‌های محیط Azure باید جداگانه بررسی شود. با این حال، هنگام انتقال اسکریپت به Azure SQL یا Edition دیگر، Propertyها، مجوزهای Metadata و تفاوت‌های پلتفرم را روی همان محیط آزمایش کنید.

سؤالات مصاحبه درباره DB_ID

در مصاحبه چگونه تفاوت ورودی و خروجی DB_ID را توضیح می‌دهید؟

پاسخ مناسب باید Syntax یعنی DB_ID ( [ N'database_name' ] )، نوع خروجی و شرایط NULL را توضیح دهد و یک نمونه از فیلتر گزارش ایندکس ارائه کند.

چه زمانی به‌جای DB_ID از کاتالوگ‌ویو یا DMV استفاده می‌کنید؟

وقتی گزارش چندین ردیف و چند Property نیاز دارد، روش Set-based معمولاً مناسب‌تر است؛ DB_ID برای تبدیل یا بررسی هدفمند یک مقدار بسیار خواناست.

چگونه نتیجه نامعتبر DB_ID را از مقدار false یا صفر جدا می‌کنید؟

با بررسی صریح IS NULL، اعتبارسنجی ورودی و در صورت نیاز Join با Metadata منبع، علت نتیجه را روشن می‌کنم. این توضیح به‌طور اختصاصی به DB_ID مربوط است.

چه نکته Performance درباره DB_ID مهم است؟

فراخوانی را پس از محدود کردن مجموعه داده انجام می‌دهم و از محاسبه تکراری DB_ID در SELECT و WHERE جلوگیری می‌کنم.

یک سناریوی واقعی برای DB_ID بیان کنید.

سناریوی مناسب می‌تواند ثبت شناسه Context باشد؛ در آن خروجی همراه Timestamp، نام Database و شناسه نشست ثبت می‌شود تا قابل پیگیری باشد.

چک‌لیست نهایی استفاده از DB_ID

  • Syntax DB_ID و ورودی‌های آن با نسخه هدف تطبیق داده شده است.
  • Context پایگاه داده یا Instance برای DB_ID روشن است.
  • مجوز لازم برای Metadata یا DMV بررسی شده است. در مبحث DB_ID
  • NULL، مقدار نامعتبر و حالت مرزی DB_ID تست شده است.
  • نمونه خروجی با نوع داده واقعی مقایسه شده است. در مبحث DB_ID
  • در Query بزرگ، هزینه فراخوانی تکراری DB_ID اندازه‌گیری شده است.
  • جایگزین Set-based برای گزارش انبوه ارزیابی شده است. در مبحث DB_ID
  • نتیجه نهایی همراه Timestamp و توضیح عملیاتی ثبت می‌شود. در مبحث DB_ID

جمع‌بندی آموزش DB_ID

DB_ID ابزاری کوچک اما مؤثر برای برای فیلتر DMVها، ارجاع به توابع مدیریتی و کنترل وجود پایگاه داده از DB_ID استفاده می‌شود. است. استفاده حرفه‌ای از آن به اعتبارسنجی ورودی، تفسیر نوع خروجی، کنترل NULL و انتخاب Scope مناسب وابسته است.

پس از تسلط بر DB_ID، برای مقایسه آن با سایر ابزارهای این مجموعه به مقاله مادر توابع کمکی Performance و Metadata در SQL Server بازگردید.

خدمات برنامه‌نویسی و پایگاه داده

برنامه‌نویسی در اصفهان

قبول سفارش‌های برنامه‌نویسی و پایگاه داده: 09131253620

انجام پروژه‌های برنامه‌نویسی، آموزش برنامه‌نویسی و آموزش پایگاه داده SQL Server با رویکرد حرفه‌ای، مستند و قابل توسعه انجام می‌شود.

مجموعه‌ای معتبر با سابقه فعالیت حرفه‌ای از سال ۱۳۷۵ شمسی

از سال ۱۳۷۵ شمسی تاکنون در زمینه طراحی و اجرای پروژه‌های برنامه‌نویسی، پایگاه داده، سیستم‌های تحت وب، وب‌سایت و راهکارهای نرم‌افزاری فعالیت می‌کنیم.

برای سفارش پروژه‌های برنامه‌نویسی و پایگاه داده، سیستم‌های تحت وب، وب‌سایت و راهکارهای نرم‌افزاری جدید، با شماره تلفن همراه 09131253620 تماس حاصل فرمایید.

ایتا، واتساپ و تماس مستقیم: +989131253620

تماس با ما

 

0 نظر

نظر محترم شما در مورد مقاله های وب سایت برنامه نویسی و پایگاه داده

نظرات محترم شما در خدمات رسانی بهتر ما را یاری می نمایند. لطفا اگر مایل بودید یک نظر ما را مهمان فرمائید. آدرس ایمیل و وب سایت شما نمایش داده نخواهد شد.

حرف 500 حداکثر