وبلاگ رسانگار
با ما حرفه ای باشید

سرور مجازی NVMe

پیمایش درخت پیش‌سفارش اصلاح شده در جنگو

0 5
زمان لازم برای مطالعه: 11 دقیقه


معرفی

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

ارزیابی اجرای قبلی

مقاله قبلی یک را تعریف کرد Employee کلاسی که به یک جدول پایگاه داده ساختار “employee(id, first_name, last_name, role, manager_id)” ترجمه می شود که در آن manager_id یک کلید خارجی است که به شناسه کارمند نشان دهنده مدیر کارمند فعلی ارجاع می دهد. این نوع پیاده سازی ذخیره سازی داده های بازگشتی در یک پایگاه داده به نام روش لیست مجاور.

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

SELECT id, first_name, last_name, role, manager_id FROM employee ORDER BY id;

میز کارمند

شناسه نام کوچک نام خانوادگی نقش manager_id
1 جین گوزن PRES
2 جان گوزن MGR 1
3 جو Schmo STD 2
4 جان رنگ قهوه ای STD 2
5 آدم اسمیت MGR 1
6 میلت فریدمن STD 5

با نگاهی به جدول کارکنان فهرست شده در بالا می توانید ماهیت سلسله مراتبی داده ها را شناسایی کنید. به عنوان مثال، می توانید بگویید که جین دو رئیس جمهور (بالای سلسله مراتب) است، زیرا ورودی manager_id او خالی است و همچنین می توانید بگویید که دو کارمند، جان دو و آدام اسمیت، به او گزارش می دهند، زیرا ورودی های manager_id آنها برابر با جین است. شناسه کارمند 1.

در زیر با استفاده از یک نمونه از را نشان می دهم Employee کلاس از مقاله قبلی، به نمایندگی از جین دو، برای بازیابی کارمندانی که مستقیماً به او گزارش می دهند.

(venv) $ python manage.py shell
Python 3.6.2 (default, Jul 17 2017, 16:44:45)
>>> from hrmgmt.models import Employee
>>> jane_doe = Employee.objects.get(pk=1)
>>> managers = jane_doe.employee.all()
>>> for m in managers:
...     print(m.first_name, m.last_name, m.role, m.manager_id, m.manager_id)
... 
John Doe MGR 1
Adam Smith MGR 1
>>>

ORM جنگو درخواستی مشابه موارد زیر را صادر می کند تا کارمندان را مستقیماً تحت جین دو قرار دهد. employee ملک نامیده می شود روی نمونه ای از Employee کلاس

SELECT * FROM htmgmt_employee WHERE manager_id = 1  
شناسه نام کوچک نام خانوادگی نقش manager_id
1 جان گوزن MGR 1
5 آدم اسمیت MGR 1

به طور مشابه، برای دریافت کارمندانی که به جان دو گزارش می دهند، باید با آن تماس بگیرید employee زمینه رابطه روی یک Employee نمونه کلاسی که جان دو را نشان می دهد و در زیر سرپوش ORM پرس و جوی مشابه این را صادر می کند:

SELECT * FROM hrmgmt_employee WHERE manager_id = 2
شناسه نام کوچک نام خانوادگی نقش manager_id
3 جو Schmo STD 2
4 جان رنگ قهوه ای STD 2

به این ترتیب می‌توانیم سلسله مراتب شرکت را شناسایی کنیم که از بالا (جین دو) شروع می‌شود و در زنجیره گزارش‌دهی ادامه می‌یابد. با این حال، برای هر مدیر جدیدی که شناسایی می کنید، دوباره باید با آن تماس بگیرید employee ویژگی رابطه و ORM جنگو یک درخواست دیگر را برای بازیابی مجموعه جدیدی از کارمندانی که به مدیر قبلی گزارش می دهند، صادر می کنند.

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

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

شما باید شناسه مدیر جان براون را شناسایی کنید که 2 است، سپس با پایگاه داده تماس بگیرید تا مدیر کارمند با شناسه 2 مشخص شود.


SELECT * FROM htmgmt_employee WHERE first_name = 'John' AND last_name = 'Brown';
شناسه نام کوچک نام خانوادگی نقش manager_id
4 جان رنگ قهوه ای STD 2

SELECT * FROM htmgmt_employee WHERE id = 2;
شناسه نام کوچک نام خانوادگی نقش manager_id
2 جان گوزن MGR 1

این جان دو، مدیر جان براون را برمی گرداند، و می بینیم که manager_id او 1 است که نشان می دهد حداقل یک سطح مدیریتی بالاتر از او وجود دارد. یک بار دیگر درخواست دیگری را برای تعیین اینکه آیا کارمند با شناسه 1 بالاترین سلسله مراتب مدیریتی را به دست می آورد یا سطح دیگری از مدیریت وجود دارد صادر می کنیم.


SELECT * FROM htmgmt_employee WHERE id = 1;
شناسه نام کوچک نام خانوادگی نقش manager_id
1 جین گوزن PRES خالی

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

پیمایش درخت پیش سفارش اصلاح شده

خوشبختانه روش دیگری برای ذخیره و بازیابی داده های سلسله مراتبی در یک پایگاه داده به نام پیمایش درخت پیش سفارش اصلاح شده (MPTT) وجود دارد. این روش دوم از یک ساختار داده درختی برای مدل‌سازی داده‌ها، همراه با برخی برچسب‌گذاری‌های بصری گره‌های مرتبط درخت استفاده می‌کند که امکان عبور از برچسب‌ها را فراهم می‌کند.

در زیر یک نمایش درختی از داده های جدول لیست قبلی کارمندان است.

ساختار درختی MPTT کارمند

طرح برچسب گذاری با قرار دادن 1 در سمت چپ شروع می شود root node، رئیس جمهور جین دو در این مثال، سپس شما یک را پایین می آورید node سمت چپ root. در این node بلافاصله در زیر و به سمت چپ تعداد را افزایش دهید و این را برچسب جدید کنید node با 2. این process ادامه می دهد تا پایین ترین فرزند (برگ) node، جو اشمو در این مثال. سپس به سمت راست کودک برچسب بزنید node با افزایش بعدی و به صورت جانبی از طریق خواهر و برادر به سمت چپ و راست برچسب زدن سمت راست حرکت کنید، هر چه می‌روید افزایش می‌یابد.

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

کار بعدی این است که این درخت تودرتو را به یک ساختار میز مسطح ترجمه کنید. این با تعریف دو ستون اضافی از مقادیر “چپ” و “راست” انجام می شود. با این حال، از آنجایی که چپ و راست کلمات کلیدی رزرو شده در زبان SQL هستند، پیاده‌سازی‌های واقعی از اختصارات مانند “lft” و “rgt” استفاده می‌کنند.

در زیر یک جدول نمونه از اجرای حداقل جدول ساختار یافته MPTT برای فهرست کارمندان آورده شده است.

staff_mptt

شناسه نام کوچک نام خانوادگی نقش manager_id ft rgt
1 جین گوزن PRES 1 12
2 جان گوزن MGR 1 2 7
3 جو Schmo STD 2 3 4
4 جان رنگ قهوه ای STD 2 5 6
5 آدم اسمیت MGR 1 8 11
6 میلت فریدمن STD 5 9 10

اکنون که داده‌ها سازماندهی شده و با مقادیر ستون‌های lft و rgt مشروح شده‌اند، انعطاف‌پذیری، کنترل و کارایی بیشتری در روش بازیابی داده‌ها به دست آورده‌ایم.

با استفاده از جدول ساختار یافته MPTT در بالا می توانید کارمندانی را که با استفاده از پرس و جوی SQL زیر به مدیر John Doe گزارش می دهند فهرست کنید.

SELECT * FROM employee_mptt WHERE lft > 2 and rgt < 7 ORDER BY lft;

با این حال، برای نشان دادن کارایی ساختار MPTT، من دوباره الحاق مدیریت را با شروع از جان براون دنبال می کنم. من می توانم این کار را با گنجاندن چند گزاره در بخش WHERE پرس و جو انجام دهم، با مشخص کردن اینکه lft کمتر از 6 و rgt بزرگتر از 6 باشد و سپس ORDER-ing توسط rgt سلسله مراتب مدیریت را به ترتیب صعودی فهرست می کند، همه در یک سفر به پایگاه داده.

SELECT * FROM employee_mptt WHERE lft < 5 AND rgt > 6 ORDER BY rgt;
شناسه نام کوچک نام خانوادگی نقش manager_id ft rgt
2 جان گوزن MGR 1 2 7
1 جین گوزن PRES 1 12

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

abs((rgt - lft - 1)) / 2 = # of managed employees

با وصل کردن مقادیر rgt و lft جان، دریافت می کنیم:

abs((2 - 7 - 1)) / 2 = 2

این پاسخ را در اختیار ما قرار می دهد و اصلاً نیازی به تعامل اضافی با پایگاه داده نیست.

Django-mptt

جامعه عالی با استفاده و توسعه چارچوب وب جنگو، این را تولید کرده است جنگو-MPTT پروژه ای که قابلیت های پایه جنگو را گسترش داده و MPTT را پیاده سازی می کند. پروژه Django-MPTT تعدادی راحتی ارائه می دهد که تعامل با داده های سلسله مراتبی در ساختار MPTT را بسیار راحت می کند و در عین حال به کارایی مرتبط با بازیابی داده MPTT دست می یابد.

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

اگر می‌خواهید دنبال کنید، می‌توانید کد را از حساب GitHub من دانلود کنید اینجا از برچسب ابتدای این آموزش به نام “mptt-start” شروع می شود.

فرمان خود را باز کنید terminal، یک محیط مجازی جدید ایجاد کنید و الزامات زیر را نصب کنید:

(venv) $ pip install django django-mptt

پس از اجرای مهاجرت های اولیه همانطور که در مقاله قبلی توضیح داده شد، پروژه را در محیط توسعه یکپارچه یا ویرایشگر متن مورد علاقه خود بارگیری کنید و اسکریپت پایتون مدل را در فهرست “hrmgmt” باز کنید و کد زیر را اضافه کنید.



from django.db import models

from mptt.models import MPTTModel, TreeForeignKey

class EmployeeMptt(MPTTModel):
   STANDARD = 'STD'
   MANAGER = 'MGR'
   SR_MANAGER = 'SRMGR'
   PRESIDENT = 'PRES'

   EMPLOYEE_TYPES = (
       (STANDARD, 'base employee'),
       (MANAGER, 'manager'),
       (SR_MANAGER, 'senior manager'),
       (PRESIDENT, 'president'))

   role = models.CharField(max_length=25, choices=EMPLOYEE_TYPES)
   first_name = models.CharField(max_length=100)
   last_name = models.CharField(max_length=100)
   parent = TreeForeignKey('self', null=True, related_name='employee')

   def __str__(self):
       return "<EmployeeMptt: {} {}>".format(self.first_name, self.last_name)

   def __repr__(self):
       return self.__str__()

اولین بیانیه جدید واردات را برای MPTTModel و TreeForeignKey کلاس ها از کتابخانه django-mptt. سپس EmployeeMptt کلاس تعریف شده است.

را EmployeeMptt کلاس از the به ارث می برد MPTTModel که فیلدهای کلاس را اضافه می کند lft، rght، level، و tree_id به زیر کلاس (EmployeeMptt). زمینه ها به شرح زیر عمل می کنند:

  • lft: یک فیلد عدد صحیح همانطور که در قسمت قبل توضیح داده شد
  • rght: یک فیلد عدد صحیح همانطور که در قسمت قبل توضیح داده شد
  • level: یک فیلد عدد صحیح که سطح سلسله مراتب را برای هر نمونه نشان می دهد
  • tree_id: یک فیلد عدد صحیح مشابه مقاله قبلی Employee class manager_id

با این حال، یک ویژگی مفیدتر ناشی از ارث بردن از MPTTModel روش‌هایی هستند که همراه با آن پیاده‌سازی فیلدهای فوق‌الذکر را انتزاعی می‌کنند و کارکردهای ترجیحی را برای کار با ساختار درختی ارائه می‌دهند.

  • get_ancestors (صعودی=نادرست، include_self=نادرست)
  • get_children()
  • get_decendants(include_self=False)
  • get_decendant_count()
  • get_family()
  • get_next_sibling()
  • get_previous_sibling()
  • get_root()
  • get_siblings (include_self=False)
  • insert_at(target، position=’first-child’، save=False)
  • is_child_node()
  • is_leaf_node()
  • is_root_node()
  • move_to (هدف، موقعیت = ‘فرزند اول’)

را TreeForeignKey فیلد اساساً مانند معمول رفتار می کند django.db.models.ForeignKey اما همچنین گزینه های سلسله مراتب درخت را با تودرتو در فرم های جنگو نمایش می دهد.

اکنون که کدی را برای تعریف آن نوشتیم EmployeeMptt، اجازه دهید کد مدل را با توجه به ساختار MPTT به جداول پایگاه داده ترجمه کنیم. در شما terminal ایجاد و اجرای یک مهاجرت برای EmployeeMptt کلاس:

(venv) $ python manage.py makemigrations
Migrations for 'hrmgmt':
  hrmgmt/migrations/0002_employeemptt.py
    - Create model EmployeeMptt

DDL SQL صادر شده را بررسی کنید:

(venv) $ python manage.py sqlmigrate hrmgmt 0002
BEGIN;
--
-- Create model EmployeeMptt
--
CREATE TABLE "hrmgmt_employeemptt" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "role" varchar(25) NOT NULL, "first_name" varchar(100) NOT NULL, "last_name" varchar(100) NOT NULL, "lft" integer unsigned NOT NULL, "rght" integer unsigned NOT NULL, "tree_id" integer unsigned NOT NULL, "level" integer unsigned NOT NULL, "parent_id" integer NULL REFERENCES "hrmgmt_employeemptt" ("id"));
CREATE INDEX "hrmgmt_employeemptt_lft_c82902c3" روی "hrmgmt_employeemptt" ("lft");
CREATE INDEX "hrmgmt_employeemptt_rght_c6110254" روی "hrmgmt_employeemptt" ("rght");
CREATE INDEX "hrmgmt_employeemptt_tree_id_7abd1eb2" روی "hrmgmt_employeemptt" ("tree_id");
CREATE INDEX "hrmgmt_employeemptt_level_687f7b49" روی "hrmgmt_employeemptt" ("level");
CREATE INDEX "hrmgmt_employeemptt_parent_id_88909826" روی "hrmgmt_employeemptt" ("parent_id");
COMMIT;

مهاجرت را اجرا کنید:

(venv) $ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, hrmgmt, sessions
Running migrations:
  Applying hrmgmt.0002_employeemptt... OK

اکنون از پوسته جنگو برای پر کردن جدول جدید “hrmgmt_employeemptt” استفاده کنید و همزمان با API Django-MPTT آشنا شوید:

(venv) $ python manage.py shell
Python 3.6.2 (default, Jul 17 2017, 16:44:45) 
(InteractiveConsole)
>>> from hrmgmt.models import EmployeeMptt
>>> jane_doe = EmployeeMptt.objects.create(first_name='Jane', last_name='Doe', role=EmployeeMptt.PRESIDENT)
>>> john_doe = EmployeeMptt.objects.create(first_name='John', last_name='Doe', role=EmployeeMptt.MANAGER, parent=jane_doe)
>>> joe_schmo = EmployeeMptt.objects.create(first_name='Joe', last_name='Schmo', role=EmployeeMptt.STANDARD, parent=john_doe)
>>> john_brown = EmployeeMptt.objects.create(first_name='John', last_name='Brown', role=EmployeeMptt.STANDARD, parent=john_doe)
>>> adam_smith = EmployeeMptt.objects.create(first_name='Adam', last_name='Smith', role=EmployeeMptt.MANAGER, parent=jane_doe)
>>> milt_friedman = EmployeeMptt.objects.create(first_name='Milt', last_name='Friedman', role=EmployeeMptt.STANDARD, parent=adam_smith)

خیلی پیچیده نیست، درست است؟ تاکنون تنها چیزی که مربوط به Django-MPTT API است، استفاده از آن است parent رشته. این برای کتابخانه Django-MPTT ضروری است تا رکوردها را با فیلدهای lft، rght، tree_id و سطح مناسب حاشیه نویسی کند که به جدولی با نام “hrmgmt_employeemptt” منتهی می شود که به صورت زیر پر شده است.

htmgmt_employeemptt

شناسه نام کوچک نام خانوادگی نقش ft راست tree_id مرحله شناسه اصلی
1 جین گوزن PRES 1 12 1 0 خالی
2 جان گوزن MGR 2 7 1 1 1
3 جو Schmo STD 3 4 1 2 2
4 جان رنگ قهوه ای STD 5 6 1 2 2
5 آدم اسمیت MGR 8 11 1 1 1
6 میلت فریدمن STD 9 10 1 2 5

اکنون اجازه دهید با بازی با روش‌های کاربردی عالی که Django-MPTT ارائه می‌کند، از این کتابخانه خوب قدردانی کنیم.

فرض کنید می‌خواهیم فهرستی از کارمندانی که مستقیماً به رئیس جمهور جین دو گزارش می‌دهند (یعنی جان دو و آدام اسمیت) دریافت کنیم. root node درخت MPTT

>>> jane_doe.get_children()
<TreeQuerySet (<EmployeeMptt: John Doe>, <EmployeeMptt: Adam Smith>)>

خوب، تا اینجا خیلی خاص نیست، درست است؟ این اساساً همان نتیجه قبلی را برای ما به ارمغان آورد jane\_doe.employee.all() و ما قبلاً ثابت کرده‌ایم که این اساساً عملکرد مشابهی با اجرای لیست مجاور دارد. با این حال، بگویید من می‌خواستم همه کارمندان شرکت را نسبت به جین دو پایین بیاورم:

>>> jane_doe.get_descendants()
<TreeQuerySet (<EmployeeMptt: John Doe>, <EmployeeMptt: Joe Schmo>, <EmployeeMptt: John Brown>, <EmployeeMptt: Adam Smith>, <EmployeeMptt: Milt Friedman>)>

خوب این بسیار نرم بود، زیرا ما همه اینها را در یک سفر به پایگاه داده به دست آوردیم.

چیز دیگری که ممکن است جالب باشد دیدن همه کارمندان است روی همان سطح دیگری است، جان براون بگویید:

>>> john_brown.get_siblings()
<TreeQuerySet (<EmployeeMptt: Joe Schmo>)>

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

>>> john_brown.get_ancestors()
<TreeQuerySet (<EmployeeMptt: Jane Doe>, <EmployeeMptt: John Doe>)>

خیلی ساده، درست است؟ و دوباره، فقط یک سفر به پایگاه داده.

سایر روش های کاربردی ارائه شده توسط Django-MPTT با نام های بصری بسیار ساده هستند. از شما دعوت می‌کنم تا روش‌های کاربردی دیگر را بیشتر بررسی کنید اسناد رسمی.

مبادله بین لیست مجاور و MPTT

همانطور که در مورد بسیاری از وظایفی که توسعه دهندگان نرم افزار با آن روبرو هستند، ما اغلب نیاز به تصمیم گیری های مهم در رابطه با استراتژی پیاده سازی داریم. در مقاله اول روی روابط بازگشتی با Django I یک روش پیاده سازی را نشان داد که به عنوان “لیست مجاور” شناخته می شود. در حالی که در این مقاله بعدی روش پیاده سازی دیگری را ارائه کردم که به نام “پیمایش درخت پیش سفارش اصلاح شده (MPTT)” شناخته می شود. هر دو الزامات اساسی مورد استفاده ما را برآورده می کنند. بنابراین، هنگامی که با یک کار برنامه نویسی مواجه می شوید که ذاتاً بازگشتی است، مانند موردی که در اینجا نشان داده شده است، کدام را باید انتخاب کنید؟

روش لیست مجاور برای استدلال و تعامل با آن از دیدگاه کدنویسی با جنگو و همچنین استفاده از SQL خام و برنامه‌نویسی رویه‌ای نسبتاً ساده است. با این حال، نگاه انتقادی به سطح پایگاه داده (عادی SELECT پرس و جوها) با سفرهای زیاد به پایگاه داده کمی تکراری و گران است.

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

با این حال، یک رشته اصلی وجود دارد گوچا قبل از رفتن از آن آگاه باشید و در نظر بگیرید روی پیاده سازی MPTT در تمام برنامه های جنگو:

MPTT برای مواردی که داده‌های سلسله مراتبی نسبتاً ثابتی دارید که اغلب از طریق آنها قابل دسترسی هستند، بهترین است. SELECT بیانیه.

به‌روزرسانی ورودی‌ها در جدول ساختار یافته MPTT گران است، زیرا شما باید مقادیر چپ و راست تقریباً هر ورودی را تغییر دهید، اما همچنین بسیار پیچیده است. process. خوشبختانه Django-MPTT با برخی از روش‌های خوب ارائه می‌شود که از پیچیدگی مراقبت می‌کنند، اما این مسئله مشکل به‌روزرسانی تقریباً مقادیر چپ، راست و سطح هر ورودی را کاهش نمی‌دهد.

به طور خلاصه، پیشنهاد می‌کنم لیست مجاور را در مواردی که انتظار دارید داده‌ها به صورت نیمه مکرر یا بیشتر به‌روزرسانی شوند، پیاده‌سازی کنید و زمانی که انتظار می‌رود داده‌ها نسبتا ثابت بمانند، Django-MPTT را بیرون بکشید تا بتوانید از افزایش عملکرد بازیابی عالی لذت ببرید.

امیدوارم از مقاله لذت برده باشید و مثل همیشه لطفا در صورت لزوم نظر یا نقد خود را بنویسید.

(برچسب‌ها به ترجمه)# python



منتشر شده در 1403-01-29 11:35:04

امتیاز شما به این مطلب
دیدگاه شما در خصوص مطلب چیست ؟

آدرس ایمیل شما منتشر نخواهد شد.

لطفا دیدگاه خود را با احترام به دیدگاه های دیگران و با توجه به محتوای مطلب درج کنید