الترقيم (Pagination) يقسم مجموعة كبيرة من النتائج إلى صفحات منفصلة، حتى لا تقوم بتحميل آلاف السجلات في نفس الوقت. إنه ضروري للأداء والقابلية للاستخدام. يوفر Django فئة Paginator للقوالب والمناظر، و DRF يوفر ترقيماً مدمجاً للـ APIs.
# ❌ loading everything — slow, memory-heavy, bad UX with thousands of rows
articles = Article.objects.()
from django.core.paginator import Paginator
def article_list(request):
articles = Article.objects.all().order_by("-created_at") # ORDER matters for consistent pages
paginator = Paginator(articles, 20) # 20 items per page
page_number = request.GET.get("page") # ?page=2
page_obj = paginator.get_page(page_number) # the requested page
return render(request, "list.html", {: page_obj})
<!-- in the template -->
{% for article in page_obj %}
<h2>{{ article.title }}</h2>
{% endfor %}
{% if page_obj.has_previous %}<a href="?page={{ page_obj.previous_page_number }}">Prev</a>{% endif %}
Page {{ page_obj.number }} of {{ page_obj.paginator.num_pages }}
{% if page_obj.has_next %}<a href="?page={{ page_obj.next_page_number }}">Next</a>{% endif %}
يقوم Paginator بتقسيم مجموعة الاستعلام إلى صفحات و get_page() تُرجع كائن صفحة مع أدوات الملاحة (has_next, next_page_number، إلخ) — لاحظ أنها تضيف LIMIT/OFFSET إلى الاستعلام، لذلك يتم جلب صفحة واحدة فقط من قاعدة البيانات.
# global default in settings.py
REST_FRAMEWORK = {
"DEFAULT_PAGINATION_CLASS": "rest_framework.pagination.PageNumberPagination",
"PAGE_SIZE": 20,
}
# now list endpoints are automatically paginated, returning:
# { "count": 1000, "next": "...?page=3", "previous": "...?page=1", "results": [...] }
يقوم DRF بترقيم نقاط نهاية القائمة تلقائياً بمجرد تكوينها، مما يُرجع بيانات وصفية للصفحة (العدد، الروابط التالية/السابقة) إلى جانب النتائج — يتنقل العملاء عبر الروابط المقدمة.
PageNumberPagination → ?page=2 (simple page numbers)
LimitOffsetPagination → ?limit=20&offset=40 (flexible offsets)
CursorPagination → opaque cursor; consistent & performant for large/changing data
(avoids OFFSET performance issues on huge datasets)
⚠️ OFFSET-based pagination (page/offset) gets SLOWER on deep pages of huge tables
(the DB must skip OFFSET rows). For very large datasets, CURSOR pagination
(keyset, using a WHERE on an indexed column) is far more efficient.
⚠️ Always ORDER BY a stable field, or pages can be inconsistent/repeat items.
الترقيم ضروري لبناء تطبيقات ذات أداء عالية وقابلة للاستخدام تتعامل مع أحجام بيانات حقيقية — بدونه، تصبح نقاط نهاية القائمة والصفحات التي تحمل جداول كاملة (ربما آلاف أو ملايين الصفوف) بطيئة وتستهلك الكثير من الذاكرة وغير قابلة للاستخدام، مما يرهق قاعدة البيانات والمستخدمين والعملاء على حد سواء.
فهم الترقيم هو معرفة عملية يومية: Paginator الخاص بـ Django يتعامل مع المناظر التقليدية/القوالب (تقسيم مجموعات الاستعلام إلى صفحات مع أدوات ملاحة، وجلب صفحة واحدة فقط بكفاءة عبر LIMIT/OFFSET)، و الترقيم المدمج في DRF يتعامل مع الـ APIs (ترقيم نقاط نهاية القائمة تلقائياً مع البيانات الوصفية وروابط الملاحة بمجرد تكوينها) — كلاهما ضروري اعتماداً على ما إذا كنت تبني صفحات معروضة على الخادم أو APIs.
معرفة كيفية تنفيذ الترقيم في كلا السياقين ضروري لتقريباً أي ميزة لعرض البيانات.
الفارق الدقيق في الأداء هو معرفة قيمة على مستوى أعلى بشكل خاص: الترقيم القائم على OFFSET القياسي يتدهور على الصفحات العميقة من الجداول الضخمة جداً (يجب على قاعدة البيانات تخطي جميع الصفوف السابقة)، لذلك ترقيم المؤشر (keyset) هو الخيار الفعال لمجموعات البيانات الضخمة أو سريعة التغير، و الترتيب دائماً حسب حقل مستقر ضروري لتجنب النتائج غير المتسقة أو المكررة عبر الصفحات.
فهم الميكانيكا الأساسية (Paginator، فئات ترقيم DRF) وهذه الاعتبارات الأداء (ترقيم OFFSET مقابل ترقيم المؤشر، الترتيب المتسق) مهم لبناء تطبيقات تبقى سريعة وصحيحة مع نمو البيانات — الترقيم هو متطلب موجود في كل مكان، والقيام به بشكل صحيح، خاصة على نطاق واسع، هو مهارة عملية تؤثر مباشرة على أداء التطبيق وتجربة المستخدم.
مكتبة من أسئلة مقابلات تقنية المعلومات مع إجابات مفصّلة — من المبتدئ إلى المتقدم.
تبرع