EXCEL · ORACLE · DATA INTERFACES
Excel is often criticised when it sits close to a database, but the problem is rarely Excel itself. The real question is whether the workbook is acting as an interface over governed data or quietly becoming a second data system.
When Excel is a good interface
There are many situations where the database should remain the source of truth while Excel provides the operational surface. Users may need filters, a compact form, an export, a comparison between records, or a controlled way to launch a query without writing SQL.
In this role Excel is not replacing Oracle. It is reducing the distance between the database and the person who needs to inspect or operate on a small part of it.
The boundary matters
The design starts to become fragile when the workbook stores copies of data that are treated as authoritative, embeds business rules in many formulas and macros, or requires users to synchronise changes manually. At that point the interface is no longer thin: it has become a parallel application with weak governance.
I prefer a clear boundary. Oracle owns persistent data and relational logic. SQL retrieves the dataset that is needed. Power Query can shape it. VBA can coordinate interaction. Excel presents the result and collects only the parameters that belong to the user’s task.
What I try to keep out of the workbook
- Large duplicated datasets maintained by hand.
- Credentials embedded in formulas or VBA.
- Critical business rules repeated in several workbooks.
- Write operations that bypass validation or audit.
- Logic that cannot be explained without opening the VBA editor.
A useful pattern
A small workbook can work well when the flow is explicit: configuration → parameters → query → transformation → control → output. Each layer has one responsibility and can be changed independently. The workbook remains understandable because the difficult parts are not scattered across cells.
This is especially useful for diagnostic tools and operational controls. The interface can be close to the user while the data remains where it belongs.
When I would stop using Excel
I would move away from Excel when many concurrent users need to update the same data, when permissions become complex, when the workflow requires server-side execution, or when the workbook itself has become a deployment problem. Those are signs that the interface is carrying more responsibility than it should.
Excel is a good front-end when it makes the database easier to use without pretending to be the database.