بریم بایک مثال خفن دیگه تفاوت Index Scan و Index Seek رو بهتون بگم.
🔍 Index Scan
مثل خانمی که به شوهرش شک کرده 😅
شروع میکنه همهچیزو زیر و رو کردن: 📱 موبایل، 🎒 کیف، 📂 پروندهها، حتی جیب شلوار!
یعنی از اول تا آخر همهچیزو میگرده تا بلکه یه سرنخ پیدا کنه.
🎯 Index Seek
اما این یکی خیلی هدفمنده 😎
صبح راه میافته دنبال شوهرش، صاف میره سر اصل ماجرا 👉 همون جایی که میدونه جوابش هست.(بعد همونجا پاره اش می کنه 😁 )
🔍 Index Scan
مثل خانمی که به شوهرش شک کرده 😅
شروع میکنه همهچیزو زیر و رو کردن: 📱 موبایل، 🎒 کیف، 📂 پروندهها، حتی جیب شلوار!
یعنی از اول تا آخر همهچیزو میگرده تا بلکه یه سرنخ پیدا کنه.
🎯 Index Seek
اما این یکی خیلی هدفمنده 😎
صبح راه میافته دنبال شوهرش، صاف میره سر اصل ماجرا 👉 همون جایی که میدونه جوابش هست.(بعد همونجا پاره اش می کنه 😁 )
🤣19😁5👍3❤2👌1
سلام
✍️ امروز یکی از دوستانم با مشکلی در SQL Server Always On Availability Group روبهرو شد.
بین دو سرور، کلاستر راهاندازی شده بود و حتی در سرویس SQL Server هم تیک مربوط به کلاستر خورده بود، اما هنگام ایجاد Availability Group خطای عجیبی نمایش داده میشد.
🔎 مراحل بررسی که انجام دادم:
1️⃣ اول از همه مطمئن شدم که سرویس کلاستر در حال اجراست.
2️⃣ بعد وضعیت نودها رو بررسی کردم تا هر دو در حالت Up باشند.
3️⃣ وجود File Share Witness رو هم چک کردم (اگر نباشه این خطا رو ایجاد نمیکنه، ولی بودنش همیشه بهتره).
4️⃣ در نهایت داخل SQL Server این کوئری رو اجرا کردم:
SELECT * FROM sys.dm_hadr_cluster
اینجا مشخص شد که برای سرویس، هیچ کلاستری تعریف نشده!
✅ راهحل ساده بود:
یکبار قابلیت Always On Availability Group رو از داخل SQL Server Configuration Manager غیرفعال و دوباره فعال کردم. مشکل برطرف شد.
💡 گفتم این تجربه رو اینجا هم به اشتراک بذارم، شاید به کارتون بیاد.
#Alwayson #Availability_Group #HA #DBA
✍️ امروز یکی از دوستانم با مشکلی در SQL Server Always On Availability Group روبهرو شد.
بین دو سرور، کلاستر راهاندازی شده بود و حتی در سرویس SQL Server هم تیک مربوط به کلاستر خورده بود، اما هنگام ایجاد Availability Group خطای عجیبی نمایش داده میشد.
🔎 مراحل بررسی که انجام دادم:
1️⃣ اول از همه مطمئن شدم که سرویس کلاستر در حال اجراست.
2️⃣ بعد وضعیت نودها رو بررسی کردم تا هر دو در حالت Up باشند.
3️⃣ وجود File Share Witness رو هم چک کردم (اگر نباشه این خطا رو ایجاد نمیکنه، ولی بودنش همیشه بهتره).
4️⃣ در نهایت داخل SQL Server این کوئری رو اجرا کردم:
SELECT * FROM sys.dm_hadr_cluster
اینجا مشخص شد که برای سرویس، هیچ کلاستری تعریف نشده!
✅ راهحل ساده بود:
یکبار قابلیت Always On Availability Group رو از داخل SQL Server Configuration Manager غیرفعال و دوباره فعال کردم. مشکل برطرف شد.
💡 گفتم این تجربه رو اینجا هم به اشتراک بذارم، شاید به کارتون بیاد.
#Alwayson #Availability_Group #HA #DBA
❤27👍12👌2
اگه دقت کرده باشید بچهها وقتی یه اسباببازی دستشونه، به هیچوجه ولکن نیستن. 😅
هرکی هم بخواد بگیره سریع میگه: «مال خودمه!»
تا وقتی یا بازیشون تموم بشه (🔒 Commit) یا حواسشون پرت یه چیز دیگه بشه (❌ Rollback)، اون اسباببازی رو ول نمیکنن.
Transaction توی SQL Server هم دقیقاً همین مدلیه!
وقتی بازه، رکورد یا جدول رو محکم گرفته و به هیچکس دیگه نمیده.
یا باید کارش رو درست تموم کنه (Commit) یا بیخیال بشه و همه چی رو پس بده (Rollback).
هرکی هم بخواد بگیره سریع میگه: «مال خودمه!»
تا وقتی یا بازیشون تموم بشه (🔒 Commit) یا حواسشون پرت یه چیز دیگه بشه (❌ Rollback)، اون اسباببازی رو ول نمیکنن.
Transaction توی SQL Server هم دقیقاً همین مدلیه!
وقتی بازه، رکورد یا جدول رو محکم گرفته و به هیچکس دیگه نمیده.
یا باید کارش رو درست تموم کنه (Commit) یا بیخیال بشه و همه چی رو پس بده (Rollback).
❤16👍13
توی خونههای پرجمعیت، اگه پدر و مادرها مدیریت نمیکردن، بچهها همدیگه رو تیکهپاره میکردن! 😅
قانون جنگل بود:
🍞 هرکی زودتر بیدار میشد غذا گیرش میاومد، وگرنه گشنه میموند.
🛏 هرکی زورش بیشتر بود، اتاق و تخت مال خودش میشد و بقیه باید وسط هال عشق میکردن!
اینجا بود که پدر و مادرها (و هنوز هم) وارد میشدن و منابع رو بین بچهها عادلانه تقسیم میکردن. نتیجه؟ دیگه جنگهای قبیلهای داخلی از بین میرفت و همه در صلح و صفا زندگی میکردن. ✌️
فقط اگه بچهای دست درازی میکرد، با سلاح کشندهای به نام دمپایی 👡 مواجه میشد!
حالا توی SQL Server هم Resource Governor همین نقش رو داره. ⚙️
منابع رو بین یوزرها تقسیم میکنه تا درگیر نشن. و اگه یه کوئری هم بخواد زور بگه و منابع بیشتری بگیره، با Kill شدن و خطا (همون دمپایی معروف 😁) روبهرو میشه.
شما تا حالا از Resource Governor استفاده کردین؟
قانون جنگل بود:
🍞 هرکی زودتر بیدار میشد غذا گیرش میاومد، وگرنه گشنه میموند.
🛏 هرکی زورش بیشتر بود، اتاق و تخت مال خودش میشد و بقیه باید وسط هال عشق میکردن!
اینجا بود که پدر و مادرها (و هنوز هم) وارد میشدن و منابع رو بین بچهها عادلانه تقسیم میکردن. نتیجه؟ دیگه جنگهای قبیلهای داخلی از بین میرفت و همه در صلح و صفا زندگی میکردن. ✌️
فقط اگه بچهای دست درازی میکرد، با سلاح کشندهای به نام دمپایی 👡 مواجه میشد!
حالا توی SQL Server هم Resource Governor همین نقش رو داره. ⚙️
منابع رو بین یوزرها تقسیم میکنه تا درگیر نشن. و اگه یه کوئری هم بخواد زور بگه و منابع بیشتری بگیره، با Kill شدن و خطا (همون دمپایی معروف 😁) روبهرو میشه.
شما تا حالا از Resource Governor استفاده کردین؟
❤10👍8
سلام عزیزان
🚀 یه پست خفن دیگه 🚀
ما توی SQL Server چیزی داریم به اسم Cost Threshold for Parallelism (CTFP).
ولی خب این یعنی چی؟ 🤔
🔧 مثال خودمونی:
همهمون حداقل یه بار اسبابکشی داشتیم. کارگر باربر رودیدین؟
تا یه حدی بار رو تنهایی مثل بنز 🚛 میندازه رو کولش و میبره.
اما وقتی بار خیلی سنگین بشه، دیگه یه نفر جواب نمیده و چند نفر باید با هم دستبهکار شن.
🔍 تشبیه:
هر کارگر = یه CPU 🖥
اون حد توان = CTFP
وقتی هزینهی اجرای یه Query از اون حد بیشتر بشه:
👉 یه CPU تنها نمیتونه
👉 چند CPU با هم میپرن وسط
👉 و تا وقتی اون بار سنگین جابهجا بشه، کارای سبکتر باید وایسن تو صف ⏳
📌 نتیجهگیری:
تا میتونید Queryهاتون رو بهینه بنویسید 💡
هزینه کم = سرعت بیشتر = CPU خوشحال 😎
⚖️ نکته مهم در تنظیم CTFP:
اگه خیلی زیاد باشه → یه CPU ممکنه زیر بار سنگین له بشه 😵💫
اگه خیلی کم باشه → حتی بارهای سبک هم چند CPU رو درگیر میکنن و همهچی کند میشه 🐌
🚀 یه پست خفن دیگه 🚀
ما توی SQL Server چیزی داریم به اسم Cost Threshold for Parallelism (CTFP).
ولی خب این یعنی چی؟ 🤔
🔧 مثال خودمونی:
همهمون حداقل یه بار اسبابکشی داشتیم. کارگر باربر رودیدین؟
تا یه حدی بار رو تنهایی مثل بنز 🚛 میندازه رو کولش و میبره.
اما وقتی بار خیلی سنگین بشه، دیگه یه نفر جواب نمیده و چند نفر باید با هم دستبهکار شن.
🔍 تشبیه:
هر کارگر = یه CPU 🖥
اون حد توان = CTFP
وقتی هزینهی اجرای یه Query از اون حد بیشتر بشه:
👉 یه CPU تنها نمیتونه
👉 چند CPU با هم میپرن وسط
👉 و تا وقتی اون بار سنگین جابهجا بشه، کارای سبکتر باید وایسن تو صف ⏳
📌 نتیجهگیری:
تا میتونید Queryهاتون رو بهینه بنویسید 💡
هزینه کم = سرعت بیشتر = CPU خوشحال 😎
⚖️ نکته مهم در تنظیم CTFP:
اگه خیلی زیاد باشه → یه CPU ممکنه زیر بار سنگین له بشه 😵💫
اگه خیلی کم باشه → حتی بارهای سبک هم چند CPU رو درگیر میکنن و همهچی کند میشه 🐌
❤14👍7👌2🤨2
سلام دوستان
🔑 توی SQL Server یه چیزی داریم به اسم Trace Flag، کلیدای مخفی که رفتارای پشتصحنه رو عوض میکنن.
حالا یعنی چی؟ 🤔
فرض کن با پارتنر عزیزت بحثت شده و رسماً در حالت پارهپوره هستید 😅
یه گل میخری 🌹 (یعنی یه Trace Flag فعال میکنی)
یهو رفتار طرف تغییر میکنه و همهچی دوباره گل و بلبل میشه! 🕊✨
ولی از اون ور، ممکنه یه جمله اشتباهی بگی و یکی از اون Trace Flagها فعال شه…
نتیجه؟ 😬 یه لاگ مفصل از غرغرها روی سرت میاد پایین! (مثل وقتی تو SQL Server میزنی 3704 و لاگهای ریزتر میبینی 📜)
نکته عجیبش چیه؟ 🤨
چه توی SQL Server چه تو زندگی واقعی، خیلی از این Trace Flagها Undocumented هستن!
یعنی هیچ راهنما و مستندی براشون نیست. باید خودت مورد عنایت قرار بگیری تا یاد بگیری 😅
📚 برای اینکه توی SQL Server بیشتر در موردش بدونید، این لینک میتونه مفید باشه
https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql?view=sql-server-ver17
🔑 توی SQL Server یه چیزی داریم به اسم Trace Flag، کلیدای مخفی که رفتارای پشتصحنه رو عوض میکنن.
حالا یعنی چی؟ 🤔
فرض کن با پارتنر عزیزت بحثت شده و رسماً در حالت پارهپوره هستید 😅
یه گل میخری 🌹 (یعنی یه Trace Flag فعال میکنی)
یهو رفتار طرف تغییر میکنه و همهچی دوباره گل و بلبل میشه! 🕊✨
ولی از اون ور، ممکنه یه جمله اشتباهی بگی و یکی از اون Trace Flagها فعال شه…
نتیجه؟ 😬 یه لاگ مفصل از غرغرها روی سرت میاد پایین! (مثل وقتی تو SQL Server میزنی 3704 و لاگهای ریزتر میبینی 📜)
نکته عجیبش چیه؟ 🤨
چه توی SQL Server چه تو زندگی واقعی، خیلی از این Trace Flagها Undocumented هستن!
یعنی هیچ راهنما و مستندی براشون نیست. باید خودت مورد عنایت قرار بگیری تا یاد بگیری 😅
📚 برای اینکه توی SQL Server بیشتر در موردش بدونید، این لینک میتونه مفید باشه
https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql?view=sql-server-ver17
Docs
Trace Flags (Transact-SQL) - SQL Server
Learn how to set specific server characteristics or to alter a particular behavior in SQL Server, using DBCC TRACEON.
👍15❤5😁1👌1
ما توی SQL Server یه قابلیتی داریم به اسم Audit Log.
حالا یعنی چی؟
فرض کن داری با ماشینت توی خیابون حرکت میکنی:
از یه طرف دوربینها همهجا هستن، از یه طرف پلیس نامحسوس رد میشه، اون وسط هم پلیس ایستاده داره سرعت رو میگیره. یعنی هر حرکتت رصد میشه و کافیه یه خطا کنی، سریع مچت رو میگیرن 🚨
دقیقاً همین کار رو Audit Log توی دیتابیس انجام میده.
یا اگه بخوام یه مثال دیگه بزنم: شنیدین میگن خدا برای هر آدمی یه فرشته گذاشته که حتی وقتی دستتو میکنی توی دماغت هم یادداشت میکنه؟ 😅
چرا؟ برای اینکه اون دنیا جای حاشا نباشه و فیلمشو بذارن جلوت.
Audit Log هم حکم همون فرشته رو داره. هرکاری کنی ثبت میشه، تا فردا روز نشه گفت: «من نبودم، دستم خورد!» 😉
حالا یعنی چی؟
فرض کن داری با ماشینت توی خیابون حرکت میکنی:
از یه طرف دوربینها همهجا هستن، از یه طرف پلیس نامحسوس رد میشه، اون وسط هم پلیس ایستاده داره سرعت رو میگیره. یعنی هر حرکتت رصد میشه و کافیه یه خطا کنی، سریع مچت رو میگیرن 🚨
دقیقاً همین کار رو Audit Log توی دیتابیس انجام میده.
یا اگه بخوام یه مثال دیگه بزنم: شنیدین میگن خدا برای هر آدمی یه فرشته گذاشته که حتی وقتی دستتو میکنی توی دماغت هم یادداشت میکنه؟ 😅
چرا؟ برای اینکه اون دنیا جای حاشا نباشه و فیلمشو بذارن جلوت.
Audit Log هم حکم همون فرشته رو داره. هرکاری کنی ثبت میشه، تا فردا روز نشه گفت: «من نبودم، دستم خورد!» 😉
👍21❤4🤨1
سلام دوستان
🚀 از ۱۰ میلیون Logical Read تا فقط ۲۵۰!
یکی از کوئریهایی که بررسی میکردم، به خاطر استفادهی از OPENJSON ( که در اونجا بهش نیازی نبود ) بیش از ۱۰ میلیون logical read داشت و اجرای اون حدود ۱۰ ثانیه CPU time طول میکشید.
با بازنویسی ساده و حذف بخشهای غیرضروری، همون کوئری در نهایت:
✅ به ۸ میلیثانیه زمان اجرا رسید
به تصاویر که نگاه کنید میزان Logical Read مخصوصا روی Worktable که برای استفاده از Tempdb هست مشخصه.
📊 این تجربه دوباره نشون داد که همیشه لازم نیست به سراغ راهحلهای پیچیده بریم. گاهی یک بازنویسی ساده میتونه بیش از هزار برابر بهبود در پرفورمنس ایجاد کنه.
❓ شما آخرین باری که یک کوئری رو به این شدت بهینه کردید، کی بوده؟
🚀 از ۱۰ میلیون Logical Read تا فقط ۲۵۰!
یکی از کوئریهایی که بررسی میکردم، به خاطر استفادهی از OPENJSON ( که در اونجا بهش نیازی نبود ) بیش از ۱۰ میلیون logical read داشت و اجرای اون حدود ۱۰ ثانیه CPU time طول میکشید.
با بازنویسی ساده و حذف بخشهای غیرضروری، همون کوئری در نهایت:
✅ به ۸ میلیثانیه زمان اجرا رسید
به تصاویر که نگاه کنید میزان Logical Read مخصوصا روی Worktable که برای استفاده از Tempdb هست مشخصه.
📊 این تجربه دوباره نشون داد که همیشه لازم نیست به سراغ راهحلهای پیچیده بریم. گاهی یک بازنویسی ساده میتونه بیش از هزار برابر بهبود در پرفورمنس ایجاد کنه.
❓ شما آخرین باری که یک کوئری رو به این شدت بهینه کردید، کی بوده؟
👍13❤3
🤔 تا حالا خواستی دقیق بدونی جداول سیستمی SQL Server چطوری کار میکنن و چه روابطی با هم دارن؟
یه روش خیلی باحال برای یادگیری هست:
1️⃣ یه SQL Server روی سیستمت نصب کن.
2️⃣ یه ابزار مانیتورینگ مثل Profiler یا ترجیحاً XEvents اجرا کن.
3️⃣ شروع کن با SSMS کار کردن. مثلاً:
لیست دیتابیسها رو باز کن.
روی گزینههای مختلف کلیک کن.
🔎 اینجا هر Query که توسط SSMS اجرا میشه (برای همون کاری که تو انجام دادی) توی ابزار لیست میشه و میتونی ببینی.
به این شکل خیلی راحت میفهمی پشت پرده دقیقاً چه اتفاقی میفته، چه جداول سیستمی درگیر میشن و کل ماجرا چطور مدیریت میشه.
⚡️ نتیجه؟ درک عمیقتر و واقعیتر از SQL Server 🚀
یه روش خیلی باحال برای یادگیری هست:
1️⃣ یه SQL Server روی سیستمت نصب کن.
2️⃣ یه ابزار مانیتورینگ مثل Profiler یا ترجیحاً XEvents اجرا کن.
3️⃣ شروع کن با SSMS کار کردن. مثلاً:
لیست دیتابیسها رو باز کن.
روی گزینههای مختلف کلیک کن.
🔎 اینجا هر Query که توسط SSMS اجرا میشه (برای همون کاری که تو انجام دادی) توی ابزار لیست میشه و میتونی ببینی.
به این شکل خیلی راحت میفهمی پشت پرده دقیقاً چه اتفاقی میفته، چه جداول سیستمی درگیر میشن و کل ماجرا چطور مدیریت میشه.
⚡️ نتیجه؟ درک عمیقتر و واقعیتر از SQL Server 🚀
❤12👍5🔥1
سلام دوستان
🛒 یادتونه سالها قبل از اینکه هایپراستار بیاد، برای هر چیزی مجبور بودیم بریم یه فروشگاه مخصوص همون؟
هیچ مرجعی نبود که یکجا همه نیازها رو پوشش بده.
وقتی هایپراستار اومد، ملت استقبال کردن چون همهچی یه جا جمع بود:
✅ برندهای خوب
✅ اجناس درستحسابی
✅ خرید راحتتر
نتیجه؟ دسترسی سادهتر به کالاها و در عوض فروش مغازههای اطراف به شدت افت کرد.
حالا دقیقاً همین اتفاق توی دنیای SQL Server و Data Warehouse (DW) میفته.
📊 توی DW:
دادهها از منابع مختلف (مثل همون فروشگاهها یا کارخانهها) جمع میشن.
برای رکوردها Master Data پیادهسازی میشه (یه کدینگ واحد برای کالاها).
دادهها تمیز و پاکسازی میشن (کالاهای خراب و برندهای ضعیف حذف میشن).
و در نهایت کاربر با یه منبع دادهی مرتب و درست سروکله میزنه و میتونه به صورت تجمیعی به همه نیازهای گزارشگیری و تصمیمگیری دسترسی داشته باشه—بدون اینکه مجبور باشه بره سراغ تکتک سیستمها.
⚠️ پس اگه جایی اومدن براتون DW و BI راه انداختن ولی این اتفاقا نیفتاد… احتمالاً یه جای کار میلنگه 😉
🛒 یادتونه سالها قبل از اینکه هایپراستار بیاد، برای هر چیزی مجبور بودیم بریم یه فروشگاه مخصوص همون؟
هیچ مرجعی نبود که یکجا همه نیازها رو پوشش بده.
وقتی هایپراستار اومد، ملت استقبال کردن چون همهچی یه جا جمع بود:
✅ برندهای خوب
✅ اجناس درستحسابی
✅ خرید راحتتر
نتیجه؟ دسترسی سادهتر به کالاها و در عوض فروش مغازههای اطراف به شدت افت کرد.
حالا دقیقاً همین اتفاق توی دنیای SQL Server و Data Warehouse (DW) میفته.
📊 توی DW:
دادهها از منابع مختلف (مثل همون فروشگاهها یا کارخانهها) جمع میشن.
برای رکوردها Master Data پیادهسازی میشه (یه کدینگ واحد برای کالاها).
دادهها تمیز و پاکسازی میشن (کالاهای خراب و برندهای ضعیف حذف میشن).
و در نهایت کاربر با یه منبع دادهی مرتب و درست سروکله میزنه و میتونه به صورت تجمیعی به همه نیازهای گزارشگیری و تصمیمگیری دسترسی داشته باشه—بدون اینکه مجبور باشه بره سراغ تکتک سیستمها.
⚠️ پس اگه جایی اومدن براتون DW و BI راه انداختن ولی این اتفاقا نیفتاد… احتمالاً یه جای کار میلنگه 😉
❤5👍1
سلام
🚀 یکی از پروژههای بهینهسازی دیتابیس که این روزا روش کار میکنم، یه ماجرای جالب داشت:
رفیقای قدیم یه علاقه خاصی به ایندکس داشتن 😅
تو جداول پرکاربرد، رو هر چی فیلد بود یه ایندکس ساخته بودن!
بعدش مثلاً علی رفته بود یه ایندکس روی تاریخ گذاشته، محمد اومده دیده "ای بابا! این علی بدون وضو ایندکس روی تاریخ گذاشته. خلاصه با نیت خالص و با وضو دوباره روی تاریخ ایندکس ایجاد کرده شاید امید به خدا درست کار کنه. " 😅✌️
ولی خب اون قبلی رو حذف نکرده بود، فقط اضافه کرده بود!
نامگذاریها هم در حد لیگ قهرمانان اروپا 🤦♂️ از 1 شروع کرده بودن و خیاری ادامه داده بودن.
📞 آخرش هم مشتری زنگ میزنه:
"داداش میخوایم یه رکورد ثبت کنیم، جد و آبادمون داره جلوی چشممون رد میشه! چند دقیقه باید صبر کنیم تا بشه!"
یاد اون دیالوگ اکبر عبدی توی اخراجیها افتادم که میگفت:
«بابام میگفت هرچی نماز بیشتر بخونی بهتره»
اینا هم فکر کردن هرچی ایندکس بیشتر بذارن، دیتابیس خوشحالتر میشه! 😂
گفتن دیگه از ایندکس چیزی برای دیتابیس کم و کسری نذاریم. 😂
🔑 نتیجه اخلاقی:
خداوکیلی این مدلی دیتابیس طراحی نکنید. ایندکسگذاری علمه، نه تعداد! 😉
🚀 یکی از پروژههای بهینهسازی دیتابیس که این روزا روش کار میکنم، یه ماجرای جالب داشت:
رفیقای قدیم یه علاقه خاصی به ایندکس داشتن 😅
تو جداول پرکاربرد، رو هر چی فیلد بود یه ایندکس ساخته بودن!
بعدش مثلاً علی رفته بود یه ایندکس روی تاریخ گذاشته، محمد اومده دیده "ای بابا! این علی بدون وضو ایندکس روی تاریخ گذاشته. خلاصه با نیت خالص و با وضو دوباره روی تاریخ ایندکس ایجاد کرده شاید امید به خدا درست کار کنه. " 😅✌️
ولی خب اون قبلی رو حذف نکرده بود، فقط اضافه کرده بود!
نامگذاریها هم در حد لیگ قهرمانان اروپا 🤦♂️ از 1 شروع کرده بودن و خیاری ادامه داده بودن.
📞 آخرش هم مشتری زنگ میزنه:
"داداش میخوایم یه رکورد ثبت کنیم، جد و آبادمون داره جلوی چشممون رد میشه! چند دقیقه باید صبر کنیم تا بشه!"
یاد اون دیالوگ اکبر عبدی توی اخراجیها افتادم که میگفت:
«بابام میگفت هرچی نماز بیشتر بخونی بهتره»
اینا هم فکر کردن هرچی ایندکس بیشتر بذارن، دیتابیس خوشحالتر میشه! 😂
گفتن دیگه از ایندکس چیزی برای دیتابیس کم و کسری نذاریم. 😂
🔑 نتیجه اخلاقی:
خداوکیلی این مدلی دیتابیس طراحی نکنید. ایندکسگذاری علمه، نه تعداد! 😉
👍15😁4❤2💯1🤣1