This sounds similar to what I saw at a client a few years back. All XML responses from a REST API were inserted into a single VARCHAR(MAX) column (one row per response, but a response could have multiple "records") in a SQL Server database.
All interaction with this was through a byzantine web of XPath expressions using the severely neutered dialect of XQuery that shipped with SQL Server 2008.
Apologies for the mini-rant, your comment appears to have triggered some painful memories.
You should see the one here. An old flat file database monstrosity from the 80s, imported into oracle, complete with all of the duplicated data. It's the most non relational, relational database ever.
Well, this is used now by about 4000 clients. So you be the judge. There is so many indexes, and spaghetti, just to make sure every possible "relationship" is accounted for. Amazing it works at all.
"Badly". At least once a week someone managed to overwrite a change another client had just made. When I left, they were running a cron to copy it every minute as a "quick restore" when it happened.
I have 177 tables, 764 stored procedures and 44 joins.
Every single table has either a uniqid() or a UUID() which isn't the primary key (they all have incrementing integer keys) but is 'joined' on in code.
When he needs to 'join' he used coalesce() on selects.
Referential integrity doesn't exist.
Oh and the cherry on the shit sandwhich, we have four seperate systems that talk to this database written in 3 different languages (Java (Android scanners), C# (Factory scanners) and PHP (the main system).
So there is no way to accurately know which SP's are used by what without grepping the entire codebase looking for call <foo>.
The PHP is written badly in the old PHP pure procedural style running on an outdated version of PHP/Debian/MySQL.
Basically if you took the absolute worst approach to everything this would be the end result.