LINUX.ORG.RU

Когда базы данных нужны, а когда нет?

 ,


0

2

Пытаюсь разобраться, в каких случаях БД нужны в десктопных приложениях, а в каких нет. Поможете подобрать use cases?

Конкретно интересует следующее (но не только). Нужно как-нибудь организовать данные в оболочке для словарей. А именно, организовать информацию о словарных статьях (источник, URL, заголовок, код в HTML, plain text и пр.) и об элементах статьи (тип, plain text, позиция и пр.). Хранить можно все в памяти (на данный момент). Элементы статьи должны быть привязаны к конкретной статье.

На данный момент все написано на Python 3, информация о статьях хранится в sqlite3, а элементы статьи реализованы классами. Хочется унифицировать.

Что нравится в БД - это мощь select, делается быстро и не нужно писать дополнительный код, понятная организация данных и контроль БД. Что не нравится - нужно вычислять все за раз и обновлять в транзакциях, иначе будут просадки по скорости.

Deleted

Когда есть нужда хранить какие-то данные, которые удобно представлять в табличном виде или когда данных много (хотя тут могут быть варианты, всё зависит от типа данных).

peregrine ★★★★★
()

Какие ещё просадки скорости в оболочке для словарей?
Давай юскейсы и методики измерения, а то это разговор ни о чём

zolden ★★★★★
()

А готовой библиотеки с поддержкой какого-нибудь стандарта словарных баз у питона нет?

thesis ★★★★★
()
Ответ на: комментарий от peregrine

в табличном виде или когда данных много

Да, это мой случай.

Deleted
()
Ответ на: комментарий от zolden

Некоторые вещи, например, html-код статьи, позиция элементов и пр. могут меняться. Серии команд update (если их сотни) работают в sqlite очень медленно (иногда часами), если предварительно не засунуть их в транзакцию, но для этого нужно иметь все результаты на руках, что не всегда удобно из-за текущей организации кода. Я, конечно, могу делать все неправильно.

Deleted
()
Ответ на: комментарий от thesis

Есть модули для парсинга разных форматов словарей. Конкретно сейчас моя программа парсит html-код на multitran.ru, и внешние словари пока не подключаются. В отличие от StarDict, GoldenDict и пр., есть возможность работать с отдельными элементами статьи более глубоко (выделять/копировать/удалять/переводить одной кнопкой), в дальнейшем можно будет сортировать/игнорировать элементы, поэтому БД должна включать больше информации, чем может изначально предоставить словарь.

Deleted
()

Unkle Bob имеет рассказ, как они замечательно трудились над wiki движком вообще без базы данных. всё прекрасно работало и без неё. но потом пришли заказчики или инвесторы и сказали, что не нужна нам ваша вики, если в ней нет mysql. у нас в корпорации так принято, надо mysql и всё тут.
мораль расплывчата, наверное, но если работает без БД, зачем БД?
а если тебе нужен ACID, то как без БД?
тебе нужен ACID?

system-root ★★★★★
()
Ответ на: комментарий от system-root

Нет, ACID мне не нужен, мне нужна более-менее четкая структурированность данных. OK, если без БД, то в каком виде, если будет нужно, сохранять данные на диск? Есть pickle, но он пишет все сразу и не загрузится, если из кода удалить класс, создающий pickle.

Deleted
()
Ответ на: комментарий от Deleted

не готов тебе прям сходу начать придумывать методы хранения в файлах для твоей задачи. там всякое можно напридумывать.
скажем «четкая структурированность данных» имеет яркую ассоциацию с XML
ещё я не понял, зачем хранить HTML? это не данные вовсе и у всех одинаковые.

system-root ★★★★★
()
Ответ на: комментарий от system-root

зачем хранить HTML?

В данный момент программа принимает на входе html, автосгенерированный авторами Мультитрана и обвешанный лапшой на JavaScript. Он подчищается, структурируется в виде таблицы и создается новый html, который и выводится на экран. html-код хранится для тех случаев, когда пользователь через историю перейдет на уже обработанную словарную статью, чтобы не проводить повторный анализ .

Deleted
()
Ответ на: комментарий от Deleted

Это всё хорошо, но не нарушаешь ли ты пользовательские условия сайта мультитрана? Если это так, то не имеет смысла заморачиваться с программой, рано или поздно всё это перестанет работать по техническим или юридическим причинам.

unC0Rr ★★★★★
()
Ответ на: комментарий от Deleted

update не нужны, делай insert + время, на которую запись актуальна

anonymous
()
Ответ на: комментарий от zolden

Интересная штука, посмотрю. Спасибо.

Deleted
()
Ответ на: комментарий от unC0Rr

Во-первых, их «пользовательские условия» нигде не прописаны. Во-вторых, в чем состоит нарушение? Я получаю ровно то же, что и пользователь браузера. Помнится, рекламщики хотели засудить AdBlock, но здравый смысл восторжествовал.

Deleted
()

Нужны, когда данных много, либо когда нужны разнообразные критерии поиска.

Если в твоей базе будет 200 записей, городить БД смысла нет, можно всё хранить в XML. А вот когда записей несколько тысяч - БД однозначно лучше, пусть даже SQLite.

Меня вот печалит, что все программы учёта личных финансов в Linux сделаны на файлах, хотя там как раз явно напрашивается БД, хотя бы из соображений быстродействия. (Последний KMyMoney, правда, умеет в БД, но если я не ошибаюсь, там это лишь один из способов хранения, прикрученный сбоку и проблему быстродействия не решающий.)

hobbit ★★★★★
()
Ответ на: комментарий от Deleted

Думаю, само по себе это не является определяющим фактором.

hobbit ★★★★★
()
Ответ на: комментарий от Deleted

Что генерируется, то в бизнес-логику и покрыть тестами. Что статично, то в БД. Что ты как маленький?

Tark ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.