I could write pages on the "company's problems" but I don't feel like it. The "reporting" database was my idea and my attempt to actually be able to do sometime

I could write pages on the "company's problems" but I don't feel like it. The "reporting" database was my idea and my attempt to actually be able to do sometime "cool" there. The java software devs, even though they all had 15+ years experience, really had no clue what a database was other than a thing to put data in. App environment configs, customer configs, binary images,... you name it and it was stuck in the main database. The schema was designed by a sysadmin that left shortly after the company (a start up) actually started getting real customers. Messing with the schema was basically off limits. No one saw an issue with it. Everyone thought the schema was brilliant because that sysadmin thought it would be a cool idea to replace indexes with partitions (DB2 9.7 at the time had a brand new "partition by range" feature). He wrote giant bash scripts to partition many tables by timestamps on either a 15 minute, one hour, or one day interval AND by groups of account IDs (or any other ID that might be in the row). His logic was that even though all queries will do a full table scan.. but hey these are all really tiny tables now! Management and the senior devs thought it was a brilliant idea. It didn't work so well in the end, and ultimately indexes were just added randomly all over the place. But the partitions remained and the scripts would run every hour... but sometimes they'd fail to add partitions because of locks. Which ultimately left no where for certain data to go (based on timestamps) and the app would go down. This went on for years... But the other issue, as time rolled on, when the schema did need to be changed, it was done the quickest and dirtiest way possible. One patch I saw go through added a "username" column to several tables to track what user made a change to a row, but it was varchar instead of a FK... completely de-normalizing the schema. No one knew or understood the data on the dev team. I tried best as I could to do analytics, but the DB2 DBA's were always on my case for "accessing" "their" database. I managed to get buy in from my manager to start standing up postgres databases for reporting. We tried Mysql at first but its supported SQL syntax was too butchered for anything other than simple queries. The idea was to have a carbon copy of the OLTP schema in postgres and populate it with Pentaho or some other BI tools/scripts. Once that was mostly working we were going to build a data warehouse schema with stuff in the proper formats so we could just query without having to transform. Sadly after a few months my manager moved me off of the project and put a rather new contractor over the project who knew nothing about data architecture, or linux (he constantly complained about the command line and would say things like "I stopped using DOS years ago"), or even postgres. I was moved to simply help with some vmware upgrades which was boring. They then opened a "jr DBA" position and filled that with someone straight out of college to handle standing up the postgres instances. And with that, I left.... and eventually most of the rest of the team too. PS, they are looking for a BI guy...