Labs piemērs šai pieejai ir Python valodas produkts Django.

Framework ļauj definēt būtiskās relācijas starp datiem un nodrošina to mappingu uz atbilstošo DBVS, ievērojot platformas īpatnības (Oracle, Mysql, Postgres, etc).

Nav nekas jauns, bet pirms gadiem desmit, kad pats intensīvāk darbojos ar datubāzēm un pirmoreiz ar šādām lietām saskāros, šķiet, lietojot Java, es par šādiem mēģinājumiem raustīju plecus, jo tas bija sarežģīti un tāpat ļoti ātri vajadzēja sākt lietot SQL.

Nezinu, kā ar citām programmēšanas sistēmām, bet iekš Django tagad man SQL tieša lietošana, radot jaunu aplikāciju, vairs nav nepieciešama. Vismaz ikdienišķi JOINi un datu manipulācijas strādā kā pulkstenis ar framwork līdzekļiem.

Pozitīvais ir tas, ka ir viena vieta, kur glabājas mans datu modelis, un man nav jāuztur, atsevišķi jāinstalē un jāatkļūdo dažādu valodu (Python un SQL) kods.

Protams, vienmēr būs aplikācijas, kuru prasības būs pietiekami sarežģītas, lai gribētos lietot “native” SQL (ko Django, protams, arī ļauj).

Taču paredzu, ka ikdienā pamazām SQL datubāžu pieprasījumu veidošana un piemērošana vairāk nobīdīsies uz legacy sistēmām un sistēmām ar speciālām prasībām, un darbs ar DBVS vairāk būs saistīts ar servera “tjūnēšanu”.

patiesībā, ja tā padomā, lielākā daļa darbavietu, kurās es esmu strādājis, varētu ietaupīt tiešām lielas summas, ja tā vietā, lai gadiem maksātu pilnas programmētāju algas par to, ka diendienā tiek manuāli ģenerētas variācijas vienam un tam pašam CRUD kodam, vienreiz to ģenerāciju automatizētu. manuālais faktors tajos gadījumos ir arī nozīmējis, ka regulāri ir tikušas ieviestas, teiksim, SQLi ievainojamības, jo izstrādātājam ir jāatceras filtrēt ievadi, bet ar prepared statements tas notiktu automātiski. tas arī ir nozīmējis, ka produkta kvalitāte ir kopumā bijusi sliktāka, jo ir bijis sarežģītāk vairākkārt izmantot kodu, it īpaši starp dažādiem projektiem. es to domāju tā, ka ar ORM vajag mazāk disciplīnas, lai veidotu modulāru kodu, kā bez