Внутренние соединения расширений SQLite в GetAllWithChildren

В настоящее время мы пробуем расширения SQLite (PCL) в качестве ORM.

Нам интересно, должно ли сопоставление создавать SELECT с INNER JOIN для дочерних элементов, если они правильно настроены в сущности?

public class Project
{
    [PrimaryKey]
    public long Id { get; set; }

    [ForeignKey(typeof(EnterpriseClient))]
    public long EnterpriseClientId { get; set; }

    [ManyToOne]
    public EnterpriseClient EnterpriseClient { get; set; }

    [OneToMany(CascadeOperations = CascadeOperation.All)]
    public List<WorkOrderHead> WorkOrderHeads { get; set; }
}

Если мы получим все проекты с помощью GetAllWithChildren:

var x = _db.GetAllWithChildren<Project>(p => true);

Наш результат — множественный выбор для каждого дочернего элемента (EnterpriseClient), и мы надеялись, что он будет заключаться в одном выборе и соединении для одновременного сбора всех данных.

Наша конфигурация неверна или так и должно быть?


c# xamarin.android orm sqlite-net sqlite-net-extensions
person Nicolas Belley    schedule 06.07.2015    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Прямо сейчас SQLite-Net Extensions выполняет SELECT для каждого извлекаемого свойства, а также страдает от Проблема N+1 в операциях чтения (уже решена для операций записи). Он реализован как очень тонкий слой над SQLite.Net, предоставляя вам некоторые удобные методы для доступа к отношениям сущностей. В настоящее время он работает так, как вы описали как предполагаемое поведение. Доступ к регистрам по первичному ключу или индексированному свойству выполняется очень быстро, а производительность не является проблемой для небольших баз данных, таких как используемые в большинстве мобильных проектов.

SQLite-Net Extensions — это развивающийся проект, поэтому всегда приветствуются запросы функций (и, конечно, запросы на вытягивание). Однако ВНУТРЕННИЕ СОЕДИНЕНИЯ нарушили бы сопоставление SQLite.Net, поэтому один SELECT, возвращающий всю необходимую информацию, потребовал бы повторной реализации механизма сопоставления SQLite.Net.

Теоретически возможно обойти проблему N+1, выполняя один SELECT для каждого свойства, поэтому рекурсивные операции TO-MANY увидят улучшение производительности. Я создал проблема, чтобы отслеживать этот запрос.

Удачного кодирования!

person redent84    schedule 07.07.2015
comment
Спасибо, этого я и опасался. Итак, в мобильном мире, должны ли мы забыть об ORM и сосредоточиться на выполнении наших собственных SELECT в базе данных? - person Nicolas Belley; 07.07.2015
comment
Ну, мне нужно было выполнить выбор вручную в очень немногих сценариях. В большинстве случаев улучшение производительности было незначительным, а простой в использовании и дружественный к рефакторингу подход склонял чашу весов в пользу расширений SQLite-Net. Использование асинхронных операций еще больше снижает влияние на производительность. Поэтому я бы посоветовал вам измерить, прежде чем оптимизировать. - person redent84; 07.07.2015
comment
После бенчмаркинга наш собственный выбор оказался намного быстрее, чем вложенный выбор с использованием фреймворка. Мы создали конструкторы EntityView, которые создают сложные запросы. Использование разрешения дочерних объектов по умолчанию было намного медленнее... - person Nicolas Belley; 04.09.2015