I'm relatively fresh out of college so most of my familiarity with relational databases is from my databases course where anything not in BCNF or 3NF is a travesty. Certainly that's one end of the extreme, but my team at work really seems to take it to the complete opposite end.
In our microservice db schemas, entities rarely have more than a single table. Anything that you would commonly normalize into another table is stored in a json column. If it's later discovered that one of the properties in this json needs to be queried on, a new column is added and the data is stored in both places (yes, in two different columns in the same table).
In a lot of cases these json columns definitely have an advantage. If you never need to query on that data and if you never have to make a unilateral change to that data (which is something you obviously can't predict), it's not a bad idea. Plus many of our services either don't see server or are hosted on machines with an obscene amount of disk space for what they needed, so data duplication isn't a huge issue. (Though something I'd generally like to avoid out of philosophy)
Currently we're building a service that matches rules based on a set of conditions they own and then performs a set of action associated with those rules when the rules are true (e.g. all of the conditions are true). My sub team that's most immediately building this service believes that there's a substantial benefit to normalizing actions and conditions away from rules in the schema. Obviously these table maintain foreign key relationships with the the rule id. From our perspective we can avoid data duplication on conditions enabling us to ensure that they are only evaluated once once and it's easy to find the conditions and rules we need when need them without needing to pull every single rule out and do the searching in memory.
Speaking with one of our principal engineers today he attempted to push me far away from this schema. Trying to argue in every way that we do don't actually need it it's going to cause performance issues in the future, referencing an old monolith we own that is a design travesty. He referred to what we're doing as "the old way" and flat tables with json as "the new way". He argued that in places where I want atomicity we don't need it and that instead of queries we should do more things in memory. This is a design principle that many of our services follow now. We don't anticipate that the volume of our data will grow substantially which should keep our queries quick. What we do anticipate is a lot of time spent in rule evaluation and performing actions. It seems logical to move as much burden as possible to SQL.
I understand non relational databases have become more popular in recent years but even when actively searching for information about the performance implications of foreign key relationships I don't see a lot of information making his case. I suppose they might tend to introduce large transactions which may cause issues, but that seems like a problem independent of the foreign key itself.
Is this my naivety? Or is this there truly something I and my sub-team are missing? I've explicitly not given detailed information on our problem because I'm not necessarily looking for a solution to that. Given that is a common trend in our larger team, I'm really curious if they're on to something with this.