آموزش sys.query_store_plan_feedback در SQL Server با ۱۰ مثال عملی، خطاها و نکات Performance

آموزش sys.query_store_plan_feedback در SQL Server با ۱۰ مثال عملی

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

نظرات 0

آموزش جامع sys.query_store_plan_feedback در SQL Server؛ از ساختار تا تحلیل عملی

sys.query_store_plan_feedback یکی از موضوع‌های تخصصی خانواده Query Store است که برای بازخورد هوشمند روی طرح‌ها به‌کار می‌رود. این مقاله از تعریف و ستون‌ها آغاز می‌کند، رابطه آن را با سایر نماها توضیح می‌دهد و سپس ده مثال مستقل، خروجی نمونه، خطاهای رایج و نکات کارایی را ارائه می‌دهد.

نسخه و سازگاری: SQL Server 2022 و نسخه‌های بعدی. همه Queryها باید در همان پایگاه داده‌ای اجرا شوند که Query Store آن مورد بررسی است. برای بازگشت به نقشه کامل این مجموعه، راهنمای جامع نماهای کاتالوگ Query Store را مطالعه کنید.

sys.query_store_plan_feedback چیست و چه اطلاعاتی می‌دهد؟

اطلاعات بازخوردهای Memory Grant، CE، DOP و قابلیت‌های جدیدتر بهینه‌سازی را برای planها نگهداری می‌کند. در عمل، این نما بخشی از زنجیره‌ای است که از متن Query شروع می‌شود، به هویت منطقی و طرح اجرایی می‌رسد و در نهایت آمار اجرا، انتظارها یا تنظیمات مدیریتی را قابل مشاهده می‌کند.

کاربرد محوری این مقاله، بررسی اینکه موتور چرا و چگونه برای یک طرح بازخورد کارایی ثبت کرده و وضعیت آن اکنون چیست. است. نتیجه مطلوب فقط نمایش چند ردیف نیست؛ هدف این است که مدیر پایگاه داده بتواند از داده کاتالوگی به یک فرضیه قابل آزمون و سپس یک اقدام کم‌ریسک برسد.

نکته مهم: وجود Feedback به‌تنهایی به معنی موفقیت قطعی نیست؛ state، زمان آخرین تغییر و آمار اجرا باید کنار هم دیده شوند.

ساختار، ستون‌های کلیدی و ارتباط‌ها

ستون‌های مهم این نما عبارت‌اند از plan_feedback_id، plan_id، feature_id، feature_desc، state، state_desc، feedback_data، create_time، last_updated_time. همه ستون‌ها در هر سناریو لازم نیستند؛ انتخاب باید بر اساس سؤال تحلیلی انجام شود.

  • plan_feedback_id: یکی از ستون‌های کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
  • plan_id: یکی از ستون‌های کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
  • feature_id: یکی از ستون‌های کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
  • feature_desc: یکی از ستون‌های کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
  • state: یکی از ستون‌های کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
  • state_desc: یکی از ستون‌های کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.

رابطه اصلی با سایر نماها چنین است: با plan_id به sys.query_store_plan و از آنجا به query متصل می‌شود. این رابطه باید با کلیدهای رسمی برقرار شود تا ضرب ردیف، شمارش تکراری یا نسبت‌دادن اشتباه آمار رخ ندهد.

بخشنقش در تحلیلنکته اجرایی
هویتplan_feedback_idبرای فیلتر و Join از کلید مناسب استفاده شود
مقدار اصلیplan_idفقط در صورت نیاز به لایه نمایش منتقل شود
ارتباطبا plan_id به sys.query_store_plan و از آنجا به query متصل می‌شود.Join صریح و قابل ممیزی نوشته شود
نسخهSQL Server 2022 و نسخه‌های بعدیپیش از اجرا سازگاری کنترل شود
نقشه مفهومی sys.query_store_plan_feedbackاجزای اصلی، کلیدها و ارتباط‌های کاتالوگی برای sys.query_store_plan_feedback sys.query_store_plan_feedback plan_feedback_idکلید و هویت plan_idداده تحلیلی feature_idاتصال مرتبط feature_descفیلتر و محدودسازی stateخطای قابل کنترل sys.query_store_plan_feedbackخروجی عملیاتی ارتباط کلیدها، داده‌ها و تصمیم مدیریتی در sys.query_store_plan_feedback

تصویر نخست، جایگاه sys.query_store_plan_feedback، ستون‌های محوری و مسیر ارتباط آن با تحلیل Query Store را نشان می‌دهد.

نحو پایه و پیش‌نیازهای دسترسی

این موضوع یک Catalog View است و مانند جدول با SELECT خوانده می‌شود. نام قابل استفاده در Queryهای این مقاله «sys.query_store_plan_feedback» است.

SELECT TOP (20)
    plan_feedback_id,
    plan_id
FROM sys.query_store_plan_feedback
ORDER BY plan_feedback_id DESC;

برای مشاهده داده‌های Query Store معمولاً مجوزهای مشاهده وضعیت یا عملکرد پایگاه داده لازم است. سطح مجوز دقیق به نسخه SQL Server وابسته است؛ بنابراین اسکریپت تولیدی بهتر است با حساب کم‌اختیار آزمایش و سپس حداقل مجوز لازم مستند شود.

ده مثال عملی و مستقل

مثال 1: نمایش نمونه ردیف‌ها

در نخستین گام، ساختار واقعی sys.query_store_plan_feedback را با تعداد محدودی ردیف مشاهده می‌کنیم تا نام ستون‌ها و شکل داده روشن شود.

SELECT TOP (10) *
FROM sys.query_store_plan_feedback
ORDER BY 1 DESC;
خروجی نمونهتوضیح
ردیف‌های بازگشتیحداکثر ۱۰
هدفشناخت ساختار نما

نکته کاربردی: در محیط عملی بهتر است به‌جای ستاره فقط ستون‌های لازم انتخاب شوند؛ این مثال عمداً برای شناسایی سریع ساختار نوشته شده است.

مثال 2: انتخاب ستون‌های کلیدی plan_feedback_id و plan_id

این نمونه فقط دو ستون محوری plan_feedback_id و plan_id را می‌خواند تا نتیجه کوچک، قابل بررسی و مناسب ابزارهای مانیتورینگ باشد.

SELECT TOP (20)
    plan_feedback_id,
    plan_id
FROM sys.query_store_plan_feedback
ORDER BY plan_feedback_id DESC;
خروجی نمونهتوضیح
plan_feedback_idشناسه یا مقدار کلیدی
plan_idویژگی اصلی تحلیل

نکته کاربردی: انتخاب ستون صریح هم خوانایی را بیشتر می‌کند و هم مانع انتقال داده‌های سنگین یا غیرضروری می‌شود.

مثال 3: استفاده از فیلتر هدفمند

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

DECLARE @TargetId bigint = 1;

SELECT *
FROM sys.query_store_plan_feedback
WHERE plan_feedback_id = @TargetId;
خروجی نمونهتوضیح
شرطplan_feedback_id = 1
نتیجهردیف مرتبط در صورت وجود

نکته کاربردی: در گزارش‌های واقعی، شناسه هدف معمولاً از مرحله قبلی تحلیل Query Store یا از یک داشبورد انتخاب می‌شود.

جریان داده sys.query_store_plan_feedbackمسیر حرکت از ورودی Query Store تا خروجی تحلیلی برای sys.query_store_plan_feedback جریان تحلیل sys.query_store_plan_feedback ورودیplan_feedback_id فیلترplan_id اتصالfeature_id محاسبهfeature_desc خروجیگزارش کنترل میانیstate اعتبارسنجیsys.query_store_plan_feedback از داده خام Query Store تا تصمیم قابل اجرا

تصویر دوم، جریان انتخاب داده، فیلتر، اتصال و تبدیل خروجی sys.query_store_plan_feedback به گزارش فنی را نمایش می‌دهد.

مثال 4: اتصال به نمای مکمل

ارزش sys.query_store_plan_feedback زمانی بیشتر می‌شود که کلیدهای آن با نمای مکمل Query Store متصل شوند. این Query رابطه اصلی مقاله را به‌صورت عملی نشان می‌دهد.

SELECT TOP (25)
    f.plan_feedback_id,
    f.plan_id,
    f.feature_desc,
    f.state_desc,
    p.query_id
FROM sys.query_store_plan_feedback AS f
INNER JOIN sys.query_store_plan AS p
    ON p.plan_id = f.plan_id
ORDER BY f.last_updated_time DESC;
خروجی نمونهتوضیح
نوع تحلیلJoin کاتالوگی
رابطهبا plan_id به sys.query_store_plan و از آنجا به query متصل می‌شود.

نکته کاربردی: Join باید روی کلید مستندشده انجام شود؛ اتصال بر اساس متن، زمان تقریبی یا ستون‌های غیرکلیدی می‌تواند ردیف‌های تکراری و نتیجه گمراه‌کننده بسازد.

مثال 5: مدیریت نتیجه خالی و NULL

برخی ستون‌ها ممکن است NULL باشند یا نمای هدف هیچ ردیفی نداشته باشد. با COALESCE می‌توان خروجی نمایشی کنترل‌شده‌ای برای گزارش ساخت.

SELECT TOP (20)
    plan_feedback_id,
    COALESCE(CONVERT(nvarchar(4000), plan_id), N'بدون مقدار') AS safe_value
FROM sys.query_store_plan_feedback
ORDER BY plan_feedback_id DESC;
خروجی نمونهتوضیح
plan_feedback_idنمونه شناسه
safe_valueمقدار واقعی یا «بدون مقدار»

نکته کاربردی: COALESCE برای نمایش مناسب است؛ اما نباید نوع داده و معنای NULL را در منطق تحلیلی پنهان کند.

مثال 6: کنترل سازگاری نسخه پیش از اجرا

از آنجا که دسترس‌پذیری sys.query_store_plan_feedback به نسخه SQL Server وابسته است، Query زیر پیش از خواندن نما وجود آن را بررسی می‌کند.

IF OBJECT_ID(N'sys.query_store_plan_feedback', N'V') IS NULL
BEGIN
    SELECT N'این نما در نسخه یا پیکربندی فعلی در دسترس نیست.' AS message;
END
ELSE
BEGIN
    SELECT TOP (5) *
    FROM sys.query_store_plan_feedback;
END;
خروجی نمونهتوضیح
حالت اولنما موجود است و نمونه داده خوانده می‌شود
حالت دومپیام سازگاری بازگردانده می‌شود

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

مثال 7: سناریوی واقعی عیب‌یابی

بررسی اینکه موتور چرا و چگونه برای یک طرح بازخورد کارایی ثبت کرده و وضعیت آن اکنون چیست.

SELECT
    feature_desc,
    state_desc,
    COUNT_BIG(*) AS feedback_count
FROM sys.query_store_plan_feedback
GROUP BY feature_desc, state_desc
ORDER BY feedback_count DESC;
خروجی نمونهتوضیح
سناریوبررسی اینکه موتور چرا و چگونه برای یک طرح بازخورد کارایی ثبت کرده و وضعیت آن اکنون چیست.
خروجیفهرست اولویت‌دار برای اقدام

نکته کاربردی: این خروجی نقطه شروع بررسی است؛ تصمیم نهایی باید با متن Query، طرح، آمار اجرا و شرایط محیط تولید تطبیق داده شود.

سناریوی کارایی sys.query_store_plan_feedbackمقایسه روش صحیح، خطاهای رایج و تصمیم کارایی برای sys.query_store_plan_feedback تصمیم کارایی برای sys.query_store_plan_feedback روش پرریسکخواندن گسترده plan_feedback_id روش پیشنهادیفیلتر هدفمند plan_id پیامدfeature_id خطاfeature_desc معیارstate نتیجهsys.query_store_plan_feedback فیلتر، Join صحیح و تفسیر مبتنی بر بازه زمانی

تصویر سوم، تفاوت خواندن گسترده با روش فیلترشده و قابل اتکا برای sys.query_store_plan_feedback را مقایسه می‌کند.

مثال 8: روش اشتباه و نسخه اصلاح‌شده

خواندن بدون محدودیت تمام ستون‌ها از sys.query_store_plan_feedback در یک Job پرتکرار می‌تواند هزینه غیرضروری بسازد. نسخه اصلاح‌شده فقط ستون و ردیف لازم را دریافت می‌کند.

-- روش نامناسب برای اجرای پرتکرار
SELECT *
FROM sys.query_store_plan_feedback;

-- نسخه کنترل‌شده
SELECT TOP (100)
    plan_feedback_id,
    plan_id
FROM sys.query_store_plan_feedback
WHERE plan_feedback_id IS NOT NULL
ORDER BY plan_feedback_id DESC;
خروجی نمونهتوضیح
روش نامناسبحجم خروجی نامحدود
روش اصلاح‌شدهستون و تعداد ردیف کنترل‌شده

نکته کاربردی: وجود Feedback به‌تنهایی به معنی موفقیت قطعی نیست؛ state، زمان آخرین تغییر و آمار اجرا باید کنار هم دیده شوند.

مثال 9: الگوی مناسب برای داشبورد کارایی

برای داشبورد، ابتدا آخرین یا مهم‌ترین ردیف‌ها از sys.query_store_plan_feedback انتخاب می‌شوند و تنها خروجی جمع‌وجور به لایه نمایش منتقل می‌شود.

DECLARE @RowLimit int = 50;

SELECT TOP (@RowLimit)
    plan_feedback_id,
    plan_id
FROM sys.query_store_plan_feedback
WHERE plan_feedback_id IS NOT NULL
ORDER BY plan_feedback_id DESC
OPTION (RECOMPILE);
خروجی نمونهتوضیح
حد ردیف۵۰
هدفپاسخ سریع و قابل پیش‌بینی

نکته کاربردی: feedback_data را فقط برای planهای منتخب واکشی کنید و اثر قبل و بعد را در بازه‌های زمانی مقایسه کنید.

مثال 10: اعتبارسنجی خروجی برای اتوماسیون

آخرین مثال تعداد ردیف‌های قابل استفاده را در یک متغیر می‌ریزد تا Job یا ابزار مانیتورینگ بتواند وضعیت sys.query_store_plan_feedback را به‌صورت صریح گزارش کند.

DECLARE @AvailableRows bigint;

SELECT @AvailableRows = COUNT_BIG(*)
FROM sys.query_store_plan_feedback;

SELECT
    @AvailableRows AS available_rows,
    CASE
        WHEN @AvailableRows = 0 THEN N'داده‌ای ثبت نشده است'
        ELSE N'داده برای تحلیل موجود است'
    END AS status_message;
خروجی نمونهتوضیح
available_rowsتعداد ردیف
status_messageپیام قابل استفاده در مانیتورینگ

نکته کاربردی: در سامانه هشدار بهتر است وضعیت Query Store، زمان آخرین Capture و علت خالی بودن احتمالی نیز همراه این عدد ذخیره شود.

خطاهای رایج

  • فرض اینکه هر ردیف sys.query_store_plan_feedback به‌تنهایی تصویر کامل عملکرد را نشان می‌دهد؛ در حالی که Join با لایه‌های مرتبط لازم است.
  • وجود Feedback به‌تنهایی به معنی موفقیت قطعی نیست؛ state، زمان آخرین تغییر و آمار اجرا باید کنار هم دیده شوند.
  • جمع‌کردن میانگین‌ها بدون توجه به وزن تعداد اجرا یا بازه زمانی.
  • اجرای Query بدون فیلتر روی پایگاه داده پرترافیک و انتقال خروجی حجیم به ابزار گزارش‌گیری.
  • نادیده‌گرفتن تفاوت نسخه‌ها و استفاده از ستون یا نمایی که در مقصد وجود ندارد.

ملاحظات کارایی و بهترین روش‌ها

feedback_data را فقط برای planهای منتخب واکشی کنید و اثر قبل و بعد را در بازه‌های زمانی مقایسه کنید.

  1. سؤال تحلیلی را قبل از نوشتن Query مشخص کنید؛ گزارش بدون سؤال فقط حجم داده تولید می‌کند.
  2. ابتدا شناسه‌ها و بازه‌های لازم را محدود کنید و ستون‌های سنگین را در مرحله آخر بخوانید.
  3. برای روندهای تاریخی، Snapshot کنترل‌شده با زمان نمونه‌برداری بسازید و از کپی کامل داده خام بپرهیزید.
  4. Query تحلیلی را روی محیط مشابه تولید آزمایش کنید و هزینه IO، CPU و زمان را ثبت کنید.
  5. هر Hint، Plan Forcing یا تغییر تنظیمات را با خط مبنا، مسئول تغییر و برنامه بازگشت مستند کنید.

کاربرد در یک پروژه واقعی

فرض کنید سامانه فروش در ساعات اوج کند می‌شود. تیم پشتیبانی ابتدا query_id یا plan_idهای پرهزینه را پیدا می‌کند، سپس از sys.query_store_plan_feedback برای بررسی اینکه موتور چرا و چگونه برای یک طرح بازخورد کارایی ثبت کرده و وضعیت آن اکنون چیست. استفاده می‌کند. خروجی با متن Query، Plan، آمار Runtime و Waitها تطبیق داده می‌شود تا مشخص شود مشکل از تغییر طرح، افزایش حجم، قفل، IO، حافظه یا تنظیم مدیریتی است.

در مرحله بعد یک گزارش دوره‌ای ساخته می‌شود که فقط انحراف‌های معنادار را نگهداری می‌کند. این رویکرد از انباشته‌شدن داده بی‌مصرف جلوگیری می‌کند و زمان واکنش تیم را کاهش می‌دهد. معیار موفقیت نیز باید قابل اندازه‌گیری باشد؛ برای نمونه کاهش صدک ۹۵ مدت اجرا، افت CPU یا حذف بازگشت مکرر به طرح نامطلوب.

سؤالات متداول

sys.query_store_plan_feedback دقیقاً چه مسئله‌ای را حل می‌کند؟

این نما اطلاعات بازخوردهای Memory Grant، CE، DOP و قابلیت‌های جدیدتر بهینه‌سازی را برای planها نگهداری می‌کند. و برای تبدیل داده‌های داخلی Query Store به گزارش قابل تحلیل استفاده می‌شود.

برای شروع کار با sys.query_store_plan_feedback کدام ستون‌ها مهم‌ترند؟

ستون‌های plan_feedback_id، plan_id، feature_id، feature_desc نقطه شروع مناسبی هستند؛ سپس بر اساس سناریو ستون‌های تکمیلی افزوده می‌شوند.

آیا استفاده از sys.query_store_plan_feedback برای گزارش مدیریتی مناسب است؟

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

چطور می‌توان از داده sys.query_store_plan_feedback در پروژه سازمانی استفاده کرد؟

می‌توان یک Job جمع‌آوری، جدول Snapshot و داشبورد ساخت تا سناریوی «بررسی اینکه موتور چرا و چگونه برای یک طرح بازخورد کارایی ثبت کرده و وضعیت آن اکنون چیست.» به‌صورت دوره‌ای پایش شود.

sys.query_store_plan_feedback با نماهای دیگر Query Store چه تفاوتی دارد؟

تمرکز این نما روی «بازخورد هوشمند روی طرح‌ها» است؛ در حالی که نماهای متن، query، plan، runtime و wait هر کدام لایه متفاوتی از زنجیره تحلیل را ارائه می‌کنند.

برای پیاده‌سازی گزارش حرفه‌ای sys.query_store_plan_feedback چه خدمتی لازم است؟

طراحی Query، مدل نگهداری Snapshot، کنترل دسترسی، ساخت داشبورد و تعریف آستانه هشدار معمولاً به تحلیل و پیاده‌سازی تخصصی SQL Server نیاز دارد.

رایج‌ترین خطا در کار با sys.query_store_plan_feedback چیست؟

وجود Feedback به‌تنهایی به معنی موفقیت قطعی نیست؛ state، زمان آخرین تغییر و آمار اجرا باید کنار هم دیده شوند.

مهم‌ترین نکته Performance برای sys.query_store_plan_feedback چیست؟

feedback_data را فقط برای planهای منتخب واکشی کنید و اثر قبل و بعد را در بازه‌های زمانی مقایسه کنید.

بهترین روش نگهداری گزارش‌های مبتنی بر sys.query_store_plan_feedback چیست؟

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

sys.query_store_plan_feedback در چه نسخه‌هایی در دسترس است؟

SQL Server 2022 و نسخه‌های بعدی. پیش از استقرار اسکریپت روی چند سرور، وجود نما و ستون‌های مورد استفاده را کنترل کنید.

سؤالات مصاحبه SQL Server

  1. توضیح دهید sys.query_store_plan_feedback چه داده‌ای می‌دهد و در چه مرحله‌ای از تحلیل Query Store استفاده می‌شود.
  2. کلید اصلی اتصال sys.query_store_plan_feedback به نمای مکمل چیست و Join اشتباه چه اثری دارد؟
  3. چگونه یک Query پرهزینه روی sys.query_store_plan_feedback را به نسخه سبک‌تر تبدیل می‌کنید؟
  4. برای کنترل سازگاری نسخه sys.query_store_plan_feedback چه الگویی پیشنهاد می‌دهید؟
  5. چگونه نتیجه حاصل از sys.query_store_plan_feedback را با آمار Runtime یا Waitها اعتبارسنجی می‌کنید؟

چک‌لیست نهایی

  1. فعال بودن Query Store و وجود داده کنترل شده است.
  2. وجود نمای sys.query_store_plan_feedback و ستون‌های مورد استفاده بررسی شده است.
  3. فیلتر شناسه و بازه زمانی قبل از Joinهای سنگین اعمال شده است.
  4. خروجی نمونه با متن Query، Plan یا شاخص مکمل تطبیق داده شده است.
  5. نتیجه، فرضیه و اقدام پیشنهادی به‌صورت قابل ممیزی ثبت شده است.

جمع‌بندی

sys.query_store_plan_feedback برای بازخورد هوشمند روی طرح‌ها یک ابزار تخصصی و ارزشمند است. استفاده درست از آن نیازمند شناخت ستون‌ها، اتصال دقیق به سایر نماها، رعایت تفاوت نسخه‌ها و تفسیر داده در بستر زمان و بار کاری است. ده مثال این مقاله مسیر را از خواندن پایه تا گزارش عملیاتی و کنترل Performance پوشش داد.

برای مشاهده جایگاه این نما در کل معماری، به مقاله مادر نماهای کاتالوگ Query Store بازگردید.

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

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

انجام پروژه و آموزش تخصصی

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

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

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

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

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

تماس با ما

 

0 نظر

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

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

حرف 500 حداکثر