Как стать автором
Обновить

Комментарии 32

На этот проект не смотрели realm.io?
Смотрели, отпугивает размер библиотеки и закрытость кода самой базы данных (доступны исходники только оберток).
Разве закрыты? На GitHub лежат все исходники библиотеки, просто ядро на C++ (NDK).
Исходный C++ код просмотрел мельком, смутили такие include

#include <tightdb/group_shared.hpp>
#include <tightdb/replication.hpp>
#include <tightdb/commit_log.hpp>


Могу ошибаться о закрытости кода ядра, создатели приводят инструкцию по сборке.
Поддерживаю вопрос. Хотелось бы увидеть realm в отчете, для полноты картины.
Realm — nosql база данных. Это конечно ничего, но вот отсутствие поддержки primary key меня остановило на половине пути внедрения.
github.com/realm/realm-java/pull/565
Другой вопрос, что для боевого применения его все еще рано использовать, иногда просто падает сам движок, мы попробовали наше приложение и при наличии определенных данных движок скисал, причем не только в телефоне, но и в их браузере.
Разве это реляционная БД? Все-таки парадигма-то не одна и та же. В статье автор рассматривает использование ORM для реляционных баз данных.

Мне гораздо интереснее было бы, если бы вы еще Cupboard попробовали и поделились своим мнением.
Для большинства приложений реляционная БД и не нужна.
Я вот чего не понимаю, а зачем вообще БД? У нас же не серверное приложение, которому действительно нужно хранить много разных данных. Я писал клиенты (не под android), и ни разу не понадобилась БД. Просто хранишь все в памяти, если нужны новые данные — запрашиваешь с сервера. Это именно какая-то android-специфика?
Мобильные клиенты используют БД как кэш, чтобы обеспечить работу приложения без интернета. Особенно это актуально для Android где приложение может быть выгружено из памяти в любой момент. Согласитесь, что гораздо приятнее смотреть на кэшированные данные, чем на сообщение об ошибке.
Просто если это рантайм-кеш, то все равно без бд проще. Ничего лишнего, хранишь сразу как тебе удобно. А вот в условиях «приложение может быть выгружено из памяти в любой момент», действительно оптимальна локальная бд. Спасибо за разъяснения.
Ничего лишнего, хранишь сразу как тебе удобно.

Я думаю, что в основном удобно как раз в БД хранить, чем изобретать и дебажить свои велосипедные, быстро усложняющиеся со временем форматы данных, поверх которых медленно прикручиваются самодельные индексы для ускорения поиска, самопальные DQL для удобства поиска и так далее.
Логично поместить кешированные данные в файлы кэша.
И организовать эти файлы как базу данных для удобства доступа. Например, SQLite отличное решение для хранения всего в файле… И, внезапно, стандартное для Android.
Например, приложение для учета финансов с различными отчетами (без серверной части).
Можно попробовать настройки SQLite (cache_size и journal_mode), на андроиде их наверное можно задать через #pragma. Ускорите и чтение и запись соответственно.
Кроме того в SQLite insert поддерживает множественную вставку (INSERT INTO Table ( Column1, Column2 ) VALUES( Value1, Value2 ), ( Value1, Value2 )) — тоже можно оптимизировать на уровне ORM (сумеет ли андроид — другой вопрос).
Еще интересно, что за данные вы писали(40-20 сек это достаточно много).
Попробовать настройки SQLite и множественный insert действительно интересно, стоит провести эксперимент. Спасибо за совет.

Список о котором идет речь в статье (который сохранялся 40 секунд) состоял из 10 полей, одно из которых было ссылочным полем на другую сущность. Список состоял примерно из 500 объектов.
Чет тут не так. Можно код посмотреть?
присоединяюсь, походу коммит тут после каждого инсерта.
Ответил в личку
Код сохранения списка до оптимизации:

if (response.isSuccessful()) {
    try {
        ActiveAndroid.beginTransaction();
        ArrayList<Deputy> deputies = new ArrayList<Deputy>();
        JSONArray array = response.getData().getJSONArray("deputat_list");
        for (int i = 0; i < array.length(); ++i) {
            Deputy deputy = Deputy.fromJSON(array.getJSONObject(i));
            deputy.save();
            deputies.add(deputy);
        }
        this.deputies = deputies;
        DeputiesConnections.setRelationsF(DeputiesConnections.class, DeputiesList.this, deputies);
        ActiveAndroid.setTransactionSuccessful();
        return ERROR_NOT_SET;
    } catch (Exception e) {
        Log.e("Cannot parse deputies list", e);
        return ERROR_UNKNOWN;
    } finally {
        ActiveAndroid.endTransaction();
    }
}


Код сохранения списка после введения оптимизации:

if (response.isSuccessful()) {
    try {
        ActiveAndroid.beginTransaction();
        ArrayList<Deputy> deputies = new ArrayList<Deputy>();
        JSONArray array = response.getData().getJSONArray("deputat_list");
        for (int i = 0; i < array.length(); ++i) {
            Deputy deputy = Deputy.fromJSON(array.getJSONObject(i));
            deputies.add(deputy);
        }
        Deputy.saveMultiple(deputies);
        this.deputies = deputies;
        DeputiesConnections.setRelationsF(DeputiesConnections.class, DeputiesList.this, deputies);
        ActiveAndroid.setTransactionSuccessful();
        return ERROR_NOT_SET;
    } catch (Exception e) {
        Log.e("Cannot parse deputies list", e);
        return ERROR_UNKNOWN;
    } finally {
        ActiveAndroid.endTransaction();
    }
}


На самом деле точное время взято больше для красного словца, точные значения уже забылись, но порядок примерно такой.
Скрытый текст
Ответил в личку
На maven/jcenter планируете выложить?
Подскажите
пожалуйста сколько по времени миллисекунд выполняется коннект к базе
и первый запрос данных с нулевого старта приложения?

Большое спасибо за такое нужное приложение! Вкрячил в него свой велосипед, который, ожидаемо, оказался худшим. Буду стараться обойти хотя бы Sugar ORM.
Хм, переделал работу с транзакцией: перегнал по записи не только Sugar ORM и ActiveAndroid, но и ORMLite. Теперь вот чтение…
Тест производительности слишком тепличный.
Сам однажды наступил на подобные грабли. Делали некую ORM-прослойку на основе генерации SQL-запросов «на лету». Когда речь шла про отдельные таблицы и простейшие CRUD-запросы, все было великолепно. Когда понадобились связанные таблицы и ссылочные поля — генерация запросов усложнилась в разы (что пришлось долго отлаживать и чинить), производительность упала из-за невозможности всегда сгенерить оптимальный запрос в конкретной ситуации.
Когда дошло до сложных выборок — тут объем необходимого высокоуровнего кода стал резко превышать сложность генерируемого внутри SQL-запроса. Т.е. такие задачи проще было бы решать без этой прослойки. Да вот незадача — следующий уровень абстракции уже был заточен на ORM.

Но справедливости ради, думаю в Android подобных сложных кейсов быть не должно.
Когда-то наступил на грабли, решая на андроиде всё как на сервере, при работе с базой данных. Это принесло очень много неудобств и ограничений.
Сейчас одна таблица аля: запрос, немного другой инфы и JSON. Результат на лицо: всё работает в разы быстрее и приятнее.
Итог: на сервере подготавливать всё наперёд, а андроид — он хоть и сильный, но служит в большинстве случаев, для отображения данных.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.