<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های مهدی نظارت</title>
        <link>https://virgool.io/feed/@nezarat</link>
        <description></description>
        <language>fa</language>
        <pubDate>2026-06-17 03:12:46</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/92851/avatar/o0iHMM.png?height=120&amp;width=120</url>
            <title>مهدی نظارت</title>
            <link>https://virgool.io/@nezarat</link>
        </image>

                    <item>
                <title>ساخت Tally Table در SQL</title>
                <link>https://virgool.io/@nezarat/%D8%B3%D8%A7%D8%AE%D8%AA-tally-table-%D8%AF%D8%B1-sql-r8qhea7qeqbr</link>
                <description>سلام به همگی بعد از مدتها با یه مطلب کاربردی خدمتتون اومدم و می خواهم در مورد جدول های شمارشی یا Tally Table با شما صحبت کنم .ابتدا بگذارید صورت مسئله را مطرح کنم ، فرض کنیم از یک پایگاه داده دیگه ای مثل اکسل یا اکسس یا ... جدولی با نام IMP را به SQL ایمپورت کردید که دارای ستون ردیف  با نام Rn هست و شما متوجه می شید که شماره ردیفها با تعداد رکوردها مطابقت نداره چرا که بعضی از ردیفها حذف شدن ! مثلا شماره ردیفها از 1 تا یک میلیون هست اما وقتی نتیجه Import را بررسی می کنید یا روی جدول مورد نظر  Select Count(*) را اجرا     می کنید ، می بینید که تعداد اونها 999,996 هست و چهار تا رکورد کم داره و باید شماره ردیفهایی که نیست را پیدا کنیم .در عمل و محیط تجاری و کاری ممکنه با این مشکل در شماره سریالهای فاکتور یک شرکت که باید ردیف و پشت سرهم باشه ، اما تعدادی از اونها نیست و بخاطر ملاحظات قانونی باید پیداشون کرد ، نبودن بعضی از شماره اسناد حسابداری در جداول بایگانی یا پیدا کردن ردیفهای حذف شده یک جدول بر اساس فیلد یکتای ( Identity ) آن و ... مواجه می شید و باید مسئله را حل کنید .خب حالا چطوری شماره ردیف هایی که نیست را پیدا کنیم ؟ جواب اینه که باید این جدول را با جدول دیگه ای که شماره ردیفهاش کامله ( اسم این جدول را می گذاریم SRC و فیلد ردیف اون را Line می نامیم ) جوین کرد تا ردیفهای مفقودی را پیدا کنیم مثلا :Select src.LineFrom SRCLeft join IMP on src.Line=IMP.RNWhere IMP.Rn is nullتوضیح تکمیلی اینکه اون جدول SRC با ستون Line  همان Tally Table یا جدول شمارشی هست و برای حل مسئله باید در پایگاه داده خودمون چنین جدولی داشته باشیم و حالا اگه نداریم چکار کنیم ؟دو تا راهکار هست که مشکل گشاستراه کار اول : با فرض اینکه تعداد ردیفهای جدول IMP کم هست مثلا زیر هزار تا و می خوایم ردیف های حذف شده را پیدا کنیم ، از یک جدول دیگه که تعداد ردیفهای مورد نظر ما را داره و  با کمک تابع Row_number جدول SRC را بصورت موقت می سازیم ، مثلا من اینجا از جدول sys.sysobjects خود SQL استفاده می کنم :Select Src.LineFrom (Select Line=Row_number()over(order by O1.Id)From sys.sysobjects O1) SRCLeft join IMP on IMP.Rn=Src.Linewhere IMP.Rn is nullراه کار دوم : اگه تعداد ردیفهای جدول IMP زیاد بود مثلا یک میلیون و ما جدولی با تعداد رکورد بالا نداریم یا نمی شناسیم تا از اون کمک بگیریم ، Cross Join را به کمک می طلبیم :Select Src.LineFrom (Select top 1000000Line=Row_number()over(order by O1.Id)From sys.sysobjects O1Cross Join Sys.sysobjects O2Order by O1. id) SRCleft join IMP on IMP.Rn=Src.Linewhere IMP.Rn is nullنکته اول : اگه جدول Sys.Sysobjects دارای 2000 تا رکورد باشه با اون Cross join  تعداد ردیفها ضرب دکارتی می شه و می شه 4 میلیون رکورد !نکته دوم : آیا به جای sys.sysobjects نمی تونیم از خود جدول IMP و Cross Join  استفاده کنیم ؟ اوه اوه ⛔ ، مراقب cross join  باشید چون اگه چنین کاری کنیم و جدول IMP شما یک میلیون رکورد داشته باشه و بخواهیم در Cross Join دوبار از این جدول استفاده کنیم، سرور SQL برای آماده سازی جدول SRC ، ابتدا باید در جدول داخلی یک تریلیون رکورد را تولید کنه ( Cross join  و ضرب دکارتی )، اون تعداد رکورد را مرتب کنه (order by) ، یک میلیونیم اون را بیرون بکشه ( Top 1000000 ) و با IMP بیرونی جوین کنه و در این بین حتما سکته خواهد کرد .نکته سوم : اگه جدول sysobjects  فقط 100 تا رکورد داشت چی ؟ می تونید چند بار اون را با خودش       Cross join کنید !امیدوارم این پست مفید بوده باشه و ارزش وقت شما را داشته باشه .💛</description>
                <category>مهدی نظارت</category>
                <author>مهدی نظارت</author>
                <pubDate>Fri, 07 Jun 2024 17:59:07 +0330</pubDate>
            </item>
                    <item>
                <title>خطای عجیب در اجرای یک ویو اس کیو ال</title>
                <link>https://virgool.io/@nezarat/%D8%AE%D8%B7%D8%A7%DB%8C-%D8%B9%D8%AC%DB%8C%D8%A8-%D8%AF%D8%B1-%D8%A7%D8%AC%D8%B1%D8%A7%DB%8C-%DB%8C%DA%A9-%D9%88%DB%8C%D9%88-%D8%A7%D8%B3-%DA%A9%DB%8C%D9%88-%D8%A7%D9%84-zby0uepsmb12</link>
                <description>سلام به همگی خیلی وقته اینجا چیزی ننوشتم، مشغله کاری و ذهنی اجازه نمی داد، به همین خاطر تصمیم گرفتم مطالبی که توی ذهنم هست را خیلی ساده و با زبان محاوره ای بیان کنم، شاید بدرد کسی خورد.امروز در محیط کار سخت مشغول بودم که یکی از کاربران گفت فلان فرم خطا می ده! طبق روال عادی فازهای  بررسی شخصی خطا در برنامه و تأیید حرف کاربر، اجرای پروفایلر، به چنگ آوردن اسکریپت اس کیو ال و در نهایت سلاخی اون اسکریپت تا بفهمم کدوم تیکش باعث و بانی هست؛ اجرا شد و در کمال تعجب چی پیدا کردم! اجرای یک ویو خطا می داد. یعنی چی؟ ویویی که درست بوده، روی دیتابیس دیگه کار می کنه چشه آخه! راه حلی که در مرحله اول به ذهن آدم می رسه اینه که کد های Select داخل ویو را جداگانه اجرا کنیم ببینیم مشکل کجاست که در کمال تعجب می بینیم هیچ خطایی وجود نداره، اما اجرای خود ویو خطاهای عجیب غریب تولید می کنه!پس مشکل کجاست؟  اگر ویو را Drop کنیم و دوباره بسازیم، مشکل ویو حل خواهد شد اما دلیل خطا را هنوز نفهمیدیم. با کنکاش بیشتر متوجه‌ می شیم بعضی از Object هایی که ویو به آنها وابستگی داشته (مثل جداولی که در Select بکار رفتن) تغییر کردن و به همین خاطر متادیتای ویو خراب شده و نمی تونه بدرستی اجرا بشه. خب، دفعه بعد که یک ویوی معیوب را پیدا کردید می تونید از دستور Sp_refreshview برای اصلاح کد اون استفاده کنید اما وقتی یه جدول را تغییر دادیم چطور بدونیم کدام ویوها نیاز به بروز رسانی دارند؟ با فرض تغییرات در جدول Person، کد زیر مشکل گشاست :USE AdventureWorks2012;  GO  SELECT DISTINCT &#x27;EXEC sp_refreshview &#x27;&#x27;&#x27; + name + &#x27;&#x27;&#x27;&#x27;   FROM sys.objects AS so   INNER JOIN sys.sql_expression_dependencies AS sed       ON so.object_id = sed.referencing_id   WHERE so.type = &#x27;V&#x27; AND sed.referenced_id = OBJECT_ID(&#x27;Person.Person&#x27;);سال نو شما مبارک ویرگولی ها :)   </description>
                <category>مهدی نظارت</category>
                <author>مهدی نظارت</author>
                <pubDate>Mon, 05 Apr 2021 21:17:08 +0430</pubDate>
            </item>
                    <item>
                <title>ورود داده ها از اکسل به اس کیو ال سرور</title>
                <link>https://virgool.io/@nezarat/%D9%88%D8%B1%D9%88%D8%AF-%D8%AF%D8%A7%D8%AF%D9%87-%D9%87%D8%A7-%D8%A7%D8%B2-%D8%A7%DA%A9%D8%B3%D9%84-%D8%A8%D9%87-%D8%A7%D8%B3-%DA%A9%DB%8C%D9%88-%D8%A7%D9%84-%D8%B3%D8%B1%D9%88%D8%B1-ij262lpnz0fb</link>
                <description>برنامه نویسان ، DBA ها و سایرینی که با Microsoft SQL Server  سر و کله می زنن همیشه درگیر این مسئله هستن که داده هایی را از فایل اکسل به پایگاه داده Import کنند یا برعکس از SQL داده ها را شوت کنن توی اکسل . این داده ها می تونه از یک سند حسابداری ساده ، لیست مشتریان و... تشکیل شده باشه . البته اینجا بحثم راجع به Import داده ها به SQL هست .وقتی SQL را نصب کنید و بعد از نصب ، SQL Server Management Studio یا SSMS مورد نظر را هم روی سرور یا کلاینت نصب کنید ( توی این ورژن های آخر نصب اونها جداگانه است ) می تونید از قابلیت Import داده ها توی SSMS استفاده کنید . نکته اینجاست که SQL یه Provider ( تأمین کننده ! ) قدیمی به نام Microsoft.Jet.OLEDB.4.0 برای ورود فایلهای اکسل و اکسس داره که بصورت استاندارد نصب می شه ولی تنها می تونه فایلهای اکسل یا اکسس 2003-97 را Import کنه و اگه فایلهای اکسل شما ورژن جدیدتر باشه باید آنها را به فرمت قدیمی تر Save as کنید و بعد ، از ویزارد SSMS برای ورود داده ها استفاده کنید .چه کنیم که از این فرایند عقب گرد نجات پیدا کنیم ؟ واقعا لازمه ؟! در جواب باید بگم که به حجم کارهای شما بستگی داره . اگه این مسئله ماهانه یکبار اتفاق می افته مسلمه که نیازی به راه حل جدید نیست اما اگر رویه روتینی برای شما هست باید به فکر چاره بود ، خودم مجبور بودم این کار را بکنم ، اوایل اهمیتی نداشت اما چون عادت دارم از فایلهایی که وارد SQL می کنم برای روز مبادا و تا مدت مشخصی پشتیبان تهیه کنم ، متوجه شدم که تعداد زیادی فایل اکسل مشابه با نگارشهای ( Version ) متفاوت روی سیستم من جا خوش کردن و روز به روز مدیریت کردنشون سخت تر می شه و از طرفی Save as کردن فایل اکسل هم در فرآیند کارهای جاری به یه رویداد تکراری کسل کننده تبدیل شده .خب راه حل :راه حل اینه که بریم سراغ Microsoft Access Connectivity Engine (ACE) و ورژن 2016 اون را نصب کنیم . اما یه نکته ظریفی این بین هست که یه مدت من را آزار می داد ، وقتی به صفحه دانلود برید و بخواهید این درایور را دانلود کنید ، امکان دانلود درایور 32 بیت یا 64 بیت را براتون فراهم می کنه ،            من ویندوزم 64 بیته ، طبیعی که میرم سراغ ورژن 64 بیت ، اون را دانلود و نصب می کنم و بعد از اون از طریق SSMS سعی به Import فایلهای اکسل می کنم که همانطور که در تصاویر بعدی می بینید به خطا       بر می خورم ؟!!!!!!!1 - کلیک راست روی دیتابیس و انتخاب گزینه Import2 - انتخاب دیتاسورس ، انتخاب فایل اکسل مورد نظر و کلیک روی Nextپیام خطا !!!!مشکل کجاست ؟ درایور درست نصب نشده ؟ در Control Panel  و توی Programs and Features  چک کنیم :پس مسئله چیه ؟!!! مسئله اینه که باید درایور 32 بیت را نصب کنید! جانم ! چرا ؟ چون SSMS و SSDT ( یا SQL Server Data Tools ) اپلیکیشن های 32 بیت هستند و درایور 64 بیتی که ما نصب می کنیم با اونها جفت نیست و وقتی از طریق SSMS بخواهید داده ها را وارد کنید ورژن 32 بیت اون اجرا می شه و درایور 64 بیت نصب شده را تشخیص نمی ده .البته بعد از نصب درایور 64 بیت اگه داخل Start Menu دنبال Data SQL Server Import and Export بگردید یه ورژن 64 بیت جدید مستقل از SSMS پیدا می کنید که فایلهای اکسل ورژن جدید را براتون Import می کنه ( پنجره ویزاردش هیچ تفاوتی با ورژن 32 بیتی نداره )، ولی اگه می خواید از این قابلیت در داخل خود SSMS استفاده کنید باید حتما نسخه 32 بیتی را هم نصب کنید . منتهی ورژن 32 بیت درایور 2016 با آفیس 64 بیت نمی خونه ! ( ای خداااااااا )و باید قید آفیس 64 بیت را بزنید:عدم تطابق اکسس دیتابیس انجین 2016 ورژن 32 بیت با آفیس 64 بیت یا ACE نگارش 32 بیت 2010  را نصب کنید ! در کمال تعجب و از داخل SSMS کار می کنه !!اینم از مایکروسافت ، مثل اینکه همه جای دنیا آسمون همین رنگه .</description>
                <category>مهدی نظارت</category>
                <author>مهدی نظارت</author>
                <pubDate>Sun, 26 Jan 2020 00:14:00 +0330</pubDate>
            </item>
                    <item>
                <title>دستورات Delete و Truncate در SQL</title>
                <link>https://virgool.io/@nezarat/%D8%AF%D8%B3%D8%AA%D9%88%D8%B1%D8%A7%D8%AA-delete-%D9%88-truncate-%D8%AF%D8%B1-sql-r7af7elme6vg</link>
                <description>Sql Delete , Truncate &amp; ...قبل از شروع مطلب این مسئله را یادآوری کنم که اگه مبتدی هستید ، از اجرای دستورات روی دیتابیسهای اصلی و پایگاه داده های محصولات تجاری خودداری کنید و جهت تمرین از پایگاه داده ای مثل AdventureWorks2016 استفاده کنید .همه ی اونهایی که با SQL سر و کله زدن دستور Delete را می شناسن. خب زندگی بدون پاک کردن بعضی چیزها جلو نمی ره ?  و خواه ناخواه چیزی را که نمی خوایم و لازم نداریم باید به خاطر هزینه های زیاد نگهداریش پاک کنیم . توی دنیای دیتابیس هم لازمه بعضی رکورد ها را حذف کرد و اون چیزی که برای حذف رکوردها بین متخصصین SQL یا DBA ها رایجه اینه که بنویسن :Delete from Table_Name Where conditionبیاید یه سناریوی بزرگتر را در نظر بگیریم ، دیتابیس بزرگ و حجیمی در اختیار شماست که چندین گیگ حجم داره و قراره که شما بعضی از اطلاعات اون را پاک کنید. برای چی ؟دو تا مثال واقعی بزنم :در یک نرم افزار انبار داری ، کارفرما از شما می خواد که کل اطلاعات مربوط به انبار بزرگی با هزاران سند ثبت شده در اون انبار را پاک کنید تا اون داده ها اصلا روی سرور موجود نباشند ! شما هم باید بگید چشم .یا مثال دیگه ، گاهی اوقات نیاز دارید که بدون حذف اطلاعات موجود در جداول پایه و پیکربندی پایگاه داده یک نرم افزار و با حذف اطلاعات جداولی که transaction ها را نگه می دارند ( صد البته این جداول حجم اصلی پایگاه داده را تشکیل می دن ) به یک کپی ساده و کم حجم برسید تا بتونید یه پایگاه داده دوم را آماده کنید که اطلاعات پیکربندی را داره اما داده خاصی از تراکنشها برای گزارشگیری در اون وجود نداره ، بعد می تونید با اون پایگاه داده دوم یه شعبه ، یک شرکت جدید ، یک محیط نرم افزاری آموزشی  یا ... را راه بیاندازید.نخستین قدم در اجرای اینکار اینه که از پایگاه داده مورد نظر Backup تهیه کنید . ( توصیه اکید می کنم خودتون شخصا فایل پشتیبان را تهیه کنید و از صحت فایل پشتیبان اطمینان پیدا کنید و اینکار را به عهده کس دیگه ای نگذارید. )در قدم دوم کارشناسان با توجه به شناختی که از ERD مربوطه روی سرور پایگاه داده دارن ، جداول ( tables ) خاصی را نشان می کنند و جدول به جدول  شروع به حذف رکوردها می کنند.اینجا یه توضیح لازمه : Microsoft SQL بانک اطلاعات رابطه ای است و رکوردهای جداول مختلف با کلیدهای خارجی (Foreign Key) با هم در ارتباط هستند و به واسطه این کلیدهای خارجی بین رکوردهای جداول  مختلف ، رابطه پدر و فرزندی وجود داره و بدلایل فنی درصد بالایی از این کلیدهای خارجی در تنظیمات خودشون گزینه ی حذف آبشاری (Cascade Delete) را ندارند یعنی اگه شما بخواهید رکوردهای جدول پدر را حذف   کنید ، رکوردهای مربوط در جدول فرزند خودکار حذف نمی شن و با پیام خطا مواجه می شید. SQL در پیام خطای خودش به شما اعلام می کنه به دلیل وجود کلید خارجی با نام فلان از جدول بهمان نمی شه داده ها را پاک کرد .به همین خاطر باید در گام نخست رکوردهای جدول فرزند را پاک کرد و در قدم های بعدی رکوردهای جدول پدر را . البته اگر تنها پای یکی دوتا کلید خارجی وسط بود، می شد قضیه را با تغییر موقت اون کلید حل کرد ، اما وقتی صدها کلید خارجی در دیتابیس وجود داشته باشه به ریسک اعمال این همه تغییر به دیتابیس نمی ارزه چرا که بعد از اعمال تغییرات و حذف داده ها باید دوباره این کلیدهای خارجی را به حالت اول برگردونید و امکان اشتباه وجود داره.خب ، برای انجام اینکار کارشناسان با شناختی که از جداول بانک اطلاعاتی و ERD دارن می دونن که در ابتدا باید کدام جداول را پاکسازی کنند. اما در اجرای گام دوم با دو تا مشکل مواجه می شن :اول اینکه حجم دیتابیس با توجه به تعداد رکورد های حذف شده خیلی خیلی بزرگ می شه. یعنی هرچی رکورد بیشتری را پاک می کنید دیتابیس بزرگتر می شه . چرا واقعا ؟! ما که داریم داده ها را پاک می کنیم پس چرا حجم دیتابیس بزرگ می شه ؟! خب به خواندن ادامه بدید تا دلیلش را متوجه بشید.مشکل دومی که بوجود می آد ، کند شدن سرور هست . در حالت عادی کارفرما سرور دیگه ای نداره که در اختیار شما بگذاره ، من و شما هم مجبوریم از دیتابیس اصلی یک کپی تهیه کنیم و اون را با نام دیگه ای روی سرور برگردونیم تا عملیات پاکسازی ! را روی این پایگاه داده دوم انجام بدیم . از آنجا که هم دیتابیس اصلی و هم اون دیتابیسی که شما در حال حذف اطلاعات اون هستید روی یه سرور قرار دارن ، منابع سرور تقسیم می شه و سرور کند خواهد شد و بزودی فریاد اعتراض کاربران نرم افزار را خواهید شنید.اما دلایل و راه حلها :وقتی با استفاده از فرمان Delete  رکورد های یک جدول را پاک می کنید فضای آزاد شده به سیستم عامل      بر نمی گرده ، بلکه در صورتیکه یک یا تعداد بیشتری از Page های پایگاه داده که فضای اونها برای ذخیره سازی اطلاعات رکورد های پاک شده مصرف شده بود ، آزاد بشن ؛ SQL Server این Page ها را به &quot; فضای آزاد دیتابیس&quot;  منتقل می کنه ( اگه جدول را Rebuild کنیم ) و در نتیجه مجموعه اندازه فایلهای پایگاه داده تغییری نخواهد کرد و تنها پس از Shrink کردن دیتابیس فضای آزاد به سیستم عامل باز خواهد گشت .اما دلیل بزرگ شدن دیتابیس پس از حذف تعداد زیادی از رکوردها اینه که در SQL دستور Delete  دستوری است که بطور کامل LOG می شه و با حذف رکوردها و با مد نظر قرار دادن پاراگراف بالا ، در حالیکه عملا حجم فایلهای داده (MDF ,NDF ,…) دست نخورده باقی می مونه ؛ به جهت ثبت و ضبط عملیات حذف رکوردها،  اندازه فایل یا فایلهای LOG بزرگ و بزرگتر می شه . (باز هم Shrink  اینجا می تونه به داد ما برسه یا اینکه Recovery Model را تغییر بدیم و بعد لاگ فایل را shrink کنیم یا فایل log را حذف کنیم و دوباره بسازیم و... بعضی وقتها همه این کارها را می کنید اما &quot;لاگ فایل لعنتی&quot; سرسختانه بدون تغییر و دست نخورده سر جاش می مونه و سردرد می گیرید ! )به سه تا عکس بعدی دقت کنید ، توی این تصاویر حجم فایلهای دیتابیس AdventureWorks در حالت عادی ، پس از حذف تعدادی رکورد و بعد از Shrink کردن اون مشخص هست .حجم فایلهای دیتابیس قبل از حذف رکوردهاحجم فایلهای دیتابیس بعد از حذف رکوردها حجم فایلهای دیتابیس بعد از shrinkخب اگر بخواهیم کل اطلاعات یک جدول را پاک کنیم ، به جای استفاده از دستور Delete می تونیم از دستور Truncate table استفاده کنیم :TRUNCATE TABLE   { database_name.schema_name.table_name | schema_name.table_name | table_name } اگه پیش از این برای حذف داده ها در یه جدول لحظات کسل کننده ای را پای کنسول / سیستم منتظر مانده باشید ، دستور truncate  براتون مثل یه معجزه می مونه !!! سریع و با ایجاد حجم کمی اطلاعات Log ، کل رکوردهای جدول را برای شما پاک می کنه .منتها این دستور برای بکارگیری در این مورد یه مشکل خاص داره ، اگه به هنگام پاک کردن اطلاعت جدول به مشکل کلید خارجی بخوره ( یعنی رکوردهای این جدول ، پدر رکوردهای جدول دیگه ای باشند ) ، در پیام خطایی که به شما نشون می ده نام جدول یا نام FK ای که به این جدول کلید خارجی داره و دارای رکورد هست را نمی آره ! ( به خاطر اینکه این دستور یه دستور DDL هست نه DML ) و خودتون باید زحمت بکشید و جدول فرزند را با استفاده از sp_Fkey یا به کمک دیتا دیاگرام Management Studio یا ... پیدا کنید . (یا شاید هم برگردید سراغ دستور Delete تا در پیام خطاش به شما بگه که مشکل کجاست ! )اما بابت کند شدن سرور ، هیچ راهی نیست ☹ باید با بقیه کاربرایی که مشغول کار با سرور هستند کنار اومد. یه راه برای راضی نگه داشتن اونها اینه که داده ها را مرحله به مرحله پاک کنید . مثلا یک دهم رکوردهای یه جدول بزرگ را پاک کنید تا سرور بتونه transaction های سایر کاربران را هم جلو ببره .حالا چطوری یک دهم داده های یه جدول حجیم را پاک کنیم ؟ اولین راهی که به ذهن می رسه اینه که با توجه به مقدار کمینه و بیشینه کلید اصلی جدول ، شرط دستور Delete را طوری بنویسیم که حدود یک دهم رکوردها پاک بشن . به عنوان نمونه اگه کمینه کلید اصلی با نام ID جدولtable _name  برابر 1000 و بیشینه 1000000 باشه بنویسیم :Delete from table_name where id&gt;1 and id&lt;100000اما راه بهتر و ساده تری هم هست :Delete top (10) percent from table_nameاس کیو ال سرور بدون رعایت هیچ ضابطه ای در انتخاب رکوردها برای حذف شدن ، 10 درصد رکوردهای جدول را پاک می کنه . بعد از اجرای دستور ، شما می تونید کمی صبر کنید تا سرور سایر تراکنش هاش را انجام بده بعد دوباره 10 تا 15 درصد رکوردها را پاک کنید. این یکی از کاربردهای عبارت Top در دستور Delete هست.تموم شد ، امیدوارم براتون مفید باشه و یه نکته دیگه ، در صدد ارائه مطلب آموزشی نیستم . یکسری تجربیاتم را با شما به اشتراک گذاشتم به امید اینکه براتون مفید باشه .</description>
                <category>مهدی نظارت</category>
                <author>مهدی نظارت</author>
                <pubDate>Sat, 21 Dec 2019 00:03:34 +0330</pubDate>
            </item>
                    <item>
                <title>سر آغاز</title>
                <link>https://virgool.io/@nezarat/%D8%B3%D8%B1-%D8%A2%D8%BA%D8%A7%D8%B2-e5jjxlykv4eo</link>
                <description>به نام خداوند بخشنده بخشایشگربه خاطر دارم همراه هم دانشگاهی های مذکر خودم برای بازدید از نمایشگاه الکامپ از زنجان به تهران اومدیم ، انواع محصولات نرم افزاری و سخت افزاری مختلف در زمینه هایی مثل حسابداری ، آموزش ، اتوماسیون صنعتی و ... در نمایشگاه عرضه شده بود . به غرفه های مختلف سر می زدیم و سعی می کردیم سر صحبت را با مسئولین غرفه باز کنیم تا با محصولاتشون آشنا بشیم و در مورد آینده ی پیش روی دنیای کامپیوتر دید بهتری بدست بیاریم . از بین تمام غرفه ها رسیدیم به غرفه ای که مونیتورش را رو به همه گذاشته بود و یه تصویر گرافیکی زیبای اسلیمی به همراه متن ، روی صفحه خود نمایی می کرد. ظاهر جذاب این محصول توی هیچ جای نمایشگاه دیده نمی شد . شاید به جرأت بتونم بگم تنها 2 درصد محصولات نرم افزاری ارائه شده چنین کیفیت گرافیکی داشتند و بعضی هاشون با وجود گرافیک چشم نواز متاسفانه فارسی نبودند.در حالی که حس کنجکاوی من و همراهام به شدت تحریک شده بود به یکی از افراد داخل غرفه سلام کردم و بدون اینکه از اسم محصول نرم افزاریشون بپرسم ، سؤال کردم &quot;با چه نرم افزاری این رو نوشتید؟ &quot; گفت : &quot;با اچ تی ام ال &quot; گفتم &quot;چی ؟&quot;  گفت &quot; اچ تی ام ال ! &quot; و ادامه داد: &quot; هایپر تکست مارکاپ لنگو ایج &quot; و رو کرد به یکی دیگه از افراد غرفه و پرسید &quot; درست گفتم مهندس ؟!&quot; مهندس با لبخندی جواب داد &quot;آره &quot;خداییش ما که با دنیای DOS کار می کردیم و تازه سرکله ی ویندوز 95 پیدا شده بود با دیدن صفحات وب اون محصول هنگ کرده بودیم .از اون روز بیش از دو دهه (20 سال) می گذره ، اینترنت همه جا نفوذ کرده و هر روز یه قدم جلوتر می آد. الان زمانه ، زمانه اینترنت اشیائه و نسل تحصیل کرده کاملا با وب آشنا هستند. اینترنت گوشی موبایل توی مشت ماست  ( البته شیر قطع و وصلش دست کسه دیگه ای ! )  ولی خب ،  در دسترس همه کم و بیش هست .این مقدمه را گفتم تا به اینجا برسم : چند وقت پیش دنبال جواب سؤال یه مورد فنی در خصوص SQL می گشتم تا بعد از کلی جستجو و تغییر کلمات جستجو ، گوگل من را به اون چیزی که می خواستم رسوند. جواب خیلی ساده بود ولی از اینکه چنین جوابی در منابع آزاد ( مجانی ) فارسی به سادگی در دسترس نیست دلخور شدم . کمی بیشتر در گوگل و به فارسی جستجو کردم . تصور اینکه کیفیت منابع آموزشی آزاد و عمومی فارسی این قدر پایین باشه برام پذیرفتنی نیست  ، یه دلیلش شاید سرعت تغییرات تکنولوژی باشه که باعث می شه ما همیشه عقب باشیم یا شایدم ، مشغله همه توی اینستاگرام و تلگرام نمی ذاره همچین کارایی بکنیم یا هزارجور بهانه دیگه . بعد دیدم خود من هم تا به حال کار خاصی نکردم ، این شد که تصمیم گرفتم به یاری خداوند بعضی از تجربه های فنی کارم را منتشر کنم ، دنبال بستر مناسب می گشتم که ویرگول را پیدا کردم   امیدوارم مطالبی که اینجا می نویسم برای دیگران مفید باشه .</description>
                <category>مهدی نظارت</category>
                <author>مهدی نظارت</author>
                <pubDate>Fri, 13 Dec 2019 16:40:47 +0330</pubDate>
            </item>
            </channel>
</rss>