Hi everyone, In a project involving Firebase and object types like Tickets, Schedules, and Timers, I want to structure my classes such that switching databases (potentially to MySQL) wouldn’t require a complete rewrite. Approach 1: * A DatabaseProxy interface with generic methods (e.g., createTicket, createTimer, etc.) * A FirebaseProxy class implementing the interface, with methods for each object type (e.g., createTicket, createTimer, etc.) * Manager classes for Tickets, Schedules, and Timers, that primarily use the FirebaseProxy for operations. This provides flexibility for processing input/output, but most of the time the manager classes will just be calling methods on the Proxy directly. Approach 2: * A DatabaseProxy interface with the most basic CRUD methods (create, read, update, delete). * A FirebaseProxy class implementing the interface. * Manager classes for Tickets, Schedules, and Timers, calling FirebaseProxy with parameters like update(collection, ticket) and implementing createTimer, createTicket, etc. I like the second approach in theory, but what I’m worried about is whether the separation is too low level. What happens if the database I switch to changes schema such that taking in an object and a collection name isn’t good enough anymore? For example, will there be concerns if I switch between Vector, NoSQL, and SQL? Any opinions are appreciated!