Я относительно новичок в колледже, так что большая часть моего знакомства с реляционными базами данных происходит из моего курса по базам данных, где что-либо не в BCNF или 3NF - это пародия. Конечно, это один крайний край, но моя команда на работе действительно, кажется, доводит его до совершенно противоположного конца.
В наших схемах микросервисных БД сущности редко имеют более одной таблицы. Все, что вы обычно нормализуете в другую таблицу, хранится в столбце json. Если позже обнаружится, что необходимо запросить одно из свойств в этом json, добавляется новый столбец, и данные хранятся в обоих местах (да, в двух разных столбцах одной и той же таблицы).
Во многих случаях эти столбцы JSON определенно имеют преимущество. Если вам никогда не нужно запрашивать эти данные и если вам никогда не придется вносить односторонние изменения в эти данные (что вы, очевидно, не можете предсказать), это неплохая идея. Кроме того, многие из наших служб либо не видят сервер, либо размещаются на машинах с неприличным объемом дискового пространства, необходимого для них, поэтому дублирование данных не является большой проблемой. (Хотя кое-что я бы вообще хотел избежать из философии)
В настоящее время мы создаем сервис, который соответствует правилам на основе набора принадлежащих им условий, а затем выполняет набор действий, связанных с этими правилами, когда правила выполняются (например, все условия выполняются). Моя подгруппа, которая скорее всего создаст этот сервис, считает, что есть существенная выгода от нормализации действий и условий вне правил в схеме. Очевидно, что эти таблицы поддерживают отношения внешнего ключа с идентификатором правила. С нашей точки зрения, мы можем избежать дублирования данных в условиях, позволяющих нам гарантировать, что они оцениваются только один раз, и легко найти условия и правила, которые нам нужны, когда они нужны, без необходимости извлекать каждое отдельное правило и выполнять поиск в памяти.
Разговаривая сегодня с одним из наших главных инженеров, он попытался оттолкнуть меня от этой схемы. Попытка всячески спорить о том, что нам это на самом деле не нужно, в будущем вызовет проблемы с производительностью, ссылаясь на наш старый монолит, который является пародией на дизайн. Он назвал то, что мы делаем, «старым способом», а плоские таблицы с json - «новым способом». Он утверждал, что в местах, где мне нужна атомарность, она нам не нужна, и что вместо запросов мы должны делать больше вещей в памяти. Это принцип дизайна, которому следуют многие наши услуги. Мы не ожидаем, что объем наших данных существенно возрастет, что должно ускорить наши запросы. Мы ожидаем много времени, потраченного на оценку правил и выполнение действий.
Я понимаю, что нереляционные базы данных стали более популярными в последние годы, но даже при активном поиске информации о влиянии на производительность отношений с ключевыми ключами я не вижу много информации, подтверждающей его обоснованность. Я полагаю, что они могут вводить большие транзакции, которые могут вызывать проблемы, но это кажется проблемой, независимой от самого внешнего ключа.
Это моя наивность? Или это действительно то, чего мне и моей подгруппе не хватает? Я явно не дал подробную информацию о нашей проблеме, потому что я не обязательно ищу решение этой проблемы. Учитывая, что это общая тенденция в нашей большой команде, мне действительно любопытно, если они что-то с этим делают.