2010-04-06 3 views
1

Используя EF, мы можем использовать LINQ для чтения данных, которые довольно просты (особенно с использованием быстрых вызовов), но мы имеем меньше контроля, если не будем писать eSQL самостоятельно.Является ли запись базы данных eSQL независимой или нет?

  1. пишет ESQL на самом деле хранить данные независимый код?
    Итак, если мы решили изменить хранилище данных, могут ли использоваться те же самые заявления?
  2. Влияет ли запись строк eSQL в ваш код на серьезные угрозы безопасности, аналогичные написанию операторов TSQL в виде простых строк в коде C#? Вот почему рекомендуются SP. Можем ли мы по-прежнему перемещать скрипты eSQL вне кода и использовать какой-либо другой метод, чтобы сделать их более безопасными?

ответ

1
  1. ESQL зависит от базы данных в целом, поэтому он может быть использован как LINQ к Entities. Но, пожалуйста, имейте в виду, что у этого есть более серьезные ограничения. Он не обладает способностями DML, DDL и DB.
    Основным недостатком ESQL является то, что даже простой запрос, содержащий пару строк, может быть переведен в чудовищный SQL-запрос для конкретной СУБД, поэтому следует проверить, что сгенерированный SQL является подходящим и проанализировать, если он является оптимальным.
  2. ESQL не будет выполняться непосредственно в базе данных, он будет переведен на SQL. Обсуждение безопасности EF обычно начинается с проверки соединения, затем обсуждается проблема безопасности модели и только после проверки защиты запроса. Разработчик должен решить, следует ли защищать особый запрос.
+0

Основная причина, по которой я попросил это в первую очередь, - использовать eSQL для лучшей оптимизации фактических запросов БД. –

+0

Давайте рассмотрим случай с определенным скриптом eSQL, который на самом деле оказывается * кислым * (то есть чудовищным). Так что, если я оптимизирую его на моем конкретном БД, он будет оптимизирован и на других БД? Или, по крайней мере, лучше, чем оригинальный? Таким образом, он будет стремиться к оптимизированному eSQL? –

+0

К сожалению, ничего не гарантировано. SQL, оптимальный для одной СУБД, может быть ужасен для другого. Как вы знаете, наилучшая производительность в случае сложных запросов обычно достигается только с помощью написанных вручную собственных SQL-запросов (DefiningQuery для EntitySet или ObjectContext.ExecuteStoreQuery() в EFv4) или путем материализации сущностей, возвращаемых из хранимых процедур (используя Импорт функций). Но в этих случаях невозможная загрузка невозможна. – Devart