چگونه می توان انجمن های چند شکل در SQL را به طور کارآمد مدیریت کرد؟

آشنایی با انجمن های چند شکل در SQL

مدیریت روابط در پایگاه داده های رابطه ای اغلب منجر به سناریوهای پیچیده می شود ، به ویژه هنگامی که یک نهاد با چندین موجود دیگر در ارتباط باشد. یک مورد کلاسیک در شرایطی است که نمونه های یک جدول (بیایید بگوییم موارد) می توانند متعلق به نمونه های جداول مختلف (مانند بازیکنان و هیولا) باشند. مثال پرس و جو ارائه شده این را با اجرای SQL نشان می دهد که در آن owner منابع ستون یا A نمونه (بازیکن) یا الف B نمونه (هیولا).

مشکل اجرای فعلی

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

مزایای استفاده از محدودیت های کلیدی خارجی

استفاده از محدودیت های کلیدی خارجی در SQL مزایای بی شماری را ارائه می دهد:

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

کاوش در گزینه های دیگر برای طراحی فعلی خود

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

1. از یک جدول اتصال استفاده کنید

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

CREATE TABLE c ( 
    id BIGINT UNSIGNED, 
    owner_id BIGINT UNSIGNED,
    owner_type ENUM('a', 'b')
);

INSERT INTO c VALUES (1, 1, 'a'), (2, 1, 'b'), (3, 3, 'b'), (4, 13, 'b');

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

2. جداول جداگانه برای صاحبان مختلف

طراحی دیگر می تواند شامل ایجاد جداول یا ستون جداگانه برای بازیکنان و هیولا باشد و اجازه می دهد تا مالکیت صریح تعریف شود. در اینجا یک مثال اساسی وجود دارد:

CREATE TABLE a_items (
    id BIGINT UNSIGNED,
    owner_id BIGINT UNSIGNED
);

CREATE TABLE b_items (
    id BIGINT UNSIGNED,
    owner_id BIGINT UNSIGNED
);

به این ترتیب ، نمایش داده شدگان می توانند مستقیماً بر اساس انواع خاص خود بدون ابهام ، موارد را به طور مستقیم واکشی کنند.

بازسازی پرس و جو برای خوانایی بهتر

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

SELECT a.id, a.label, c.id, c.owner_id
FROM a 
JOIN c ON c.owner_id = a.id AND c.owner_type="a"
UNION 
SELECT b.id, b.label, c.id, c.owner_id 
FROM b 
JOIN c ON c.owner_id = b.id AND c.owner_type="b";

این پرس و جو SQL ساده تر و خواندن آسان تر می شود و مدیریت هر دو نوع صاحبان را به طور موثری مدیریت می کند.

سوالات متداول (متداول)

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

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

س: آیا موارد می توانند چندین مالک داشته باشند؟
پاسخ: در حالی که این تنظیم اغلب به وضوح مالکیت را منعکس می کند ، بسته به کاربرد شما ، ممکن است ارزشمند باشد که آیا مالکیت متعدد بخشی از نیازهای شما است یا خیر.

پایان

گزینه های پیشنهادی ضمن افزایش خوانایی و حفظ قابلیت تنظیم SQL شما ، طرح های قوی تری را ارائه می دهند. انتخاب استراتژی که با داده ها و نیازهای کاربردی شما به خوبی مقیاس می یابد ، اطمینان از یکپارچگی داده ها و سهولت در تغییرات آینده ضروری است.