Hopefully they'll one day allow WHENCE as an alias of FROM

Maybe this makes me old, but I much prefer a written document explaining how an API works over Swagger.

{
  "act1": {
    "position": "reverse cowgirl"
    "etc...": {}
  }
}

Not sure what you expected

Edit: also found this https://json-porn.com/

What do you mean by “no structure”? Afaik mongodb does not enforce a schema in a collection by default

At a certain level all data is a pair (some name, blob of bytes). You can concatenate sequences of those pairs into a tar archive and call that a database. To access "the last object" you'd have to seek over the "first" objects. So you can build another set of (some name, blob of bytes) that serves as an index into the first set. You'll first have to do at least one full pass over that first set, and you'll need to make space on the books to account for twice as many sets, AND you'll still have to do some seeking over the "first objects" in the indexing collection, but it all keeps recall times very short!

The fun comes when there is no actual data model. All in all, I'd say being familiar with the data model is about 60% of my job. 35% is building queries and query scripts for people who need regular exports. 5% is running after other people's fuckups.

Strap in, because this is a ride.

There is a raw database from a decade-and-a-half old app, which I get to access through a layer of views that does some joining, but not all, with absolutely no documentation on how the original database is structured or where things are pulled from or what anything refers to. No data dictionary, no list or map of key relations, some objects are mapped in two different views, no semantic naming of columns.

If you want to want to query order part delegations by who they're assigned to (Recipient in the app) you need to use the foreign key RefAssignmentUnit. The "Assignment" unit that did the delegation is just RefUnit. If you have orders that were created by a salesperson on behalf of a customer, OrderingPerson (also a foreign key, but not named Ref-) is the customer, while OrderingPerson2 is the salesperson that entered the order. Don't confuse that with Creator, which for orders created through the web form is usually a technical user, unless the salesperson is one of the veterans that use the direct app in which case it'll be the salesperson while OrderingPerson2 is null.

Also, we have many-to-many relationships that are mapped through reference tables... whose columns are named object and reference for each and every one. Have fun trying to memorize which refers to which so you don't need to look it up every damn time.

Create my own views to clean this up? Nope, only the third party service providers for the app can do that, and they don't wanna. Our internal app admin (singular) can use some awkward tool to generate those views, but there's no reverse lookup to see what a given column refers to. Also, they have no concept for what actually constitutes a good model because they're not really familiar with the database, just with the app.

Get my own serverless DB to create views that query the original DB? No can do, you'd need to order a whole server and that's pricy.
Get a cloud DB? Sure, but it will be managed by the cloud team and if you want to have or edit custom views, you'll get to create a project request. They'll put it in the backlog and work it into some future sprint.

Get literally any tool that allows me to efficiently create reusable data prep so I don't have to copy & paste the base transformations needed for a given query every fucking time and if the source DB ever changes I need to update all my query scripts? If you can somehow squeeze the time to prepare a convincing pitch - a full Power Point presentation, of course - between all your tedious and redundant query preparation and script maintenance, find a management sponsor willing to hear you out and hopefully propose your request to their superiors. Best case: It becomes a whole project - alternatives will have to be considered first, implications, security, costs, and you'll be the one having to assemble and present that information to management only to have some responsible person point out that it would actually be the remit of a different team... that also works in sprints, has a backlog and will give you no control over your prep.

And obviously, the app provider doesn't give us any advance notice of just what will change in the DB with the next update. We only learn that when a view breaks. The app admin can use the tool to refresh the affected views then, while I scramble to determine all the scripts that need to be updated and copy&paste the fix. If a user has been granted their own access to the database, odds are they'll come crying to me when their modified versions of my queries break.

There is a lot I like about my job, I acknowledge the difficulties of a historically grown system and service contracts, but the rigid and antiquated corporate culture can go take a long walk off a short pier.