Polimorfinės „Laravel“ asociacijos suteikia būdą, kaip modelis priklausyti daugiau nei vienam kitam modeliui, naudojant vieną asociaciją. Nors šis dinaminis lankstumas yra patrauklus tam tikruose vystymosi scenarijuose, polimorfinės asociacijos turi daugybę galimų trūkumų, kurie gali turėti įtakos duomenų bazės vientisumui, našumui, prižiūrimumui ir masteliui.
Duomenų vientisumo trūkumas ir užsienio raktų apribojimai
Vienas reikšmingiausių polimorfinių asociacijų naudojimo „Laravel“ trūkumų yra nesugebėjimas įgyvendinti užsienio raktų apribojimų duomenų bazės lygiu. Polimorfinės asociacijos paprastai remiasi dviem stulpeliais, susijusiose lentelėje - vienoje, kurioje saugomas susijusio modelio ID, o kita - tipo (klasės pavadinimas) kaip eilutę. Šis dizainas neleidžia naudoti standartinių užsienio raktų apribojimų, nes užsienio rakto nuoroda dinamiškai skiriasi priklausomai nuo susijusio modelio tipo. Todėl duomenų bazės variklis negali garantuoti referencinio vientisumo, todėl gali būti didesnė našlaičių ar nenuoseklių įrašų rizika, jei susiję subjektai ištrinami arba modifikuoti, nesukeliant tinkamo programos veikiančio elgesio.
užklausos sudėtingumas ir našumo problemos
Polimorfinės asociacijos apsunkina užklausą, nes kiekviena užklausa turi filtruoti ir pagal užsienio rakto ID, ir tipo stulpelį. Pvz., Norint gauti konkretaus šaltinio tipo komentarus, reikia nurodyti modelio tipą kartu su ID. Dėl šios jungtinės sąlygos dažnai kyla neefektyvių užklausų, dėl kurių duomenų bazės optimizatorius apsunkina veiksmingai naudoti indeksus, taip sulėtėjus užklausų vykdymui, ypač didėjant duomenų kiekiui. Sudėtiniai rodikliai yra būtini tipo ir ID stulpeliuose, tačiau gali būti sunku optimizuoti. Pats eilutės tipo stulpelis prideda pridėtines pridėtines vertes ir užima daugiau vietos saugyklai, palyginti su tik sveikaisiais klavišais, o tai gali pabloginti bendrą duomenų bazės našumą.
Duomenų bazių normalizavimo pažeidimai ir vienos atsakomybės principas
Tame pačioje lentelėje kaupiant daugybę nesusijusių asociacijų, polimorfinės asociacijos nutraukia atskiros atsakomybės duomenų bazės projektavimo principą. Skirtingų modelių lentelės tampa visais, kurie gali turėti skirtingus atributų rinkinius ir apribojimus. Tai pažeidžia normalizavimo principus, todėl schema tampa ne tokia aiški ir sunkiau įgyvendinama ar patvirtinama duomenų bazės lygiu. Polimorfiniai laukai saugo duomenis, atspindinčius skirtingus subjektus, turinčius skirtingus semantikos ir vientisumo poreikius, o tai apsunkina schemų valdymą ir padidina klaidų ar duomenų anomalijų riziką.
Padidėjęs priežiūros sudėtingumas ir kodo netvarka
Įdiegus polimorfines asociacijas, dažnai atsiranda sudėtinga taikymo logika. Pavyzdžiui, įvesties patvirtinimas, modelio gyvenimo ciklo kabliukai ir verslo taisyklės gali tekti sąlygiškai tvarkyti skirtingus modelio tipus viename polimorfiniame modelyje. Dėl šios priežasties kodas gali būti užgožtas atliekant konkrečios rūšies sąlyginius patikrinimus, sumažinant skaitomumą ir prižiūrimumą. Tobulėjant modeliams, atsižvelgiant į skirtingus reikalavimus, vienas polimorfinis modelis linkęs kaupia atsakomybę, kurią sunku atskirti, todėl gaunama techninė skola.
iššūkiai su nekantriais pakrovimo ir ORM apribojimais
ORM rėmai, tokie kaip „Laravel's“ iškalbingi, turi apribojimų dirbant su polimorfinėmis asociacijomis, ypač dėl nekantrios pakrovimo. Kadangi polimorfiniai ryšiai dinamiškai susieja kelis tipus, ORM negali natūraliai atlikti optimizuoto nekantrios pakrovimo su visais susijusių tipų jungtimis vienoje užklausoje. Šis apribojimas verčia papildomas užklausas ar sudėtingą sprendimo kodą, kad būtų išvengta N+1 užklausų problemų, padidindama kūrimo ir našumo naštą.
Sunkumai vykdant unikalius apribojimus ir indeksavimą
Rašyti unikalius indeksus ar apribojimus, apimančius polimorfines asociacijas, sunku arba neįmanoma dėl kintamo ir sudėtinio raktų pobūdžio. Pavyzdžiui, norint užtikrinti unikalius polimorfinių klavišų derinius, reikia sudėtinių indeksų tiek tipo stulpelyje, tiek ID stulpelyje, kuriuos galima suprojektuoti ir prižiūrėti. Be to, indeksuojantys eilučių tipo stulpeliai yra lėtesni, palyginti su sveikaisiais užsienio raktais, ir sunaudoja daugiau saugojimo vietos, padidindama užklausų kainą.
iššvaistyta duomenų bazės erdvė dėl eilutės tipo stulpelių
Polimorfinės asociacijos naudoja styginių stulpelį, kad išsaugotų susijusio modelio klasės pavadinimą, kuris paprastai yra ilgesnis ir labiau vartojamas erdvėje nei sveikieji užsienio raktai. Ši iššvaistyta erdvė tampa reikšminga per milijonus eilučių. Saugojimas nereikalingų ir ilgų tipų pavadinimų išpūstas lentelės dydis ir gali padidinti I/O pridėtines išlaidas skaitymo ir rašymo metu.
pasenusių ar našlaičių duomenų rizika, nes trūksta kaskadinių ištrynimų
Kadangi duomenų bazė negali įgyvendinti užsienio raktų apribojimų, naudojant kaskadinius polimorfines asociacijas, nesunku kaupti pasenusius įrašus, kai ištrynę tėvų subjektai. Išvalymo atsakomybė visiškai atitinka taikymo kodą, todėl padidėja rizika pamiršti ištremti priklausomus polimorfinius įrašus, kurie gali išlikti kaip našlaičiai ar neteisingi duomenys.
Ribotas užklausos ir sudėtingos ataskaitos
Heterogeninių asociacijų saugojimas polimorfinėse lentelėse apsunkina ataskaitų teikimo ir apibendrinimo užklausas. Tipiškos užklausos, filtravimo ar grupavimo operacijos tampa sudėtingesnės, nes susiję įrašai priklauso skirtingiems lentelėms ar tipams, reikalaujant papildomos logikos, kad jas būtų suvienodinti ar atskirti klausimai. Šis suskaidytas pobūdis pablogina sugebėjimą efektyviai atlikti prasmingą analizę.
Pageidaujamos alternatyvos, o ne polimorfinės asociacijos
Dėl minėtų trūkumų kūrėjai dažnai rekomenduoja polimorfinių asociacijų alternatyvas, kad būtų pasiektas geresnis duomenų vientisumas ir paprastesnė techninė priežiūra:
- Atskiros santykių lentelės: vietoj vienos polimorfinės lentelės naudokite atskiras lenteles su aiškiais užsienio raktais kiekvienam santykio tipui. Tai palaiko duomenų vientisumą su vietinių duomenų bazių apribojimais ir supaprastina užklausas ir indeksavimą.
- Vienos lentelės paveldėjimas (STI) arba klasės lentelės paveldėjimas (CTI): Šie požiūriai į paveldėjimo hierarchijose yra aiškiau ir gali sumažinti tam tikrą polimorfinį sudėtingumą, nors jie taip pat turi apribojimų ir gali padidinti sudėtingumą kitose srityse.
- Kompozicija dėl paveldėjimo: palankumo kompozicija, kai susiję duomenys yra įtraukti į skirtus modelius ir ryšius, pagerinant aiškumą ir palaikymą.