خب خب خب جلوگیری از Race Condition در جنگو با select_for_update 🔒🚀

توی این پست در مورد Race Condition صحبت کردیم و گفتیم چطور ممکنه چندتا درخواست همزمان بیان و دیتا رو خراب کنن. حالا بریم ببینیم جنگو چه ترفندهایی برای کنترل این مشکل داره و چطور می‌تونیم از select_for_update استفاده کنیم.

مشکل چیه؟ 🤔
فرض کن یه سیستم بانکی داری و کاربرا دارن پول جابه‌جا می‌کنن. حالا دو نفر همزمان می‌خوان از حسابشون پول بردارن و موجودی حساب فقط 100 تومنه. اگه این درخواست‌ها بدون قفل کردن دیتا پردازش بشن، ممکنه هر دو برداشت موفق بشن و سیستم بدهکار بشه 😬

اینجا همون جاییه که select_for_update میاد وسط و دیتا رو از فاجعه نجات می‌ده.

چطوری select_for_update مشکل رو حل می‌کنه؟ 🔐
وقتی از select_for_update استفاده می‌کنی، رکورد دیتابیس قفل می‌شه تا هیچ درخواست دیگه‌ای نتونه همزمان تغییرش بده. این یعنی هر درخواستی که بعد از اولین درخواست بیاد، باید منتظر بمونه تا قفل آزاد بشه و بعد پردازش بشه.

مثال 1: جلوگیری از برداشت همزمان از حساب بانکی 🏦

from django.db import transaction
from myapp.models import Account

def withdraw_money(account_id, amount):
    with transaction.atomic():  # شروع تراکنش
        account = Account.objects.select_for_update().get(pk=account_id)  # قفل کردن رکورد
        if account.balance >= amount:
            account.balance -= amount
            account.save()
            print("برداشت موفقیت‌آمیز بود!")
        else:
            print("موجودی کافی نیست!")  # جلوگیری از برداشت بیش از حد

✅ این کد مطمئن می‌شه که وقتی یه درخواست داره موجودی رو چک می‌کنه و کم می‌کنه، هیچ درخواست دیگه‌ای همزمان وارد عمل نشه.

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

from django.db import transaction
from myapp.models import Account

def transfer_money(from_id, to_id, amount):
    with transaction.atomic():
        accounts = Account.objects.select_for_update().filter(pk__in=[from_id, to_id]).order_by("id")
        
        sender = accounts[0]
        receiver = accounts[1]

        if sender.balance >= amount:
            sender.balance -= amount
            receiver.balance += amount
            sender.save()
            receiver.save()
            print("انتقال وجه موفقیت‌آمیز بود!")
        else:
            print("موجودی کافی نیست!")  # جلوگیری از انتقال اشتباه

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

چندتا نکته 🚀

🔹 انتخاب نوع قفل (select_for_update(nowait=True))
اگه بخوای درخواست‌های معطل رو سریع رد کنی، می‌تونی nowait=True بذاری که اگه رکورد قفل بود، درخواست جدید منتظر نمونه و مستقیم خطا بده.

account = Account.objects.select_for_update(nowait=True).get(pk=1)

☝️ این باعث می‌شه که اگه رکورد قفل باشه، جنگو بلافاصله یه DatabaseError بده و منتظر نمونه.

🔹 قفل کردن رکوردها بدون مسدود کردن خواندن (select_for_update(skip_locked=True))
اگه درخواست‌های زیادی داری و نمی‌خوای که یک درخواست کل سیستم رو بلاک کنه، می‌تونی از skip_locked=True استفاده کنی که درخواست‌های دیگه بتونن رکوردهای آزاد رو پردازش کنن.

account = Account.objects.select_for_update(skip_locked=True).get(pk=1)

☝️ این کار باعث می‌شه که اگه یه رکورد قفل بود، درخواست بیخیال اون رکورد بشه و فقط رکوردهایی که قفل نیستن رو انتخاب کنه.

🔹 مدیریت تایم‌اوت قفل (set statement_timeout)
اگه نمی‌خوای که درخواست‌ها مدت زیادی بلاک بشن، توی PostgreSQL می‌تونی یه تایم‌اوت برای قفل تعیین کنی:

SET statement_timeout = '5s'; 

☝️ این یعنی اگه یه درخواست بیشتر از ۵ ثانیه قفل بمونه، بهش خطا داده می‌شه و می‌ره بیرون.

جمع‌بندی ✍
‏select_for_update یکی از قوی‌ترین ابزارها برای جلوگیری از Race Condition توی جنگوئه. مهم‌ترین نکاتش اینان:
✅ قفل کردن رکوردهای دیتابیس موقع آپدیت برای جلوگیری از دستکاری همزمان
✅ استفاده از nowait=True برای جلوگیری از انتظار بیش از حد
✅ استفاده از skip_locked=True برای رد کردن رکوردهای قفل‌شده و ادامه پردازش.

#️⃣ #python #programming #db

➖➖➖➖➖➖➖➖➖

🥷 CHANNEL | GROUP

خب خب خب Alembic 🧪

مروز می‌خوام درباره یه ابزار کاربردی تو دنیای پایتون حرف بزنم: Alembic اگه با دیتابیس کار می‌کنین و دنبال یه راه ساده برای مدیریت تغییراتش هستین، این پست برای شماست. بیاین با هم ببینیم Alembic چیه، چطوری کار می‌کنه و چرا باید ازش استفاده کنین.

‏🧠 Alembic چیه؟

‏Alembic یه ابزار متن‌باز (open-source) برای مدیریت مهاجرت‌های دیتابیس (database migrations) تو پایتونه. این ابزار بیشتر با SQLAlchemy (یه ORM معروف) جفت‌وجوره و بهتون کمک می‌کنه تغییرات ساختاری دیتابیستون رو (مثل اضافه کردن جدول، تغییر ستون یا حذف فیلد) به صورت خودکار و منظم مدیریت کنین. به جای اینکه دستی کوئری‌های SQL بنویسین و دیتابیس رو عوض کنین، Alembic این کار رو براتون ساده و خودکار می‌کنه.

فکر کنین یه جدول جدید به پروژه‌تون اضافه کردین یا یه ستون رو تغییر دادین؛ Alembic این تغییرات رو به یه فایل مهاجرت (migration script) تبدیل می‌کنه که می‌تونین هر وقت خواستین اعمالش کنین یا حتی برگردونین (rollback).

‏📚 Alembic چطوری کار می‌کنه؟

‏Alembic مثل یه مدیر پروژه برای دیتابیستونه. بیاین قدم‌به‌قدم ببینیم چطوری کار می‌کنه:

1⃣ نصب و راه‌اندازی:
اول با

pip install alembic

نصبش می‌کنین. بعد با دستور

alembic init نام اختیاری

یه پوشه برای تنظیماتش می‌سازین (معمولاً به اسم alembic).

2⃣ ساخت Migration:
وقتی مدل‌های SQLAlchemy‌تون رو تغییر می‌دین (مثلاً یه ستون به کلاس اضافه می‌کنین)، با دستور زیر Alembic تغییرات رو تشخیص می‌ده و یه اسکریپت Migration می‌سازه:

   alembic revision --autogenerate -m "اضافه کردن ستون جدید"
   

این اسکریپت دو تا تابع داره:

**‏upgrade()** برای اعمال تغییرات و

**‏downgrade()** ‏برای برگردوندنش.

3⃣ اعمال migration:
با دستور زیر تغییرات رو روی دیتابیس اعمال می‌کنین:

   alembic upgrade head
  

اگه بخواین برگردین به نسخه قبلی:

   alembic downgrade -1
  

4⃣ مدیریت نسخه‌ها:
‏ Alembic یه جدول به اسم alembic_version تو دیتابیستون می‌سازه و نسخه فعلی رو اونجا نگه می‌داره تا همیشه بدونین کجای کار هستین.

🚀 چرا Alembic به وجود اومد؟
قبل از ابزارهایی مثل Alembic، اگه می‌خواستین دیتابیستون رو تغییر بدین، باید خودتون کوئری‌های SQL می‌نوشتین و دستی اجرا می‌کردین. این چندتا مشکل داشت:

خطا:

یه اشتباه کوچیک تو کوئری می‌تونست دیتابیس رو به هم بریزه.

پیچیدگی:

تو پروژه‌های تیمی، هماهنگ کردن تغییرات دیتابیس بین اعضا سخت بود.

بازگشت پذیری:

اگه یه تغییر اشتباه می‌کردین، برگردوندنش یه کابوس بود.

‏Alembic اومد که:

اتوماسیون:

تغییرات رو خودکار تشخیص بده و اسکریپت
بسازه.

نسخه بندی:

تاریخچه تغییرات رو نگه داره و بتونه عقب و
جلو بره.

هماهنگی:

تو تیم‌ها همه بتونن با یه سیستم مشخص کار کنن.

🛠 یه مثال ساده

فرض کنین یه مدل Sqlalchemy دارین

from sqlalchemy import Column, Integer, String
from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()

class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    name = Column(String)

حالا می‌خواین یه ستون email اضافه کنین:

class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    name = Column(String)
    email = Column(String)

با دستور

 alembic revision --autogenerate -m "add email"

‏Alembic یه فایل می‌سازه که تغییرات رو اعمال می‌کنه بعد با

 alembic upgrade head 

دیتابیستون آپدیت می‌شه. به همین راحتی 😎

جمع‌بندی ✍
‏Alembic یه ابزار قدرتمند و باحاله که مدیریت Migrations های دیتابیس رو تو پایتون به یه تجربه لذت‌بخش تبدیل می‌کنه. با Alembic دیگه لازم نیست نگران کوئری‌های خام یا هماهنگی تیمی باشین؛ همه‌چیز خودکار و منظمه. اگه با SQLAlchemy کار می‌کنین، حتماً یه امتحانش کنین و ببینین چقدر زندگی‌تون رو راحت می‌کنه.

#️⃣ #db #alembic #sqlalchemy

➖➖➖➖➖➖➖➖➖

🥷 CHANNEL | GROUP

خب خب خب NoSQL 🚀
امروز می‌خوام درباره یه موضوع جذاب تو دنیای دیتابیس‌ها باهاتون حرف بزنم NoSQL اگه دنبال یه راه‌حل برای مدیریت داده‌های بزرگ، انعطاف‌پذیر و سریع هستین، Nosql گزینه خیلی خوبیه. بیاین با هم ببینیم NoSQL چیه.


🧠 ‏NoSQL چیه؟
‏NoSQL (که مخفف "Not Only SQL" هست) یه دسته از دیتابیس‌های غیررابطه‌ایه که برعکس دیتابیس‌های سنتی رابطه‌ای (مثل MySQL یا PostgreSQL) از ساختار جدول و اسکیما (schema) ثابت استفاده نمی‌کنه (schema less). این دیتابیس‌ها برای مدیریت داده‌های بدون ساختار (unstructured)، نیمه‌ساختار (semi-structured) یا ساختاریافته (structured) طراحی شدن و بهتون انعطاف‌پذیری و مقیاس‌پذیری بالایی می‌دن.

به زبان ساده، NoSQL اومد که بگه "داده‌هات هر شکلی که هستن، من مدیریتشون می‌کنم 😎"


📚 انواع NoSQL
‏NoSQL چند مدل اصلی داره که هر کدوم برای یه نوع داده و کاربرد خاص بهینه شدن:

1️⃣ ‏Key-Value (کلید-مقدار):
ساده‌ترین نوعه، مثل یه دیکشنری بزرگ. یه کلید می‌دی، یه مقدار می‌گیری

مثال: Redis، DynamoDB

‏
2️⃣‏ Document (سندی):
داده‌ها رو به صورت داکیومنت (مثل JSON یا XML) ذخیره می‌کنه. هر داکیومنت می‌تونه ساختار متفاوتی داشته باشه.

مثال: MongoDB، CouchDB

3️⃣‌‏ Column-Family (ستونی):
داده‌ها رو تو ستون‌ها ذخیره می‌کنه و برای دیتاهای بزرگ و تحلیلی عالیه.

مثال: Cassandra، ScyllaDB

4️⃣ ‏Graph:
داده‌ها رو به صورت گراف (node) و یال (edge) ذخیره می‌کنه، مناسب روابط پیچیده هست.

مثال: Neo4j، ArangoDB

چرا NoSQL به وجود اومد؟ 🚀

دیتابیس‌های رابطه‌ای (RDBMS) برای سال‌ها پادشاه بودن، ولی با رشد تکنولوژی و داده‌ها، مشکلاتی پیش اومد:

حجم داده‌ها: وب، اپلیکیشن‌های موبایل و IoT حجم داده‌ها رو به شکل انفجاری زیاد کردن و RDBMSها تو مقیاس بزرگ کند شدن.
ساختار ثابت: جدول‌های RDBMS نیاز به اسکیما دارن و تغییرشون سخت بود، ولی داده‌های امروزی انعطاف‌پذیر و متنوع شدن.
مقیاس‌پذیری عمودی: RDBMSها فقط با ارتقای سخت‌افزار (vertical scaling) بزرگ می‌شن، که گرون و محدوده.
سرعت: تو اپلیکیشن‌های بلادرنگ (مثل چت یا بازی آنلاین)، تاخیر RDBMS جواب نمی‌داد.

‏NoSQL اومد که:
مقیاس‌پذیری افقی:
با اضافه کردن سرورهای بیشتر (horizontal scaling) بزرگ بشه.
انعطاف‌پذیری:
بدون نیاز به اسکیما، هر نوع داده‌ای رو مدیریت کنه.
سرعت:
برای عملیات سریع و بلادرنگ بهینه بشه.


🔍 مزایا و معایب NoSQL
✅ مزایا:
مقیاس‌پذیری: به راحتی با اضافه کردن نود (node) بزرگ می‌شه.
انعطاف‌پذیری: برای داده‌های متنوع و بدون ساختار عالیه.
سرعت: تو عملیات سنگین و بلادرنگ حرف نداره.
توزیع‌شده: به صورت ذاتی برای سیستم‌های توزیع‌شده طراحی شده.

❌ معایب:
عدم تطابق کامل (Consistency): تو بعضی مدل‌ها (مثل BASE به جای ACID)، ممکنه داده‌ها لحظه‌ای ناسازگار باشن.
یادگیری: هر نوع NoSQL دستورات خاص خودش رو داره و یادگیریش زمان میبره.
کمبود تراکنش پیچیده: برای عملیات پیچیده مثل تراکنش‌های بانکی، RDBMS هنوز بهتره.


🎯 کجا از NoSQL استفاده کنیم؟

اپلیکیشن‌های وب و موبایل: برای ذخیره داده‌های کاربرها (مثل پروفایل‌ها).
داده‌های بلادرنگ: چت، اعلان‌ها، بازی‌های آنلاین.
داده‌های بزرگ: تحلیل لاگ‌ها، IoT، سری‌های زمانی.
پروژه‌های مقیاس‌پذیر: وقتی نمی‌دونی داده‌هات چقدر قراره رشد کنن.

جمع‌بندی ✍️
‏NoSQL یه انقلاب تو دنیای دیتابیس‌ها بود که برای دنیای مدرن و داده‌محور امروز طراحی شده. با انعطاف‌پذیری، سرعت و مقیاس‌پذیریش، یه انتخاب خوب برای پروژه‌هاییه که نمی‌خوان تو چارچوب‌های سفت و سخت RDBMS گیر کنن. از MongoDB برای اپلیکیشن‌های وب گرفته تا ScyllaDB برای داده‌های بلادرنگ، NoSQL برای هر نیازی یه جواب داره.

#️⃣ #db #nosql

➖➖➖➖➖➖➖➖➖

🥷 CHANNEL | GROUP

خب خب خب، کامند inspectdb توی جنگو⚙️
احتمالا به این فکر کردین که چطوری میشه از جدول های یه دیتابیس آماده توی جنگو استفاده کرد. راه حلش این ابزاره.

‏inspectdb چیه؟
با استفاده از inspectdb، جنگو میتونه ساختار جدول های دیتابیس رو بررسی کنه و یه فایل مدل جنگو(مثل model.py) تولید کنه و توی خروجی نمایش بده. این یعنی دیگه نیاز نیست برای دیتبایس قدیمیتون دستی مدل بنویسید، جنگو اینکارو هم خودش انجام میده.

python manage.py inspectdb > models.py

➕ شما حتی میتونید فقط یه جدول رو بررسی و تبدیل کنید:

python manage.py inspectdb my_table > models.py

این ابزار میتونه توی این مواقع کمکتون کنه:
1️⃣ وقتی روی یه دیتابیس قدیمی یا پروژه ی legacy کار میکنید.
2️⃣ موقع مهاجرت از یه سیستم دیگه به جنگو.
3️⃣ وقتی میخوان بدون نوشتن کلی کد دستی با یه دیتابیس خارجی کار کنید.

نکته مهم⚠️:
کدی که این ابزار تولید میکنه همیشه تمیز و ایده‌آل نیست. بهتره بعد از ساخت، مدل‌ها رو یه دور بازبینی و شخصی‌سازی کنید. جنگو خودش هم توی فایل تولید شده این هشدار رو مینویسه.


⏺️ برای اطلاعات بیشتر میتونید به داکیومنت جنگو مراجعه کنید:
‏inspectdb در جنگو

#⃣ #django #python #db

➖➖➖➖➖➖➖➖➖➖

🥷🏻 CHANNEL | GROUP

خب خب خب، کامند inspectdb توی جنگو⚙️
احتمالا به این فکر کردین که چطوری میشه از جدول های یه دیتابیس آماده توی جنگو استفاده کرد. راه حلش این ابزاره.

‏inspectdb چیه؟
با استفاده از inspectdb، جنگو میتونه ساختار جدول های دیتابیس رو بررسی کنه و یه فایل مدل جنگو(مثل model.py) تولید کنه و توی خروجی نمایش بده. این یعنی دیگه نیاز نیست برای دیتبایس قدیمیتون دستی مدل بنویسید، جنگو اینکارو هم خودش انجام میده.

python manage.py inspectdb > models.py

➕ شما حتی میتونید فقط یه جدول رو بررسی و تبدیل کنید:

python manage.py inspectdb my_table > models.py

این ابزار میتونه توی این مواقع کمکتون کنه:
1️⃣ وقتی روی یه دیتابیس قدیمی یا پروژه ی legacy کار میکنید.
2️⃣ موقع مهاجرت از یه سیستم دیگه به جنگو.
3️⃣ وقتی میخوان بدون نوشتن کلی کد دستی با یه دیتابیس خارجی کار کنید.

نکته مهم⚠️:
کدی که این ابزار تولید میکنه همیشه تمیز و ایده‌آل نیست. بهتره بعد از ساخت، مدل‌ها رو یه دور بازبینی و شخصی‌سازی کنید. جنگو خودش هم توی فایل تولید شده این هشدار رو مینویسه.


⏺️ برای اطلاعات بیشتر میتونید به داکیومنت جنگو مراجعه کنید:
‏inspectdb در جنگو

#⃣ #django #python #db

➖➖➖➖➖➖➖➖➖➖

🥷🏻 CHANNEL | GROUP

خب خب خب، Redis ولی برای چه کاری؟🗃
خب خیلی وقتا اسم ردیس رو شنیدید ولی دقیقا ندونید که کاربردش چیه و کجا استفاده میشه.

اصلا Redis چی هست؟🤔
خیلی ساده بخوام بگم، ردیس یه دیتابیس in-memory هست که با ساختار کلید و مقدار(key-value) کار میکنه. یعنی داده ها به صورت یک کلید و یک مقدار توش ذخیره میشن. حالا همون in-memory بودنش باعث شده تا سرعت فوقالعاده بالای داشته باشه.

ویژگی های Redis🔍
1️⃣ ‏in-memory بودن که باعث سرعت بالاش شده.
2️⃣ پشتیبانی از TTL یا همون انقضای خودکار داده ها.
3️⃣ ‏Atomic بودن عملیات ها.
4️⃣ پشتیبانی از Pub/Sub برای ارسال پیام بین سرویس ها.
5️⃣ قابلیت Cluster و Scale افقی

خب کجا کاربرد داره؟🛠
کش(Cache): وقتی یه داده ی پرتکرار داریم که نمیخوایم هربار از منبع دریافتش کنیم(مثلا دیتابیس اصلی پروژه) میتونیم یه بار دریافتش کنیم، توی redis ذخیرش کنیم و درنهایت توی درخواست های بعدی اون داده رو از redis دریافت کنیم. فقط باید حواسمون باشه که داده هایی که توی redis هستن بسته به داده ای که داریم توی یه بازه زمانی مشخص آپدیت بشن تا داده های قدیمی برنگردونیم.

صف پیام(Message Queue): خب redis میتونه به عنوان یه صف سبک کار کنه. مثلا برای صف بندی ایمیل هایی که میخوایم ارسال کنیم، تسک های پس زمینه و خیلی چیزای دیگه.

مدیریت نشست ها(Session Management): برای ذخیره سازی session های کاربرا با زمان انقضا. خیلی از سیستم های احراز هویت و مدیریت سبد خرید توی سایت های فروشگاهی از redis استفاده میکنن.

جمع بندی✍️
‏Redis یه ابزار سبک و سریعه که با سرعت فوقلعادش برای کارهای موقتی و سریع عالیه. این دیتابیس داده هارو به شکل key-value ذخیره میکنه. اگه تسکایی دارین که نیاز به دسترسی سریع، ذخیره ی موقت یا مدیریت ساده ی تسک ها نیاز دارن، Redis میتونه انتخاب خوبی باشه.

#️⃣ #programming #db

➖➖➖➖➖➖➖➖➖➖

🥷🏻 CHANNEL | GROUP

خب خب خب، انواع کلید توی دیتابیس های رابطه ای🔑
کلید ها توی دیتابیس ها نقش حیاتی ای توی تضمین یکپارچگی و سازماندهی داده ها دارن. شاید تا الان موقع طراحی دیتابیس به این فکر کرده باشین که مثلا Primary Key چیه؟ چطوری تعیین میشه؟ یا اینکه اصلا Foreign Key چیه؟ توی این پست مهم ترین کلیدهای دیتابیس رو باهم مرور میکنیم.

1. کلید اولیه یا اصلی (Primary Key):
هر جدول یک کلید اولیه داره که رکوردها رو به‌صورت یکتا شناسایی می‌کنه. مقادیر این کلید باید منحصربه‌فرد و غیر NULL باشن.
مثال: توی جدول کاربران، user_id به عنوان کلید اولیه عمل می‌کنه. نمیتونه NULL باشه و حتما باید منحصر به فرد باشه.

2. کلید خارجی (Foreign Key):
کلید خارجی ارتباط بین دو جدول را فراهم می‌کنه و به کلید اولیه یک جدول دیگر اشاره داره. این کلید برای حفظ یکپارچگی مرجع استفاده می‌شه. درواقع ستونی که به کلید اصلی یه جدول دیگه اشاره کنه رو کلید خارجی میگن.
مثال: توی جدول سفارشات، user_id به کلید اولیه جدول کاربران اشاره می‌کنه. کلید اصلی از جدول کاربران توی جدول سفارشات استفاده شده و توی جدول سفارشات بهش میگیم کلید خارجی.

3. کلید ترکیبی (Composite Key):
کلیدی که از ترکیب چند ستون ساخته می‌شه و برای شناسایی یکتا به کار میره. معمولاً زمانی که یک ستون به تنهایی کافی نیست از کلید ترکیبی استفاده می‌شه.
مثال: در جدول ثبت‌نام‌ها، ترکیب student_id و course_id یک کلید ترکیبی ایجاد می‌کنه.

4. کلید کاندید (Candidate Key):
هر ستون یا ترکیبی از ستون‌ها که بتونه به عنوان کلید اصلی استفاده بشه، کلید کاندید نامیده میشه. هر جدول می‌تواند چندین کلید کاندید داشته باشه، اما فقط یکی از اونها به عنوان کلید اصلی انتخاب می‌شن. خیلی ساده تر بخوام بگم ستون یا ستون هایی که میتونستند به عنوان کلید اصلی انتخاب بشن.
مثال: توی جدول محصولات، ستون‌های product_code و product_name می‌تونن به عنوان کلید کاندید عمل کنن.

5. سوپر کلید (Super Key):
سوپر کلید، هر مجموعه‌ای از ستون‌هاست که میتونه هر رکورد توی جدول رو به‌طور یکتا شناسایی کنه. همه کلیدهای کاندید و کلید اصلی، سوپر کلید هستند، ولی هر سوپر کلیدی کاندید نیست.
مثال: ستون user_id یا ترکیب user_id و email در جدول کاربران می‌تواند سوپر کلید باشد.

برای این میگیم هر سوپر کلیدی، کلید کاندید نیست که یه سوپر کلید ممکنه از ترکیب یه کلید اصلی و یه کلید کاندید ایجاد شده باشه(مثلا user_id+user_email) ولی چون فقط با یکی از اینها(user_id) میتونیم یه رکورد رو به صورت یکتا شناسایی کنیم و کلید دومی(user_email) یه جورایی اضافه هست، دیگه این ترکیب کاندید نیست بلکه این فیلد ها هرکدوم یه کلید کاندید به حساب میان.

7. کلید جایگزین (Alternate Key):
زمانی که یک کلید کاندید به عنوان کلید اولیه انتخاب نمیشه، بهش کلید جایگزین میگن. این کلید هنوز قابلیت شناسایی یکتا را داره،ولی به عنوان کلید اصلی انتخاب نشده.
مثال: اگر توی جدول کاربران هم user_id و هم email کلید کاندید باشن و user_id به عنوان کلید اصلی انتخاب بشه، email کلید جایگزین خواهد بود.

8. کلید منحصر به فرد (Unique Key):
مثل کلید کاندیده با این تفاوت که کلید منحصر به فرد می‌تونه مقدار NULL داشته باشه (در بیشتر پایگاه‌داده‌ها حتی چند مقدار NULL مجازه)، ولی مقادیر غیر NULL نباید تکراری باشن. کلید منحصر به فرد در تضمین یکتایی داده‌ها موثر هست.
مثال: توی جدول کاربران، email میتونه یک کلید منحصر به فرد باشه، به این صورت که مقادیر ایمیل نباید تکراری باشن، اما میتونن NULL باشند.

جمع بندی✍️
این کلیدها به شما کمک می‌کنن تا وابستگی‌های تابعی رو بهتر بشناسید و ساختار دیتابیس‌تون رو اصولی و منظم طراحی کنید. همچنین باعث می‌شن دیتابیس‌تون هم مقیاس‌پذیرتر باشه و هم برای تغییرات آینده آماده‌تر.

#️⃣ #programming #db

➖➖➖➖➖➖➖➖➖➖

🥷🏻 CHANNEL | GROUP

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

وابستگی تابعی چیه؟🧐
وابستگی تابعی زمانی رخ میده که مقدار یک ستون در جدول بتونه مقدار یه ستون دیگه رو مشخص کنه. یعنی اگه دو سطر در ستون A مقدار یکسانی داشته باشن، حتما مقدار ستون B هم باید یکسان باشه. وابستگی تابعی رو به شکل زیر نمایش میدیم:
A->B
این نماد به این معناست که ستون A مقدار ستون B رو تعیین میکنه. یا از یه زاویه دیگه بهش نگاه کنیم، ستون B به ستون A وابسته هست.
برای مثال توی جدول کارمندان، emp_id میتونه emp_name رو مشخص کنه. چون هر شناسه کارمند منحصر به فرده و فقط به یک نام خاص اشاره میکنه.

اهمیت وابستگی های تابعی📝
1️⃣بهبود طراحی پایگاه داده:
شناسایی وابستگی های تابعی به ما کمک میکنن تا جدول هامون رو به شکل منطقی و بهینه طراحی کنیم و از تکرار داده ها و اطلاعات جلوگیری کنیم.

2️⃣کاهش ناهماهنگی داده:
نرمال سازی جدول ها بر اساس وابستگی های تابعی، ناهماهنگی و تناقضات داده ها رو کم میکنه و باعث بالا رفتن کیفیت داده ها میشه.

3️⃣پیدا کردن کلیدهای کاندید:
وابستگی های تابعی به پیدا کردن کلیدهای کاندید کمک میکنن.

4️⃣بهینه سازی عملکرد:
طراحی بر اساس وابستگی های تابعی، عملکرد جستجو، به روزرسانی و حذف داده هارو بهینه میکنه و از تداخل جلوگیری میکنه.

5️⃣مدیریت داده های پیچیده:
کمک به درک بهتر ساختار و روابط داده ها در سیستم های پیچیده و جلوگیری از مشکلات احتمالی.

6️⃣نرمال فرم ها:
نرمال فرم ها معمولا براساس این وابستگی ها تعریف میشن و از اون ها برای بهینه سازی ساختار جدول ها استفاده میکنن.

نحوه کشف وابستگی های تابعی🔍
1️⃣تحلیل داده ها:
بررسی رکورد ها و شناسایی الگوها و روابط بین ستون ها.

2️⃣روش های الگوریتمی:
استفاده از الگوریتم هایی مثل Apriori و FD-Mining برای کشف وابستگی های تابعی.

3️⃣تجزیه و تحلیل آماری:
استفاده از روش های آماری مثل تحلیل همبستگی و رگرسیون برای شناسایی وابستگی ها.

4️⃣مقایسه مدل های مفهومی:
ایجاد مدل های مفهومی و مقایسه اونها با داده های واقعی.

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

#️⃣ #programming #db

➖➖➖➖➖➖➖➖➖➖

🥷🏻 CHANNEL | GROUP

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

1️⃣وابستگی تابعی کامل(Full)
زمانی رخ میده که مقدار یه ستون(B) به طور کامل توسط یک ستون دیگه(A) تعیین میشه. یعنی هیچ زیر مجموعه ای از A نمیتونه مقدار B رو تعیین کنه.
مثال: employee_id -> employee_name

2️⃣وابستگی تابعی جزئی(Partial)
زمانی رخ میده که فقط بخشی از یک کلید ترکیبی مقدار یک ستون دیگه رو تعیین میکنه.
مثال: اگر در (employee_id, department_id -> department_name) فقط department_id بتونه به تنهایی department_name رو تعیین کنه این وابستگی رخ میده.

3️⃣وابستگی تابعی متعدی(Transitive)
اگر A مقدار B رو تعیین کنه و B مقدار C رو تعیین کنه، وابستگی متعدی بین A و C رخ میده.
مثال: اگر order_id -> customer_id و customer_id -> customer_name برقرار باشن بنابراین order_id -> customer_name هم برقراره.

4️⃣وابستگی تابعی بدیهی(Trivial)
توی وابستگی تابعی بدیهی مجموعه وابسته زیر مجموعه ای از مجموعه تعیین کننده است و در این صورت مجموعه تعیین کننده مقادیر مجموعه وابسته رو تعیین میکنه.
مثال: (employee_id, employee_name -> employee_name)

5️⃣وابستگی تابعی غیربدیهی(Non-Trivial)
در وابستگی تابعی غیربدیهی مجموعه وابسته زیر مجموعه ای از مجموعه تعیین کننده نیست.
مثال: employee_id -> employee_name

6️⃣وابستگی تابعی چند مقداری(MultiValued)
زمانی رخ میده که یک کلید اولیه میتونه مقدار چندین ستون رو تعیین کنه به شرطی که بین ستون های وابسته هیچ ارتباط یا وابستگی ای نباشه.
مثال: employee_id -> (employee_name, employee_age). توی این مثال id کارمند اسم و سن اون رو تعیین میکنه ولی ارتباط یا وابستگی ای بین سن و اسم کارمند وجود نداره.

جمع بندی✍️
این ها انواع وابستگی های تابعی بودن و سعی کردم ساده و قابل فهم توضیحشون بدم. در اصل پیدا کردن و شناختنشون یکمی پیچیده تر از چیزیه که اینجا بیان شد، میتونین با مراجعه به منابع مختلف دانش خودتون توی این زمینه رو تقویت کنید.

#️⃣ #programming #db

➖➖➖➖➖➖➖➖➖➖

🥷🏻 CHANNEL | GROUP

چرا Async تو کار با دیتابیس همیشه کار امد نیست؟ 🧵

یه باور رایج بین برنامه‌نویس ها اینه که استفاده از Async (برنامه‌نویسی ناهمزمان) تو همه‌چیز معجزه می‌کنه، مخصوصاً وقتی با دیتابیس کار می‌کنین. اما می‌دونستید که Async زدن کد برای کار با دیتابیس همیشه اون تأثیر که فکر می‌کنید رو نداره؟ تو این پست قراره ببینیم چرا.

🧠 چرا Async تو دیتابیس تأثیر کمی داره؟

وقتی با دیتابیس کار می‌کنین (مثل PostgreSQL، MySQL یا MongoDB)، عملیات‌ها مثل خوندن (SELECT)، نوشتن (INSERT) یا آپدیت کردن معمولاً CPU-bound هستن، نه I/O-bound. حالا این یعنی چی؟

‏CPU-bound:
یعنی گلوگاه اصلی تو عملیات، پردازش CPUئه. مثلاً وقتی یه کوئری SQL اجرا می‌کنی، دیتابیس باید کارایی مثل پارس کردن کوئری، بهینه‌سازی پلن، پردازش داده‌ها و مرتب‌سازی رو انجام بده. اینا همشون به CPU وابسته‌ان.

‏I/O-bound:
یعنی گلوگاه اصلی منتظر موندن برای ورودی/خروجی (مثل خوندن از دیسک یا شبکه). Async تو این سناریوها خوب عمل میکنه چون می‌تونه CPU رو آزاد کنه تا وقتی منتظر I/O هستیم، کارهای دیگه انجام بده.

دیتابیس‌ها معمولاً تو محیط‌های خودشون بهینه شدن که عملیات CPU-bound رو سریع انجام بدن (مثل استفاده از ایندکس‌ها یا کش). برای همین، وقتی از یه کلاینت (مثل یه برنامه پایتون) به دیتابیس وصل می‌شین، بیشتر زمان صرف پردازش کوئری تو خود دیتابیسه، نه منتظر شبکه یا دیسک. حالا Async (مثل async/await تو پایتون) اینجا کمک زیادی نمی‌کنه، چون CPU داره کار اصلی رو انجام می‌ده و چیزی برای "منتظر موندن" وجود نداره.

مثال ساده:
فرض کنین یه کوئری سنگین مثل این تو PostgreSQL دارین:

SELECT * FROM orders WHERE total > 1000 ORDER BY created_at;

این کوئری CPU دیتابیس رو حسابی درگیر می‌کنه (برای فیلتر کردن و مرتب‌سازی). حالا اگه تو پایتون اینو با یه کلاینت sync (مثل psycopg2) یا async (مثل asyncpg) اجرا کنین، تفاوت سرعت خیلی کمه، چون گلوگاه اصلی تو خود دیتابیسه، نه تو کلاینت.

📚 چرا Async همیشه مفید نیست؟

وقتی از یه کلاینت Async استفاده می‌کنین (مثل asyncpg یا motor برای MongoDB)، انتظار دارین عملیات دیتابیس سریع‌تر بشه چون می‌تونه همزمان کارهای دیگه رو انجام بده. اما چندتا دلیل باعث می‌شه این تأثیر کم باشه:

1⃣ گلوگاه تو دیتابیسه:
همون‌طور که گفتم، بیشتر عملیات دیتابیس CPU-bound هستن. Async فقط می‌تونه I/O شبکه رو مدیریت کنه (مثل زمان ارسال کوئری یا گرفتن نتیجه)، ولی این بخش معمولاً کسری از کل زمانه.

2⃣ ‏Overhead خود Async: استفاده از async/await یه مقدار سربار (overhead) به کد اضافه می‌کنه. اگه عملیات دیتابیستون سریع باشه (مثلاً چند میلی‌ثانیه)، این سربار ممکنه حتی باعث شه Async کندتر بشه.

3⃣ مدیریت اتصالات:
دیتابیس‌ها معمولاً تعداد اتصالات همزمان (connection pool) رو محدود می‌کنن. حتی با Async، اگه تعداد کوئری‌ها زیاد باشه، ممکنه منتظر اتصال بمونین.

🔍 کی Async به کار میاد؟

هرچند Async تو اکثر عملیات دیتابیس تأثیر زیادی نداره، تو یه سری سناریوها می‌تونه خوب عمل کنه:

1⃣ دیتابیس‌های توزیع‌شده:
تو دیتابیس‌های NoSQL مثل MongoDB یا Cassandra که عملیات شبکه‌ای (مثل اتصال به نودهای مختلف) زمان‌بره، Async می‌تونه کمک کنه کلاینت همزمان چند درخواست رو مدیریت کنه.

2⃣ عملیات I/O-heavy:
اگه دیتابیستون روی یه سرور دور باشه یا شبکه کند باشه، Async می‌تونه زمان انتظار برای اتصال و انتقال داده رو بهتر مدیریت کنه.

3⃣ چندین درخواست همزمان:
اگه برنامه‌تون نیاز داره چند کوئری رو به‌صورت موازی اجرا کنه (مثل یه API که باید از چند جدول داده جمع کنه)، Async می‌تونه این درخواست‌ها رو همزمان مدیریت کنه.

4⃣ دیتابیس‌های خاص:
بعضی دیتابیس‌ها مثل CockroachDB یا Redis که برای عملیات سریع و توزیع‌شده طراحی شدن، با کلاینت‌های Async بهتر کار می‌کنن.

✍ جمع‌بندی
اینکه بگیم Async تو کار با دیتابیس معجزه می‌کنه یه کم زیاده‌رویه چون بیشتر عملیات دیتابیس CPU-bound هستن، استفاده از کلاینت‌های Async مثل asyncpg یا motor معمولاً تأثیر چشمگیری روی پرفورمنس نداره. اما تو سناریوهای خاص مثل دیتابیس‌های توزیع‌شده، عملیات شبکه‌محور یا درخواست‌های موازی، Async می‌تونه مفید باشه. پس قبل از اینکه همه‌چیز رو Async کنین، نوع عملیات‌تون رو بررسی کنین و ببینین کجا واقعاً به کارتون میاد.

#️⃣ #web #programming #db

➖➖➖➖➖➖➖➖➖➖ 

🥷🏻 CHANNEL | GROUP

این داستان ‏Query Planning 😯

احتمالا با دیتابیس هایی مثل PostgreSQL یا MySQL کوئری زدین، اگه دقت کرده باشید این کوری ها چه ساده باشن چه پیچیده سریع اجرا میشن، دلیلشم تو یه فرایند جالب به اسم Query Planning هست.
تو این پست قراره ببینیم چیه، چطور کار می‌کنه.

‏🧠 Query Planning چیه؟

‏Query Planning (یا برنامه‌ریزی کوئری) فرایندی تو دیتابیس‌های رابطه‌ایه که توش دیتابیس تصمیم می‌گیره بهترین راه برای اجرای یه کوئری SQL چیه. وقتی یه کوئری مثل SELECT * FROM users WHERE age > 30
می‌نویسین، دیتابیس نمی‌ره مستقیم اجرا کنه؛ اول یه نقشه می‌کشه که چطور داده‌ها رو پیدا کنه، فیلتر کنه و برگردونه. این نقشه که بهش Query Plan یا Execution Plan می‌گن، مثل یه GPSه که به دیتابیس می‌گه از کدوم مسیر بره تا سریع‌تر به مقصد برسه.

هدف اصلیش بهینه‌سازی پرفورمنس با کم کردن زمان اجرا، مصرف CPU، حافظه و I/O (خوندن/نوشتن دیسک). دیتابیس این کار رو با تحلیل ساختار کوئری، آمار جدول‌ها و ایندکس‌ها انجام می‌ده.

‏📚 Query Planning چطور کار می‌کنه؟

دیتابیس‌ها (مثل PostgreSQL، MySQL، SQL Server) یه بخش به اسم Query Optimizer دارن که مسئول ساختن پلن بهینه‌ست. بیاین قدم‌به‌قدم ببینیم چی به چیه:

1⃣ پارس کردن کوئری (Parsing)
دیتابیس اول کوئری رو بررسی می‌کنه تا مطمئن شه درست نوشته شده (از نظر گرامری و معنایی). مثلاً چک می‌کنه جدول users وجود داره یا نه.
خروجی این مرحله یه درخت نحوی (parse tree)ه که ساختار کوئری رو نشون می‌ده.

2⃣ بازنویسی کوئری (Rewriting)
تو این مرحله، دیتابیس کوئری رو ساده‌تر یا بهینه‌تر می‌کنه، بدون اینکه نتیجه‌ش تغییر کنه. مثلاً:
  تبدیل ساب کوری ها به جوین‌ها.
  حذف شرط‌های اضافی (مثل WHERE TRUE).
تو PostgreSQL، این کار توسط Query Rewriter انجام می‌شه.

3⃣ تولید پلن‌های ممکن (Plan Generation)
حالا Query Optimizer کلی پلن ممکن برای اجرای کوئری می‌سازه. مثلاً برای یه کوئری ساده:

  SELECT * FROM users WHERE age > 30;
  

  ممکنه این گزینه‌ها بررسی شه:

  ‏Sequential Scan:
کل جدول رو خط‌به‌خط بخونه.

  ‏Index Scan:
از ایندکس روی ستون age استفاده کنه.

  ‏Bitmap Scan:
ترکیبی از ایندکس و اسکن.

برای کوئری‌های پیچیده (با جوین، گروه‌بندی و غیره)، تعداد پلن‌ها می‌تونه به هزارتا برسه

4️⃣ تخمین هزینه (Cost Estimation)
دیتابیس برای هر پلن یه هزینه (cost) تخمین می‌زنه. این هزینه یه عدد خیالیه که شامل:

  مصرف CPU (برای مقایسه‌ها، مرتب‌سازی و غیره).

  ‏I/O (خوندن از دیسک یا کش).

شبکه (اگه دیتابیس توزیع‌شده باشه).

دیتابیس از آمار جدول‌ها (مثل تعداد ردیف‌ها، توزیع داده‌ها) و ساختار ایندکس‌ها برای این تخمین استفاده می‌کنه.
مثلاً تو PostgreSQL، دستور ANALYZE این آمار رو به‌روز می‌کنه.

5️⃣ انتخاب بهترین پلن
‏Optimizer پلنی رو انتخاب می‌کنه که کمترین هزینه رو داره. این پلن می‌شه Execution Plan و برای اجرا به Executor فرستاده می‌شه.
تو بعضی دیتابیس‌ها (مثل Oracle)، می‌تونین از hints استفاده کنین تا Optimizer رو به یه پلن خاص هدایت کنین.

6️⃣ اجرا و بازخورد
بعد از اجرا، دیتابیس ممکنه بازخورد بگیره (مثلاً آمار واقعی تعداد ردیف‌ها) و پلن‌های بعدی رو بهتر کنه.

🛠 چرا Query Planning مهمه؟

‏Query Planning مثل مغز دیتابیسه و مستقیم روی پرفورمنس تأثیر می‌ذاره:

سرعت: یه پلن خوب می‌تونه یه کوئری رو از چند دقیقه به چند میلی‌ثانیه برسونه.

مصرف منابع: پلن بد می‌تونه CPU و دیسک رو بیخودی درگیر کنه و سرور رو خفه کنه.

مقیاس‌پذیری: تو دیتابیس‌های بزرگ با میلیون‌ها ردیف، یه پلن بهینه فرق بین موفقیت و فاجعه‌ست.

تجربه کاربر: اگه API‌تون به یه دیتابیس کند وصل باشه، کاربراتون فرار می‌کنن

🔍 مشکلات رایج تو Query Planning

آمار قدیمی: اگه آمار جدول‌ها به‌روز نباشه، Optimizer ممکنه پلن بد انتخاب کنه.

کوئری‌های پیچیده: جوین‌های چندگانه یا شرط‌های مبهم می‌تونن Optimizer رو گیج کنن.

عدم ایندکس: بدون ایندکس، دیتابیس مجبوره کل جدول رو اسکن کنه.

دیتابیس‌های توزیع‌شده:
تو دیتابیس‌هایی مثل CockroachDB، شبکه هم به معادله اضافه می‌شه و پلن‌ها پیچیده‌تر می‌شن.

✍ جمع‌بندی

‏Query Planning مثل یه شطرنج‌باز حرفه‌ایه که تو دیتابیس تصمیم می‌گیره بهترین حرکت چیه. با تحلیل کوئری، آمار جدول‌ها و ایندکس‌ها، یه پلن بهینه می‌سازه که می‌تونه سرعت و کارایی پروژه‌تون رو زیر و رو کنه.

#️⃣ #web #programming #db

➖➖➖➖➖➖➖➖➖➖ 

🥷🏻 CHANNEL | GROUP

تا حالا کلی مطالب خفن و کاربردی تو کانال NinjaLearn براتون آماده کردیم و الان صدها مطلب مختلف و جذاب داریم.

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


این شما و این لیست دسته‌بندی‌های کانال🔻:

🦫 #go: آموزش‌ها و نکات کاربردی زبان گو

💻 #programming: مطالب برنامه نویسی

🐍 #python: ترفندها و نکات پایتونی

🦄 #django: مطالب فریم‌ورک جنگو

⚡️ #fastapi: مطالب فریم ورک فست

🌐 #web: مطالب مرتبط به وب

📡 #network: مطالب مرتبط به شبکه

🗂️ #db: معرفی و نکات دیتابیس

🔖 #reference: معرفی مقاله و ویدیو

📢 #notif: اطلاع رسانی ها

❓ #question: سوالات جالب در برنامه نویسی

🎊 #event: رویداد هایی که معرفی کردیم

🎬 #movie: معرفی فیلم و سریال

📚 #book: معرفی کتاب‌های تخصصی

🤖 #AI: مطالب مرتبط به هوش مصنوعی

📊 #ml: مطالب مرتبط به یادگیری ماشین

🛠️ #backend: آموزش‌ها و ترفندهای بک‌اند

🔒 #security: نکات امنیتی

⚙ #devops: مطالب مرتبط به دواپس

📺 #YouTube: ویدیوهای چنل یوتیوب ما

🌏 #geo: تکنولوژی های جغرافیایی

هر کدوم از این هشتگ‌ها برای یه موضوع خاص طراحی شده تا شما به راحتی بتونید محتوای مورد نظرتون رو پیدا کنید. دیگه لازم نیست کلی تو کانال بگردید 😊

اگه موضوع جدیدی به مطالب کانال اضافه بشه، حتماً تو این لیست قرار می‌گیره ✅

راستی میتونید بنر کانال رو برای دوستاتون هم بفرستید تا اونا هم به جمع ما بپیوندن و از این مطالب مفید استفاده کنن 😉

NinjaLearn Banner 🥷🤝

#category

➖➖➖➖➖➖➖➖➖

🔆 CHANNEL | GROUP