Mettendo la logica aziendale in un DBMS può permettersi alcune stratificazioni logiche, ma ha notevoli svantaggi pratici e strategici:
Lock-in. Il tuo codice sarà associato a quel database e alle sue risorse disponibili, probabilmente per sempre. Le migrazioni dei database si sono storicamente dimostrate estremamente difficili e sono quindi molto rare. Il lock-in del database è stato un problema aziendale estensivo e costoso. Più sei strettamente legato alle strutture DBMS, più difficile sarà separarsi da tali dipendenze.
Debole strumenti di sviluppo ed ecosistema. È possibile programmare stored procedure e altri comportamenti incorporati all'interno di PostgreSQL, Oracle DBMS, DB2, SQL Server, ecc. Ma questo stile di codifica manca del ricco ecosistema di IDE, debugger, framework di test, profiler di codice, repository di moduli, sistemi di compilazione, ecc. - strumenti di uso quotidiano in Java, Python, JavaScript e praticamente tutti gli altri linguaggi di programmazione. Codificare la maggior parte della logica all'interno di un DBMS non è la moderna norma di sviluppo, quindi sia il fornitore che l'investimento della comunità per esso sono radicalmente più deboli.
Questa debolezza è probabilmente permanente. Ho avuto discussioni significative con CTO presso IBM, Microsoft, Oracle e altri produttori di DBMS sulla logica residente in database. Alcuni, come Microsoft, sono relativamente positivi. La maggior parte, tuttavia, è sprezzante o ostile all'idea; mentre lo supportano in termini di drib e key come se fossero stored procedure, e mentre apprezzano gli sviluppatori che si bloccano nei loro prodotti quando possibile, in genere non vedono la logica del DBMS come uno stile di sviluppo praticato dalla maggior parte dei clienti, quindi non è un buon posto dove investire risorse significative.
Mancato supporto di -ities. uno dei principali motivatori per architetture a strati si sta separando preoccupazioni per supportare modularità, scalabilità, disponibilità, testabilità, flessibilità, sicurezza e altri "aspetti". I motori middleware come i server delle applicazioni progettati per architetture multilivello a più livelli hanno spesso capacità significative di isolare i componenti l'uno dall'altro (per sicurezza e disponibilità), per aumentare o ridurre (per la scalabilità), per riconoscere e adeguarsi dinamicamente alle risorse non riuscite (per la disponibilità), e altrimenti sfruttare la separazione delle preoccupazioni consentite dalla stratificazione. Mettere la logica all'interno di un DBMS sconfigge molte di queste opportunità. Anche quando i cluster DBMS sono supportati, le garanzie semantiche per le quali i database sono amati (ad esempio integrità referenziale, ACID ) sono indebolite. I loro sistemi di programmazione logica interna hanno buche simili nel supporto multi-istanza.
Mancata corrispondenza dell'impedenza. Con la logica aziendale nel DBMS, dovrai ancora affrontare il problema della "corrispondenza di impedenza" tra costrutti DBMS (ad esempio tabelle e relazioni) in costrutti di linguaggio di programmazione (ad esempio oggetti e raccolte). I livelli logici di business spesso rendono trasparenti i dati grezzi in oggetti rilevanti per il business (direttamente o con l'assistenza di un "oggetto business" correlato, " ORM ," o "dominio".) Eliminare la logica di business nel DBMS significa che non si dispone di un posto così conveniente per "shim" i risultati DBMS. Significa che il codice dell'applicazione che tocca i dati toccherà i costrutti di livello inferiore o richiederà comunque un livello di mappatura esterno al database. Non è una struttura impossibile, ma è ingombrante.