Entity Framework Code First - почему при создании отношения one to many, в таблице создаются 2 колонки?

virtual нужен для того, чтобы EF не сразу загружал данные из связанных таблиц при получении объектов из базы, а только при обращении к соответствующим свойствам. По этой же причине класс сущности не должен быть sealed.

Как сформулировать перекресный запрос на выборку из таблицы SQL?

Как сравнить производительность, понятною Надо насовать over9000 тестовых данных во все таблицы и выполнить оба запроса. Оптимальнее первый.

Как создать вычислимое поле в модели Code First Entity Framework 6?

Евгений: Да, насчет экстремальной нормализации я понимаю. Есть доводы за и против нее, но большая нагрузка на сервер при формировании отчетов – не мой случай. Кроме того, в Enterprise-системе никому никогда не придет в голову (на самом деле, случается) хранить или рассчитывать суммарное количество по документу уже хотя бы потому, что количества в разных строках одного документа могут быть в разных единицах измерения.
На самом деле, меня интересует более общий вопрос. Можно ли в принципе в сущности EF описать свойство, значение которого рассчитывалось бы на SQL-сервере? Например, дата предыдущего документа того же типа на SQL рассчитывается элементарно:

lag(DocumentDate) over (partition by DocumentType_id order by DocumentDate)

Хранить это значение было бы ну совсем уж странно.

Как создать вычислимое поле в модели Code First Entity Framework 6?

Спасибо, это почти то, что надо. То есть, да, данные выбираются, но для того, чтобы рассчитать TotalQuantity по одному документу, выполняется 2 запроса: 1) собственно выборка реквизитов документа и 2) выборка строк. Да плюс еще постобработка на клиенте для суммирования по коллекции строк. Таким образом, если я захочу показать пользователю в гридушке n документов с количествами, система выполнит n+1 запрос. И результаты всех этих запросов в итоге будут занимать память клиента, пока вся коллекция документов не будет удалена, а польза от них только одна - посчитать суммарное количество. Как-то это неправильно, учитывая, что то же самое может посчитать один единственный запрос SQL.