Pull to refresh

Comments 14

Использование какой бы то ни было ORM в связке с Firebird — это верный путь к тормозам. Как только схема БД станет чуть сложнее примера, количество записей в таблицах перешагнёт за пару десятков тысяч, а логика отбора станет чуть изощрённее, чем просто отбор по датам, автоматически сгенерированные запросы просто положат эту СУБД, и никакие сложносочинённые индексы от этого не спасут. Единственный способ заставить эту штуку работать сравнительно быстро с большими объёмами данных — это писать запросы руками, а изредка ещё и подсовывать ему собственный план исполнения, потому что он не всегда справляется с построением хорошего плана самостоятельно.

Не то чтобы я хотел сказать что-то плохое про Firebird, у него есть множество своих преимуществ, основным из которых является простота установки и администрирования, это скорее камень в огород ORM.
Наверное, Вы работали с Firebird лет 10 назад, во времена 1.0-1.5, когда предикат IN неверно обрабатывался и прочие косяки были. Начиная с версии 2.0 оптимизатор значительно улучшен, а 2.5 и 3-ка, рассматриваемые в этом примере работают с автогенерированными запросами (много джойнов и подзапросов) уже очень хорошо. Естественно, лучше использовать ORM, которые понимают особенности оптимизации — для Firebird и Java это jOOq, например. Что там в .NET, сказать не могу.
Мы работали с ним 10 лет назад и продолжаем работать сейчас со стабильной версией 2.5. Подвижки в оптимизации там, без порно, есть, но в глобальном плане ничего особо не меняется. Банально несколько объединений в запросе и пара условий типа ИЛИ могу заставить его построить совершенно непотребный план выполнения запроса, и никакие индексы с идеальной селективностью не помогут, пока не задашь план вручную или не поменяешь декартово пересечение таблиц на соответствующего вида джойны, чтобы они в нужном порядке исполнялись.
Честно говоря, затруднился представить, зачем в валидном запросе может быть нужно декартово произведение. Обычно это результат ошибки. Или речь о том, что ORM генерирует декартово произведение? Тогда да, беда, но она на любой СУБД будет такой же бедой.
Декартово произведение — это когда в предложении FROM перечислено несколько таблиц. Если честно, я не совсем понимаю, зачем нужна СУБД, если не использовать такие запросы.
Вы, наверное, имеете в виду неявное соединие таблиц путем указания связей в WHERE. Погуглите — декартово произведение определяется по другому и вряд ли имеет широкое практическое применение :)
В отладчике видно какие запросы генерирует LINQ. Да они конечно кривые: на каждый чих выборка заворачивается в Devired Table, но оптимизатор такое спокойно разруливает. С агрегатами и группировками конечно дело хуже. В этом случае запрос составленный руками может работать в 10 раз быстрее.
Извините, но вы не совсем верно используете терминологию. Фактически, у вас здесь используется не Code First, а Database First, просто модель построена на Fluent API а не с помощью EDMX.
То что модель получена из базы данных с помощью мастера ещё не обозначает, что она перестала быть Code First. Хотя да в этом случае база данных была до кода. На скриншотах это видно.
Так вот я как раз об этом, модель сама по себе не может быть Code First или Database First, модель просто хранит метаданные в формате EDMX или FluentAPI-кода. Кроме того, в следующей версии EF FluentAPI вообще будет единым форматом модели для всех трех сценариев. Но, ок, наверное, я придираюсь.
FirebirdSql.Data.FirebirdClient.dll на клиенте + IBExpert для разработки БД = быстро и удобно. Имхо.
Посмотрел на это и вспомнились курсовые в универе.
И все-таки pay это неправильный глагол.
Pay — paid — paid
Only those users with full accounts are able to leave comments. Log in, please.