SQL-запросы в .NET

Question

Я обычно использую Entity Framework для своих запросов SQL, что прекрасно, поскольку позволяет динамически создавать запросы строго типизированного и удобного в обслуживании способа.
Однако в данный момент я работаю над проектом, который использует пространственные запросы.,Большинство моих запросов будут выводить порядок набора результатов по времени или расстоянию от заданной координаты.Однако я обнаружил, что упорядочение по STDistance замедляет запрос в 10 раз.(на самом деле это замедляется, если я присоединяюсь к другой таблице в дополнение к «упорядочить по»)

Мне удалось оптимизировать запрос самостоятельно и вернуть производительность обратно туда, где она должна быть, однако этот запрос не можетбыть произведенным Entity Framework.

Таким образом, я мог бы получить набор запросов «порядок по времени», сгенерированный EF, а затем другой набор запросов «порядок по расстоянию» как хранимые процедуры в SQL Server.Проблема в том, что, в основном, этот последний набор запросов должен был бы быть создан с помощью конкатенации строк (либо в SP, либо в C #).

Я пытался уйти от конкатенации строк SQL в течение многих лет иэти платформы ORM отлично подходят для 99% запросов, однако мне всегда приходится возвращаться к конканенации строк, чтобы получать самые оптимальные запросы, отправляемые на сервер.Это кошмар обслуживания, хотя.

Конкатенация строк была решена в ASP.NET с шаблонизаторами, которые, по сути, позволяют создавать строки HTML.Кто-нибудь знает такое решение для строк SQL?Несмотря на то, что в некоторых отношениях это немного неаккуратно, он допускает наиболее оптимальные запросы.На мой взгляд, это было бы лучше, чем

• Конкат строки в сохраненном процессе
• Конкат строки в C #
• Массы дублирующегося кода в хранимых процессах, охватывающие все возможные входныепараметры
• LINQ-запросов, которые могут создавать неоптимальный SQL

Мне бы очень хотелось узнать ваши мысли об этой общей проблеме и что вы думаете о моем предлагаемом решении.
спасибоKris

Answer 1

Вы проверили последнюю Entity Framework Beta ? Предполагается, что он поддерживает пространственные типы данных.

Кроме того, если вы хотите динамически создавать SQL-запросы, ознакомьтесь с SQL Builder от PetaPoco . Некоторые примеры с сайта:

Пример 1:

var id=123;
var a=db.Query<article>(PetaPoco.Sql.Builder
    .Append("SELECT * FROM articles")
    .Append("WHERE article_id=@0", id)
    .Append("AND date_created<@0", DateTime.UtcNow)
)

Пример 2:

var id=123;
var sql=PetaPoco.Sql.Builder
    .Append("SELECT * FROM articles")
    .Append("WHERE article_id=@0", id);

if (start_date.HasValue)
    sql.Append("AND date_created>=@0", start_date.Value);

if (end_date.HasValue)
    sql.Append("AND date_created<=@0", end_date.Value);

var a=db.Query<article>(sql)

Пример 3:

var sql=PetaPoco.Sql.Builder()
    .Select("*")
    .From("articles")
    .Where("date_created < @0", DateTime.UtcNow)
    .OrderBy("date_created DESC");

Answer 2

Трудно понять вопрос.

Любая форма EF всегда будет медленнее, чем sql ручной работы.Итак, нам осталось вручную создавать и управлять этими SQL-запросами.Это можно сделать

1. , вручную написать procs
2. написать «умные procs» с конкатенацией строк SQL в них
3. использовать механизм шаблонов для генерации этих procs во время компиляции
4. Напишите свой собственный linq для sql провайдера для генерации запросов во время выполнения

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

Answer 3

Может быть, будет возможность использовать шаблон T4 для генерации представлений (и соответствующих запросов). Вы можете изменить шаблон или выборочно переопределить сгенерированный вывод (хотя для этого также может потребоваться изменить шаблон).

Microsoft предоставляет шаблон T4 для этой цели (при условии, что вы не используете код в первую очередь, поскольку я не уверен, что для этого сценария существует эквивалент).

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