Мой провайдер 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) с удаленными элементами, отмеченными звездочкой, SQL, очевидно, работает намного быстрее.
Мой вопрос: моя ссылка на сущности виновата или чего-то не хватает? Или виноват провайдер Devart EF?
Обновление вопроса: Здравствуйте, как первоначальный создатель этого вопроса, я хотел бы попытаться прояснить этот вопрос, если это возможно. Из комментариев LukLed: «Поставщики Entity Framework по умолчанию работают правильно и не создают таких условий SQL. Это не только неправильно, но и сильно снижает производительность». Меня в основном беспокоит комментарий «нападающего производительности», этот удар огромен, особенно потому, что количество строк увеличивается по обе стороны от соединения. Мне приходилось обходить это поведение с помощью ExecuteStoreQuery‹> или Sproc. Это означало отсутствие linq, и мне пришлось надеть шляпу sql, чтобы выполнить работу.
SQLкак есть. Если бы программист хотел соединиться по нулям, он бы явно добавил это условие, но кто на самом деле соединяется поNULL? Поставщики Entity Framework по умолчанию работают правильно и не создают такихSQLусловий. Это не только неправильно, но и сильно снижает производительность. Кто-то не понимает, чтоNULLявляется особым значением вSQLи не должно относиться к нему так же. - person LukLed   schedule 15.02.2011