DView: When Putting a Database in a Browser Felt New

Down memory lane.

Near the end of the year, I was going through an old Dropbox folder and suddenly came across something I had not seen in years — screenshots, notes and presentations for DView, a little database browser I had built early in my career.

Looking at those screens now is mildly amusing. Lots of blue hyperlinks. Very basic HTML. Backgrounds that clearly belong to another era. And yet I found myself thinking: this actually was not too bad for what the web looked like then.

So I thought — why not capture the story?

At the time I was working across several applications and, among other things, doing database design and DBA work. That meant the usual questions kept coming my way: What is locked? Which session is doing this? What indexes does this table have? Who can access this object?

You could answer all of that with SQL or desktop database tools. But developers either needed those tools installed or needed to know which queries to run.

At the same time, I was getting interested in web applications. Oracle had a way for browser requests to invoke PL/SQL procedures and generate HTML. That combination was too tempting: why not browse a database the way you browse a website?

DView became a browser interface over Oracle database and system information — tables, columns, indexes, views, procedures, users, privileges, sessions, locks, storage information and more, connected through hyperlinks rather than repeated SQL.

There was another benefit I had not expected. As a DBA, I already knew many of these internals. But building a structured interface over them forced me to understand them differently — digging through the data dictionary, working out how the pieces related, deciding what belonged together, and making it navigable for somebody else.

Building the browser became a pretty good way of learning the database more deeply.

A tiny technology snapshot

The working Oracle version was deliberately simple. The broader product idea later explored a more portable multi-database architecture.

Piece	What I used / explored
Database	Oracle
Application logic	PL/SQL
Web layer	Oracle Application Server / PL/SQL HTML tooling
Interface	HTML + hyperlinks in a browser
Database internals	Oracle data dictionary and system views
Broader product direction	JDBC + Servlets for multi-vendor database access

For teams, the browser model also meant no dedicated database client on every desktop and no persistent client/server connection for each user.

Around the same time, there was an internal initiative encouraging people in a services environment to think about products. Ideas could be submitted, evaluated, and a few selected ones would move toward something closer to a real product journey.

Fortunately, I was not submitting only a presentation. I already had DView working, so I entered it. It was selected among the top three ideas.

What stayed with me more than the ranking was having to look at something I had built for myself and ask a different set of questions: Who else needs this? What is the alternative? Why would they use it? How do I explain the value? Could this little utility become a product?

That was probably one of my earliest brushes with product thinking.

Straight from the archive. A few of the original DView ideas and screens — lightly sanitized where necessary, but deliberately left looking like the web of its time.

DView belongs to another technology era. But looking back, I recognise a combination that kept showing up in things I built later: start with a problem I understand, use it to learn something new, make the complexity easier for somebody else to navigate — and then ask whether the little solution could become something more. Maybe that is why finding it in Dropbox all these years later was such fun.