Я бы сказал, что необходимость использовать много объединений (например, иметь дело с нормализованными данными) - это не запах кода, а скорее указание на то, что вы, возможно, не работаете в нужном месте. По моему опыту, те, кто обеспокоен количеством соединений в запросах, слишком много разрабатывают в базе данных и недостаточно в приложениях и отчетах, которые предоставляют данные. Структуры данных должны быть достаточно гибкими, чтобы поддерживать множество применений, и поэтому нормализация в той или иной степени важна.
Создавая современные корпоративные приложения, разработчики могут использовать вчерашние достижения для работы на абстрактных уровнях, значительно превосходящих технологии, такие как SQL и даже XML, для обеспечения большей отдачи при меньших затратах труда. Существуют инструменты, т. Е. Составители отчетов, генераторы кода, ORM, структуры сущностей и т. Д., Которые абстрагируют низкоуровневую работу по созданию SQL вручную и будут выполнять объединения для вас. Большинство знает об используемом диалекте SQL (например, Oracle 9 против MySQL 3) и может генерировать синтаксис SQL, наиболее эффективный для этого диалекта; Это означает, что они могут создавать соединения лучше, чем вы.
Однако эти инструменты работают очень слабо или совсем не работают в реляционной среде без достаточной нормализации. Для меня это - то, где запах "развития" проявляет себя; если установленный инструмент доступа к данным не может понять отношения, в соответствии с которыми я структурировал свои данные, мне, вероятно, нужно искать более нормализованный способ создания этих отношений, и в этом получаются преимущества, намного превосходящие только использование инструмента. Как правило, где-то между 2-м и 3-м нормальная форма является сладким пятном; хотя всегда есть небольшие области реляционных данных, где более высокая степень нормализации имеет смысл и добавляет ценность.
Ура,
Travis