A UX is A Database, A Database is A UX
I am convinced that Computers do not need databases. As for ‘networks’, like the Internet, all they need are ‘anchor points’ (aka the URI), the ‘database’ (as traditionally understood) is not required.
Filesystems
A filesystem is, in many ways, the proto-database. It arrived before we even thought of creating more complex applications like Word processors.
When one thinks this through very carefully, it is quite evident that one of the key reasons why a GUI was invented was to get around the primitiveness of relying on complex and cumbersome (not to mention error prone!) command-line-interface queries of locating and managing files.
Relational Data
Without a GUI or before a GUI was taken seriously by many ‘hardcore’ software engineers, it was thought that filesystems are not ‘efficient’ and ‘reliable’ enough to be the most trusted data vault. Companies like IBM, Oracle and SAP even went as far as to argue that while one may indeed ‘pull and process data’ on a normal personal computer, one cannot trust these same devices to store large amounts of ‘critical’ data.
It was a lie; mainly predicated on the sense of failure and regret that accompanied these companies’ lack of involvement in the PC space. Storing data on ‘several’ devices (especially over a network) is actually much more reliable than storing it in a centralised piece of hardware. Locating/managing that data is even easier that way as it gives the users the same sense of control and access that they already have on their personal computers. This is why technologies like NFS were invented. But they mostly seem to have been ‘taken over’ either by telecommunications companies or by database companies. NFS-like technologies, at the end of the day, also had a ‘UX’ problem.
But it was a convincing lie. Most personal computers, way until the mid to late nineties, were still primitive in terms of UX. So a ‘database’ was still the most assured way of managing data records.
It’s 2018!!!
It has been more than 20 years since the GUI found its way into the mainstream of personal computing. Databases are still around and they abound.
Unlike the filesystem technologies, they seem to come in completely different forms, formats, API’s, query languages and use-cases. To ‘use’ a new database is to learn a new language!
Clearly, this is extremely distracting. We’re distracted from the real problem: We Want to (reliably) Store and Retrieve Our Data! ‘Installing’ a new database, from NOne-SQL to No-SQL via GraphDB/GraphQL and back to SQL again is not solving the problem.
Why They All Suck!
As software developers, we will keep going round and round in circles, moving from one ‘new’ QL to another, from BigTable, to Graph, from Graph to Spark, and from Spark back to Maria.
All databases, from properietary (e.g. Oracle and SAP) all the way to open source (e.g. MongoDB or Postgresql) fundamentally suck.
There’s no hiding around this. If just ONE of them was ‘that good’ we would just stop everything (and/or pay everything) to use that one ‘good’ one. Once again, there is ABSOLUTELY no excuse. If a ‘thing’ is meant to store data then that’s what it should do! No further hacking, experimentation or new installations required!
All current databases suck because they CANNOT actually perform their primary task: which is to store and retrieve data!
But why have we FAILED to solve this? Well, it is because we literally ‘invented’ a complex paradigm (i.e. you need a database!) to solve a rather simple problem (i.e. you need to reliably store/retrieve data!).
In other words, once we REMOVE the database from the equation, then BOTH the question and the answer are simplified.
All You Need is A UX…
If all we need to do is to store/retrieve data, then it follows that all one needs is simply a human-friendly interface for storing and retrieving data.
The ‘back-end’ / or a database is simply a construct that we software engineers invented in an attempt to ‘explain’ how the storage/retrieval is achieved. Once again, that is a total distraction! People/companies need to store/retrieve data using a good interface! That’s it! If there’s ever an occasion to ‘explain’, that is a sure sign that the UX is not working! (One just uses / drives a car; without needing to be told that an ‘engine’ is required for it to move. Which is actually not always true; one could use an electric motor. Same applies to ‘databases’; sometimes all one needs is a good data ‘URI-like’ system — over the wire or residing locally. e.g. the Internet!).
This ‘construct’ or any other, is only as useful as its effect: solving the user problem. So far, it has not proven to be useful, at all!
The other way to get around the likely obstacle of ‘over-simplication’ is to consider that most UI or UX designs do not have a good ‘data’ management paradigm. They over-rely on ‘objects’ as a paradigm to contain and manage user views and inputs; which is precisely the paradigm that our data persistence / database-model layer rejects. If UX engineers would change this, then the database / back-end would become less necessary.
There it is, you do NOT need a database if you have a good UX design, and you do not need a UX if you have a good data retrieval/storage system.
