Мой провайдер Devart Entity Framework передает следующую ссылку на сущности.
from p in context.BEAT_CONTACT
join cl in context.COMPASS_LOCATIONS
on p.GAZETEER_KEY equals cl.GAZETTEER_KEY
//on new { bcdid = p.GAZETEER_KEY.Value }
//equals new { bcdid = cl.GAZETTEER_KEY.Value }
into myRandomlj
from rr in myRandomlj.DefaultIfEmpty()
Примечание. Столбцы соединения имеют тип данных, допускающий обнуление, в БД и, следовательно, десятичные? в с #
Сгенерированный SQL:
FROM NP_TEST.BEAT_CONTACT "Extent1"
LEFT OUTER JOIN NOTTS_DW_OWNER.COMPASS_LOCATIONS "Extent2"
ON ("Extent1".GAZETEER_KEY = "Extent2".GAZETTEER_KEY)
* OR (("Extent1".GAZETEER_KEY IS NULL)
* AND ("Extent2".GAZETTEER_KEY IS NULL))
Помеченные (*) ИЛИ и И добавляют дополнительные секунды на выполнение моего sql. Когда оператор помещается в жабу (между прочим, oracle devart ef provider) с удаленными помеченными элементами, sql, очевидно, работает намного быстрее.
Мой вопрос: мой linq к сущностям виноват или что-то упустил? Или это ошибка поставщика Devart EF?
Обновление до вопроса:
Здравствуйте, как первоначальный создатель этого вопроса, я хотел бы попытаться получить ясность по этому вопросу, если это возможно. Из комментариев LukLed: «Поставщики Entity Framework по умолчанию работают правильно и не создают таких условий SQL. Это не только неправильно, но и сильно снижает производительность». Я в основном обеспокоен комментарием «снижение производительности», этот удар огромен, особенно с учетом того, что число строк увеличивается с обеих сторон соединения. Мне пришлось обойти это поведение с помощью ExecuteStoreQuery <> или Sproc. Это означало отсутствие linq, и мне пришлось надеть шляпу sql, чтобы выполнить работу.