Comments 14
Использование какой бы то ни было ORM в связке с Firebird — это верный путь к тормозам. Как только схема БД станет чуть сложнее примера, количество записей в таблицах перешагнёт за пару десятков тысяч, а логика отбора станет чуть изощрённее, чем просто отбор по датам, автоматически сгенерированные запросы просто положат эту СУБД, и никакие сложносочинённые индексы от этого не спасут. Единственный способ заставить эту штуку работать сравнительно быстро с большими объёмами данных — это писать запросы руками, а изредка ещё и подсовывать ему собственный план исполнения, потому что он не всегда справляется с построением хорошего плана самостоятельно.
Не то чтобы я хотел сказать что-то плохое про Firebird, у него есть множество своих преимуществ, основным из которых является простота установки и администрирования, это скорее камень в огород ORM.
Не то чтобы я хотел сказать что-то плохое про Firebird, у него есть множество своих преимуществ, основным из которых является простота установки и администрирования, это скорее камень в огород ORM.
Наверное, Вы работали с Firebird лет 10 назад, во времена 1.0-1.5, когда предикат IN неверно обрабатывался и прочие косяки были. Начиная с версии 2.0 оптимизатор значительно улучшен, а 2.5 и 3-ка, рассматриваемые в этом примере работают с автогенерированными запросами (много джойнов и подзапросов) уже очень хорошо. Естественно, лучше использовать ORM, которые понимают особенности оптимизации — для Firebird и Java это jOOq, например. Что там в .NET, сказать не могу.
Мы работали с ним 10 лет назад и продолжаем работать сейчас со стабильной версией 2.5. Подвижки в оптимизации там, без порно, есть, но в глобальном плане ничего особо не меняется. Банально несколько объединений в запросе и пара условий типа ИЛИ могу заставить его построить совершенно непотребный план выполнения запроса, и никакие индексы с идеальной селективностью не помогут, пока не задашь план вручную или не поменяешь декартово пересечение таблиц на соответствующего вида джойны, чтобы они в нужном порядке исполнялись.
Честно говоря, затруднился представить, зачем в валидном запросе может быть нужно декартово произведение. Обычно это результат ошибки. Или речь о том, что ORM генерирует декартово произведение? Тогда да, беда, но она на любой СУБД будет такой же бедой.
В отладчике видно какие запросы генерирует LINQ. Да они конечно кривые: на каждый чих выборка заворачивается в Devired Table, но оптимизатор такое спокойно разруливает. С агрегатами и группировками конечно дело хуже. В этом случае запрос составленный руками может работать в 10 раз быстрее.
Извините, но вы не совсем верно используете терминологию. Фактически, у вас здесь используется не Code First, а Database First, просто модель построена на Fluent API а не с помощью EDMX.
FirebirdSql.Data.FirebirdClient.dll на клиенте + IBExpert для разработки БД = быстро и удобно. Имхо.
Посмотрел на это и вспомнились курсовые в универе.
И все-таки pay это неправильный глагол.
Pay — paid — paid
Pay — paid — paid
Sign up to leave a comment.
Создание приложений для СУБД Firebird с использованием различных компонент и драйверов: ADO.NET Entity Framework 6