Vastus: See pole keelatud, eeldusel, et loodud rakendus kasutab andmebaasi läbi avaliku andmebaasi liidese e virtuaalse andmete kihi. Teiste sõnadega peaks rakendus lugema andmeid vaadetest (näiteks Djangos on see võimalik) ning muutma andmeid kasutades andmebaasiserveris talletatud rutiine (näiteks Djangos on see võimalik). Andmete kitsendustele vastavuse kontroll peab toimuma andmebaasi tasemel (kasutades deklaratiivseid kitsendusi ja reegleid), mitte rakenduse tasemel nagu ORM vahendid üldiselt propageerivad. Rakenduse tasemele andmete kontrolli probleemiks on:

• üleliigsed päringud andmebaasi põhjal, mis kokkuvõttes aeglustavad ORM abil loodud programmi tööd,
• kontrollide ebapiisavus selles mõttes, et juhul kui samu andmeid kasutab samaaegselt mitu kasutajat, siis võivad need kontrollid lasta läbi reeglitele mittevastavaid andmeid.

ORM vahendi(te) probleemidele osutab see uuring 67 avatud lähtekoodiga tarkvara põhjal.

Siin on veel üks suure hulga põhjendustega selgitus, miks üks arendaja loobus ORMi kasutamisest ning eelistab ise SQL lauseid kirjutada.

Siin on arutelu, kus kõrvutatakse ORMi ja andmebaasiserveris talletatud rutiinidest, vaadetest ja hetktõmmistest koosneva virtuaalse andmete kihi kasutamist.

Kuigi eelnev näitab, et ORMi ja andmebaasi avalikku liidest saab koos kasutada, siis praktikas on need alternatiivid.

• Alternatiiv 1: Rakendus kasutab andmebaasi läbi ORMi. ORM vahend genereerib ise SQL koodi, millega loetakse ja muudetakse andmebaasis andmeid otse baastabelites. Selleks, et piirata kasutajate juurdepääsu teatud tingimustega tabeli ridadele, pakuvad andmebaasisüsteemid vahendeid nagu turvapoliitikad (PostgreSQL) või peeneteralised juurdepääsupiirangud.
• Alternatiiv 2: Rakendus kasutab andmebaasi läbi avaliku andmebaasi liidese, mille realiseerimiseks kasutatakse andmebaasis loodud vaateid, rutiine ja materialiseeritud vaateid e hetktõmmiseid. Rakendus ei pöördu otse baastabelite poole, vaid kasutab nendes olevaid andmeid läbi avaliku liidese.