Django mudelite pärilus: Abstraktsed baasmudelid vs. mitme tabeli pärilus

Django objekt-relatsiooniline kaardistaja (ORM) pakub võimsaid funktsioone andmete modelleerimiseks ja andmebaasidega suhtlemiseks. Üks Djangos tõhusa andmebaasi disaini võtmeaspekte on mudelite päriluse mõistmine ja kasutamine. See võimaldab teil taaskasutada ühiseid välju ja käitumisviise mitmes mudelis, vähendades koodi dubleerimist ja parandades hooldatavust. Django pakub kahte peamist tüüpi mudelite pärilust: abstraktsed baasklassid ja mitme tabeli pärilus. Igal lähenemisel on oma kasutusjuhud ja mõju andmebaasi struktuurile ning päringute jõudlusele. See artikkel pakub põhjaliku ülevaate mõlemast, juhendades teid, millal kumbagi tüüpi kasutada ja kuidas neid tõhusalt rakendada.

Mudelite päriluse mõistmine

Mudelite pärilus on objektorienteeritud programmeerimise põhimõiste, mis võimaldab teil luua uusi klasse (Djangos mudeleid) olemasolevate põhjal. Uus klass pärib vanemklassi atribuudid ja meetodid, võimaldades teil laiendada või spetsialiseerida vanema käitumist koodi ümber kirjutamata. Djangos kasutatakse mudelite pärilust väljade, meetodite ja meta-valikute jagamiseks mitme mudeli vahel.

Õige pärilustüübi valimine on hästi struktureeritud ja tõhusa andmebaasi ehitamisel ülioluline. Päriluse vale kasutamine võib põhjustada jõudlusprobleeme ja keerulisi andmebaasiskeeme. Seetõttu on oluline mõista iga lähenemise nüansse.

Abstraktsed baasklassid

Mis on abstraktsed baasklassid?

Abstraktsed baasklassid on mudelid, mis on loodud pärimiseks, kuid mida ei ole mõeldud otse instantsieerima. Need toimivad teiste mudelite kavanditena, määratledes ühised väljad ja meetodid, mis peaksid olema olemas kõigis alamudelites. Djangos määratlete abstraktse baasklassi, seades mudeli Meta klassi atribuudi abstract väärtuseks True.

Kui mudel pärib abstraktsest baasklassist, kopeerib Django kõik abstraktses baasklassis määratletud väljad ja meetodid alamudelisse. Kuid abstraktset baasklassi ennast ei looda andmebaasis eraldi tabelina. See on oluline erinevus mitme tabeli pärilusest.

Millal kasutada abstraktseid baasklasse

Abstraktsed baasklassid on ideaalsed, kui teil on ühiste väljade komplekt, mida soovite lisada mitmesse mudelisse, kuid te ei pea abstraktset baasklassi otse pärima. Mõned levinud kasutusjuhud hõlmavad:

• Ajatempliga mudelid: created_at ja updated_at väljade lisamine mitmesse mudelisse.
• Kasutajaga seotud mudelid: user välja lisamine mudelitele, mis on seotud konkreetse kasutajaga.
• Metaandmete mudelid: Väljade nagu title, description ja keywords lisamine SEO eesmärkidel.

Abstraktse baasklassi näide

Loome näite abstraktsest baasklassist ajatempliga mudelite jaoks:

            
from django.db import models

class TimeStampedModel(models.Model):
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        abstract = True

class Article(TimeStampedModel):
    title = models.CharField(max_length=200)
    content = models.TextField()

    def __str__(self):
        return self.title

class Comment(TimeStampedModel):
    article = models.ForeignKey(Article, on_delete=models.CASCADE)
    text = models.TextField()

    def __str__(self):
        return self.text

            

              
                Copy
              
            
          

Selles näites on TimeStampedModel abstraktne baasklass väljadega created_at ja updated_at. Nii Article kui ka Comment mudelid pärivad TimeStampedModel klassist ja saavad automaatselt need väljad. Kui käivitate käsu python manage.py migrate, loob Django kaks tabelit, Article ja Comment, millest mõlemal on väljad created_at ja updated_at. `TimeStampedModel` enda jaoks tabelit ei looda.

Abstraktsete baasklasside eelised

• Koodi taaskasutatavus: Väldib ühiste väljade ja meetodite dubleerimist mitmes mudelis.
• Lihtsustatud andmebaasi skeem: Vähendab tabelite arvu andmebaasis, kuna abstraktne baasklass ise ei ole tabel.
• Parem hooldatavus: Muudatused abstraktses baasklassis kajastuvad automaatselt kõigis alamudelites.

Abstraktsete baasklasside puudused

• Otsene pärimine puudub: Abstraktset baasklassi ei saa otse pärida. Saate pärida ainult alamudeleid.
• Piiratud polümorfism: Erinevate alamudelite instantside ühetaoline käsitlemine on keerulisem, kui peate pääsema juurde abstraktses klassis määratletud ühistele väljadele ühe päringu kaudu. Peate iga alamudelit eraldi pärima.

Mitme tabeli pärilus

Mis on mitme tabeli pärilus?

Mitme tabeli pärilus on mudelite päriluse tüüp, kus igal mudelil pärilushierarhias on oma andmebaasi tabel. Kui mudel pärib teisest mudelist, kasutades mitme tabeli pärilust, loob Django automaatselt üks-ühele seose alamudeli ja vanemmudeli vahel. See võimaldab teil pääseda juurde nii alam- kui ka vanemmudeli väljadele ühe alamudeli instantsi kaudu.

Millal kasutada mitme tabeli pärilust

Mitme tabeli pärilus sobib, kui soovite luua spetsialiseeritud mudeleid, millel on selge "on-tüüpi" (is-a) seos üldisema mudeliga. Mõned levinud kasutusjuhud hõlmavad:

• Kasutajaprofiilid: Spetsialiseeritud kasutajaprofiilide loomine erinevat tüüpi kasutajatele (nt kliendid, tarnijad, administraatorid).
• Tootetüübid: Spetsialiseeritud tootemudelite loomine erinevat tüüpi toodetele (nt raamatud, elektroonika, rõivad).
• Sisu tüübid: Spetsialiseeritud sisumudelite loomine erinevat tüüpi sisule (nt artiklid, blogipostitused, uudised).

Mitme tabeli päriluse näide

Loome näite mitme tabeli pärilusest kasutajaprofiilide jaoks:

            
from django.db import models
from django.contrib.auth.models import User

class Customer(User):
    phone_number = models.CharField(max_length=20, blank=True)
    address = models.CharField(max_length=200, blank=True)

    def __str__(self):
        return self.username

class Vendor(User):
    company_name = models.CharField(max_length=100, blank=True)
    payment_terms = models.CharField(max_length=100, blank=True)

    def __str__(self):
        return self.username

            

              
                Copy
              
            
          

Selles näites pärivad nii Customer kui ka Vendor mudelid sisseehitatud User mudelist. Django loob kolm tabelit: auth_user (User mudeli jaoks), customer ja vendor. Tabelil customer on üks-ühele seos (implitsiitselt ForeignKey) tabeliga auth_user. Samamoodi on tabelil vendor üks-ühele seos tabeliga auth_user. See võimaldab teil pääseda juurde standardsetele User väljadele (nt username, email, password) Customer ja Vendor mudelite instantside kaudu.

Mitme tabeli päriluse eelised

• Selge "on-tüüpi" seos: Esindab selget hierarhilist suhet mudelite vahel.
• Polümorfism: Võimaldab käsitleda erinevate alamudelite instantse vanemmudeli instantsidena. Saate pärida kõiki `User` objekte ja saada tulemusi, mis sisaldavad nii `Customer` kui ka `Vendor` instantse.
• Andmete terviklikkus: Jõustab viiteterviklikkuse alam- ja vanemtabelite vahel üks-ühele seose kaudu.

Mitme tabeli päriluse puudused

• Suurenenud andmebaasi keerukus: Loob andmebaasi rohkem tabeleid, mis võib suurendada keerukust ja potentsiaalselt aeglustada päringuid.
• Jõudluse lisakulu: Mitut tabelit hõlmavate andmete pärimine võib olla vähem tõhus kui ühe tabeli pärimine.
• Potentsiaalne andmete liiasus: Kui te ei ole hoolikas, võite lõpuks salvestada samu andmeid mitmesse tabelisse.

Proksi mudelid

Kuigi proksi mudelid ei ole rangelt võttes samasugune mudelite päriluse tüüp nagu abstraktsed baasklassid ja mitme tabeli pärilus, on neid selles kontekstis siiski väärt mainimist. Proksi mudel võimaldab teil muuta mudeli käitumist ilma selle andmebaasi tabelit muutmata. Proksi mudeli määratlete, seades mudeli Meta klassis proxy = True.

Millal kasutada proksi mudeleid

Proksi mudelid on kasulikud, kui soovite:

• Lisada mudelile kohandatud meetodeid: Muutmata mudeli välju või seoseid.
• Muuta mudeli vaikimisi järjestust: Konkreetsete vaadete või kontekstide jaoks.
• Hallata mudelit teise Django rakendusega: Hoides aluseks olevat andmebaasi tabelit algses rakenduses.

Proksi mudeli näide

            
from django.db import models

class Article(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    published = models.BooleanField(default=False)

    def __str__(self):
        return self.title

class PublishedArticle(Article):
    class Meta:
        proxy = True
        ordering = ['-title']

    def get_absolute_url(self):
        return f'/articles/{self.pk}/'

            

              
                Copy
              
            
          

Selles näites on PublishedArticle Article mudeli proksi mudel. See kasutab sama andmebaasi tabelit nagu Article, kuid sellel on erinev vaikimisi järjestus (ordering = ['-title']) ja see lisab kohandatud meetodi (get_absolute_url). Uut tabelit ei looda.

Õige pärilustüübi valimine

Järgnev tabel võtab kokku peamised erinevused abstraktsete baasklasside ja mitme tabeli päriluse vahel:

Siin on otsustusjuhend, mis aitab teil valida õiget tüüpi pärilust:

• Kas peate pärima baasklassi otse? Kui jah, kasutage mitme tabeli pärilust. Kui ei, kaaluge abstraktseid baasklasse.
• Kas loote spetsialiseeritud mudeleid selge "on-tüüpi" seosega? Kui jah, kasutage mitme tabeli pärilust.
• Kas teil on peamiselt vaja jagada ühiseid välju ja meetodeid? Kui jah, kasutage abstraktseid baasklasse.
• Kas olete mures andmebaasi keerukuse ja jõudluse lisakulu pärast? Kui jah, eelistage abstraktseid baasklasse.

Mudelite päriluse parimad praktikad

Siin on mõned parimad praktikad, mida järgida Django mudelite päriluse kasutamisel:

• Hoidke pärilushierarhiad madalad: Sügavad pärilushierarhiad võivad muutuda raskesti mõistetavaks ja hooldatavaks. Piirake tasemete arvu oma pärilushierarhias.
• Kasutage tähendusrikkaid nimesid: Valige oma mudelitele ja väljadele kirjeldavad nimed, et parandada koodi loetavust.
• Dokumenteerige oma mudelid: Lisage oma mudelitele docstringid, et selgitada nende eesmärki ja käitumist.
• Testige oma mudeleid põhjalikult: Kirjutage ühiktestid, et tagada oma mudelite ootuspärane käitumine.
• Kaaluge mixinide kasutamist: Mixinid on klassid, mis pakuvad taaskasutatavat funktsionaalsust, mida saab lisada mitmele mudelile. Mõnel juhul võivad need olla heaks alternatiiviks pärilusele. Mixin on klass, mis pakub teistele klassidele pärimiseks mõeldud funktsionaalsust. See ei ole baasklass, vaid moodul, mis pakub spetsiifilist käitumist. Näiteks võiksite luua `LoggableMixin`-i, et automaatselt logida mudeli muudatusi.
• Olge teadlik andmebaasi jõudlusest: Kasutage tööriistu nagu Django Debug Toolbar, et analüüsida päringute jõudlust ja tuvastada potentsiaalseid kitsaskohti.
• Kaaluge andmebaasi normaliseerimist: Vältige samade andmete salvestamist mitmes kohas. Andmebaasi normaliseerimine on tehnika, mida kasutatakse liiasuse vähendamiseks ja andmete terviklikkuse parandamiseks, organiseerides andmed tabelitesse nii, et andmebaasi terviklikkuse piirangud jõustaksid sõltuvusi õigesti.

Praktilised näited üle maailma

Siin on mõned globaalsed näited, mis illustreerivad mudelite päriluse kasutamist erinevates rakendustes:

• E-kaubanduse platvorm (globaalne):
  • Mitme tabeli pärilust saab kasutada erinevat tüüpi toodete modelleerimiseks (nt PhysicalProduct, DigitalProduct, Service). Igal tootetüübil võivad olla oma spetsiifilised atribuudid, pärides samal ajal ühiseid atribuute nagu nimi, kirjeldus ja hind baasmudelist Product. See on eriti kasulik rahvusvahelises e-kaubanduses, kus regulatsioonidest või logistikast tulenevad tootevariatsioonid nõuavad eristuvaid mudeleid.
  • Abstraktseid baasklasse saab kasutada ühiste väljade lisamiseks, nagu 'shipping_weight' ja 'dimensions' kõigile füüsilistele toodetele, või 'download_link' ja 'file_size' kõigile digitaalsetele toodetele.
• Kinnisvarahaldussüsteem (rahvusvaheline):
  • Mitme tabeli pärilus saab modelleerida erinevat tüüpi kinnisvara (nt ResidentialProperty, CommercialProperty, Land). Igal tüübil võivad olla unikaalsed väljad, nagu 'number_of_bedrooms' elamukinnisvara jaoks või 'floor_area_ratio' ärikinnisvara jaoks, pärides samal ajal ühiseid välju nagu 'address' ja 'price' baasmudelist Property.
  • Abstraktseid baasklasse saab kasutada ühiste väljade lisamiseks, nagu 'listing_date' ja 'available_date', et jälgida kinnisvara saadavust.
• Haridusplatvorm (globaalne):
  • Mitme tabeli pärilus võib esindada erinevat tüüpi kursuseid (nt OnlineCourse, InPersonCourse, Workshop). Veebikursustel võivad olla atribuudid nagu 'video_url' ja 'duration', samas kui kohapealsetel kursustel võivad olla atribuudid nagu 'location' ja 'schedule', pärides ühiseid atribuute nagu 'title' ja 'description' baasmudelist Course. See on kasulik erinevates haridussüsteemides üle maailma, mis pakuvad erinevaid edastusmeetodeid.
  • Abstraktseid baasklasse saab kasutada ühiste väljade lisamiseks, nagu 'difficulty_level' ja 'language', et tagada järjepidevus kõigi kursuste vahel.

Kokkuvõte

Django mudelite pärilus on võimas tööriist hästi struktureeritud ja hooldatavate andmebaasiskeemide loomiseks. Mõistes erinevusi abstraktsete baasklasside ja mitme tabeli päriluse vahel, saate valida oma konkreetse kasutusjuhtumi jaoks õige lähenemise. Otsuse tegemisel pidage meeles kompromisse koodi taaskasutatavuse, andmebaasi keerukuse ja jõudluse lisakulu vahel. Selles artiklis esitatud parimate tavade järgimine aitab teil luua tõhusaid ja skaleeritavaid Django rakendusi.