Перемещение этого в «ответ», потому что то, что я хочу сказать, слишком длинное для комментария.
Похоже, вы сталкиваетесь с неотъемлемым ограничением для ORM. Вы не получите идеальной производительности, пытаясь сделать все в коде. Похоже, вы пытаетесь использовать ORM, как интерфейс T-SQL, а не для сопоставления объектов и реляционного экземпляра данных.
Вы говорите, что хотите поддерживать совместимость между базами данных, но это уже нестартер, если вы рассматриваете различия схем из базы данных в базу данных. Если вы уже выполняете шаг проверки схемы, чтобы убедиться, что ваш код не сломается, тогда не должно быть причин, по которым вы не можете использовать что-то вроде просмотров.
Вы можете сказать, что не хотите поддерживать эти вещи весь день, но простой момент в том, что эти вещи существуют, потому что они затрагивают определенные проблемы. Если вы опережаете их, то вы не можете рассчитывать избавиться от этой проблемы. Некоторые вещи просто улучшают базу данных.
Итак, я думаю, вы ожидаете чего-то из технологии, которую он не должен был решать. Вам нужно будет либо пересмотреть свою стратегию, либо использовать другой инструмент для ее выполнения. Я думаю, вам может понадобиться пара разных инструментов.
Что вы делали, возможно, работало, когда ваш масштаб был меньше. На самом деле я мог видеть, как это работает. Тем не менее, он имеет ограничение по шкале, и я думаю, что вы против этого.
Я думаю, вам нужно определить, какие базы данных вы хотите поддерживать. Высказывание «мы поддерживаем все базы данных» несостоятельно. Затем сравните функции и используйте общие. Если это дело MS SQL и MySQL, то нет причин, по которым вы не можете использовать представления или хранимые процедуры.
Пожалуйста, дайте пример, демонстрирующий размер и сложность вы имеете дело с. – Bigsby
Можете ли вы использовать EntitySQL или вы строго хотите выражения linq? – vittore
@Bigsby извините, но не могу поделиться кодом, его sql с более чем 300 строк кода с большим количеством объединения и агрегации в нем – pabbasian