An ancient dream
Presently, the majority of developer time is spent on reinventing the wheel laboring on
- modeling business logic,
- creating database schemas for those models and
- developing user interfaces that bind against that storage.
Any progress to make this easier or parts of it redundant has economic potential in the ballpark of the combined cost of those developer hours.
The ultimate technological dream would be a tool that allows to do these steps in an entirely non-programmatic, potentially graphic way: the “spreadsheet” of databases.
Indeed, this was originally the vision for those now ancient relational databases when they first emerged: dBase, FoxPro and MS Access came with tools for both sides of the application coin: data storage and UI development.
And yet, today, almost all database products merely store, and virtually all UI technology is storage agnostic. Somewhere along the way, the dream died.
I want to revive this dream.
The first step
There is a more modest first step along the way to that grand vision that is already economically potent: A generic UI for existing relational databases.
Relational databases have enough metadata (the relations between tables) to allow inference of a user interface. The demo shows an inferred UI for some example databases.
The current state of SQuiL is barely an MVP and many things are missing, such as editing features.
However, I believe the tool will soon be economically viable, even without the wider vision it’s aiming at. If you doubt that, consider two points:
First: Middle-sized, relational databases are not cool, and they are not what Google technologists usually want to write papers about. They are, however, the most ubiquitous piece of technology in companies around the world after Word and Excel. Their user interfaces are custom-made for all the line-of-business applications and in-house solutions, often hastily hacked together, both buggy and ugly, by the necessity of daily demands.
Besides the custom application, the only alternative software capable of even just listing the names of tables in a database are the classic database clients, which are all very similar but really little more than SQL command line interfaces. Their most advanced features deal with the import of CSV files or the copying of entire databases. All of them are unable to even retrieve a single row together with all related data without someone having to write a custom query in textual SQL.
In contrast, look at the SQuiL, even in its current, fledgling state. Ask around if tools like that exist. They could have existed for decades. But mysteriously, they don’t.
It’s about time to change that.
What I’m looking for
I know I have a lot to offer but need the right partners to shine.
I will go on developing this project on my own, eventually getting users and then customers, but even though I can make the first steps myself, the larger vision requires a team and therefore a business.
Ideally, however, I just want to create the product - but then I also know that only a business can give me the team to make this happen quickly.
Contact me if you are interested to talk.
Jens