Должен ли я быть обеспокоен тем, что ORM по умолчанию возвращают все столбцы?

Question

Из моего ограниченного опыта работы с ORM (до сих пор LLBL Gen Pro и Entity Framework 4) я заметил, что по сути запросы возвращают данные для всех столбцов.Я знаю, что NHibernate - это еще один популярный ORM, и я не уверен, применимо ли это к нему или нет, но я бы предположил, что это так.

Конечно, я знаю, что есть обходные пути:

• Создание представления SQL и создание моделей и сопоставлений в представлении
• Использование хранимой процедуры и создание моделей и сопоставлений для возвращенного набора результатов

Я знаю, что соблюдение определенныхпрактики могут помочь смягчить это:

• Обеспечение разумного ограничения количества строк при выборе данных
• Обеспечение не слишком широких таблиц (большое количество столбцов и / или большие типы данных)

Итак, вот мои вопросы:

1. Достаточно ли вышеприведенных методов достаточно, или мне все же стоит подумать над поиском способов ограничения количества возвращаемых столбцов?

2. Существуют ли другие способы ограничения возвращаемых столбцов, кроме тех, которые я перечислил выше?

3. Как вы обычно подходите к этому в своих проектах?

Заранее спасибо.

ОБНОВЛЕНИЕ: Этот вид связан с представлением о том, что SELECT * считается плохой практикой.См. это обсуждение .

Answer 1

Одна из причин использования ORM практически любого рода заключается в том, чтобы отложить многие из этих проблем более низкого уровня и сосредоточиться на бизнес-логике.До тех пор, пока вы сохраняете разумное объединение и разумную ширину таблицы, ORM предназначены для упрощения ввода и вывода данных, и для этого требуется наличие всей строки.

Лично я рассматриваю подобные проблемыпреждевременная оптимизация, пока не возникнет конкретный случай, который застопорился из-за ширины таблицы.

Answer 2

Во-первых: отличный вопрос, и о времени кто-то спросил это!:-)

Да, тот факт, что ORM обычно возвращает все столбцы таблицы базы данных, - это то, что вы должны учитывать при проектировании своих систем.Но, как вы упомянули - есть способы обойти это.

Главный факт для меня - это осознавать , что это то, что происходит - или SELECT * FROM dbo.YourTable, или (лучше)a SELECT (list of all columns) FROM dbo.YourTable.

Это не проблема, если вам действительно нужен весь объект и все его свойства, и если вы загружаете несколько строк, это тоже хорошо - удобство превосходит необработанную производительность.

Возможно, вам придется немного подумать об изменении структуры вашей базы данных, например:

• , возможно, поместить большие столбцы, такие как BLOB, в отдельные таблицы со ссылкой 1: 1.в вашу базовую таблицу - таким образом, выборка в родительских таблицах не захватывает все эти большие объекты данных

• , возможно, помещает необязательные группы столбцов, которые могут отображаться тольков определенных ситуациях, в отдельные таблицы и связывать их - опять же, просто для того, чтобы базовые таблицы были простыми

Кроме того: избегайте попыток "заставить" ваш ORM "работать".массовые операции - это просто неИх сильная сторона.

И: следите за производительностью и попробуйте выбрать ORM, который позволяет вам изменять определенные операции, например, на хранимые процедуры - Entity Framework 4 позволяет это.Так что, если удаления убивают вас - возможно, вы просто пишете Delete сохраненный процесс для этой таблицы и обрабатываете эту операцию по-другому.

Answer 3

Существуют ли другие способы ограничения возвращаемых столбцов, кроме тех, которые я перечислил выше?

NHibernate позволяет добавлять проекции к вашим запросам, чтобы вам не приходилось использовать представления или процедуры только для ограничения ваших столбцов.

Answer 4

Вопрос здесь охватывает ваши варианты довольно хорошо. По сути, вы ограничены созданием вручную HQL / SQL. Это то, что вы хотите сделать, если столкнетесь с проблемами масштабируемости, но, если судить по моему опыту, это может иметь очень большое положительное влияние. В частности, это экономит много дискового и сетевого ввода-вывода, поэтому ваша масштабируемость может значительно возрасти. Не то, чтобы делать прямо сейчас: проанализируйте, а затем оптимизируйте.

Answer 5

В LLBLGen Pro вы можете вернуть Типизированные списки , которые не только позволяют вам определить, какие поля возвращаются, но также позволяют объединять данные, чтобы вы могли получить пользовательский список полей из нескольких таблиц.

В целом, я согласен, что в большинстве случаев это преждевременная оптимизация.

Одно из больших преимуществ использования LLBLGen и других ORM (я чувствую себя уверенно, говоря о LLBLGen, потому что я использовал его с момента его создания), заключается в том, что производительность доступа к данным была оптимизирована людьми, которые понимают проблемы лучше, чем ваш средний медведь.

Всякий раз, когда они находят способ еще больше ускорить свой код, вы получаете эти изменения "бесплатно", просто заново сгенерировав свой слой данных или установив новую DLL.

Если вы не считаете себя экспертом в написании кода доступа к данным, ORM, вероятно, повысят эффективность и точность большинства разработчиков.

Answer 6

Вы можете ограничить количество возвращаемых столбцов, используя Projection и Transformers.AliasToBean и DTO, как это выглядит в Criteria API:

.SetProjection(Projections.ProjectionList()
    .Add(Projections.Property("Id"), "Id")
    .Add(Projections.Property("PackageName"), "Caption"))
.SetResultTransformer(Transformers.AliasToBean(typeof(PackageNameDTO)));

Answer 7

Для меня это было проблемой, только если в таблицах есть LOTS столбцов> 30 или если в столбце было много данных, например, более 5000 символов в поле.

Я использовал подходпросто сопоставить другой объект с существующей таблицей, но только с полями, которые мне нужны.Так что для поиска, который заполняет таблицу 100 строками, у меня будет MyObjectLite, но когда я нажму, чтобы просмотреть детали этой строки, я вызову GetById и верну MyObject со всеми столбцами.

ДругойПодход состоит в том, чтобы использовать пользовательский SQL, Stroed Procs, но я думаю, что вы должны идти по этому пути только в том случае, если вам ДЕЙСТВИТЕЛЬНО требуется повышение производительности и когда пользователи жалуются.Поэтому, если нет проблем с производительностью, не тратьте свое время на исправление несуществующей проблемы.