Кажется, это в контексте какого-то ORM, так что я буду работать с этим. (Даже если это не так, продолжайте читать.)
Объекты полезны для моделирования сложных операций. Например, добавление нового Contract приводит к тому, что с Team, Player s и различными PayCheck s происходят всевозможные сумасшедшие вещи (я сделал последнее, но вы поняли) , Это идеальная вещь для обработки в коде, чем, скажем, в ужасно сложной хранимой процедуре T-SQL.
Но когда дело доходит до запросов , я нахожу, что часто имеет смысл написать представление / предложение / проекцию SQL, которые бесстыдно приспособлены к набору необходимой вам информации. выполнять функцию. Пока вы делаете это для чтения данных, а не для их записи, вы на самом деле не подрываете свою объектную модель; вы просто смотрите по-другому, и вы просто делаете прагматическое замечание, что большую часть времени вам нужна только информация из IPlayerCurrentContractQuery, а не весь список Contract в пределах Player. Так как этот метод называется bajillion раза, вы написали интеграционный тест, чтобы убедиться, что SQL дает правильные результаты, и вы внимательно посмотрели на его план запроса, чтобы убедиться, что он не делает такие ужасные вещи, как таблица сканирует в базу данных. Этот обычно используемый экран в вашем приложении быстрый, и все довольны.
Можно утверждать, что создание такого отдельного запроса является преждевременной оптимизацией, но, вероятно, это не так. Я имею в виду, что если у игрока обычно всего несколько Contract с, то, возможно, не стоит разделять запрос и интерфейс. Высасывание всех Contract из базы данных для их циклического прохождения и извлечения текущего будет хуже, чем выбор правильного в базе данных первым, но если это всего лишь несколько Contract с, то подход «да, я полностью осознаю, что это глупо, но достаточно быстро», вероятно, достаточно хорош, просто двигайтесь дальше. Но если эти Contract растянуты на годы или являются большими объектами, то выделение запроса становится легким делом.
Если , что начинает работать плохо из-за объединений (что маловероятно, если вы не начнете видеть значительный трафик), тогда вы добавляете кеш. И если , что не работает из-за большого количества записей, вы можете начать денормализацию базы данных, добавив прямую ссылку. Но если вы не пишете следующий бейсбольный Facebook, то YAGNI, и в этот момент вы разделяете серверы и в любом случае отбрасываете большинство преимуществ реляционной модели, так что кого это волнует.
Подобная ситуация возникает в моем ответе на этот вопрос .
(Если этот вопрос не касается ORM и на самом деле касается моделирования того, как создаются таблицы, то вы должны убедиться, что у вас есть индекс, охватывающий запрос, который выбирает текущий контракт - например, start и stop даты - и вы в значительной степени сделали это, если у вас действительно исключительные требования к масштабированию, как упомянуто выше. Если вы пишете определенный набор объединений очень часто, то вы можете написать функцию или хранимую процедуру для удаления шаблон.)
Это мой мозг. Надеюсь, это поможет!