Skip to main content

Architecture and design

4 articles

Explore unified data access and database adaptation.

Back
  • Unifying the Database Dialect Layer

    As dbVisitor expanded from RDBMS to NoSQL, the dialect system's abstractions became fragmented. This post explains a deep architectural refactoring that unifies dialect metadata and command building into a cohesive design — no functional changes, pure structural improvement.

  • Inside dbVisitor's Two-Layer Adapter

    dbVisitor's "Two-Layer Adapter" unifies RDBMS and NoSQL access through two abstractions: Layer 1 — a unified API (LambdaTemplate / Mapper) hiding syntax differences; Layer 2 — JDBC-compliant drivers wrapping NoSQL protocols. Use the full stack, or integrate the driver with an existing MyBatis project after checking its required JDBC capabilities.

  • Unified Data Access: Layers and Database Limits

    After dbVisitor can a single API truly unify RDBMS and NoSQL? This post tackles the controversy and explains the design principles behind dbVisitor's "One API, Access Multiple Databases" vision.

  • dbVisitor: Many Databases, One API

    Data storage has diversified beyond RDBMS to NoSQL, NewSQL, and AI Vector. dbVisitor aims to define the next-generation standard: One API, Access Multiple Databases.