сериализация вместо базы данных

 
 
 
Сообщения:499
вопрос - есть ли в этом смысл, если объемы оперируемых данных не очень велики? и на скольок они должны быть не велики? просто как мне кажется проделывать с объектом все нужные манипуляции в разы легче, чем с базой или всякими персистенз апи. и быстрее.
 
 
Сообщения:7989
Ну тут дело такое, если вам просто надо объект сбросить в файл чтобы позже считать обратно - то можно сериализовать (только не стандартным апи - а в json например).

А если у вас хотя бы там список пользователей и их транзакций, то наверняка уже удобнее будет уметь выбирать по более или менее хитрым запросам и т.п.

При этом если объёмы данных невелики то это просто означает что вы базу можете попроще взять, возможно, встраиваемую.

www.codeabbey.com - programming problems for novice coders (+ certificates)
 
 
Сообщения:126
lorenai:
как мне кажется проделывать с объектом все нужные манипуляции в разы легче, чем с базой или всякими персистенз апи. и быстрее.

А легче ли? И насколько велика разница относительно остального объёма приложения?

И там, и там нужно создать объект из некоторого вида исходников - JSON или БД. После этого работа с объектом будет одна и та же. Если кол-во вариантов с запросами конечное(не будет же пользователь произвольные запросы в консоли вводить, значит, есть некий ГУИ с конечным числом вариаций), то это нужно реализовать всего один раз, покрыть тестами и закоммитить. После этого разница роли уже не играет.

Life without limits
Изменен:17 окт 2014 18:28
 
 
Сообщения:1527
Quote:
А если у вас хотя бы там список пользователей и их транзакций, то наверняка уже удобнее будет уметь выбирать по более или менее хитрым запросам и т.п.
При этом если объёмы данных невелики то это просто означает что вы базу можете попроще взять, возможно, встраиваемую.

Ссылка на проект, опубликованная RodionGork'ом некоторое время назад ))) cqengine
Движок отлично прижилась на андроиде, в проектах, где нет острой необходимости/желания возиться с SQLite.
 
 
Сообщения:129
Так базы-то разные бывают, например MapDB.
Изменен:17 окт 2014 19:52
 
 
Сообщения:1517
Помимо всех этих перекладушек в различные не соответствующие объектам формы данных и сериализации существует event sourcing. Вместо самого объекта сохраняются события, приводящие к изменению состояния объекта. Соответственно повторно воспроизводя эти события можно получить последнее (или в любой момент времени) состояние объекта. На основе этих событий можно составлять любое представление данных. В том числе и такое, о котором вы сейчас даже не задумываетесь, но когда оно понадобиться, все данные для его наполнения уже будут.
 
 
Сообщения:499
допустим, у меня объект в котором лежит лист объектов типа запись с кучей сеттеров геттеров и тп. выборка, сортировка через апи коллекций вопрос в принципе, не сложный. меня такой вопрос мучает, скажем там пару тысяч записей (некая таблица с десятком полей) в аррайлисте -- и я грузану ее в память.. что будет с памятью? :) и как быстро этот лист будет обрабатываться в случае итерирования и т.п.? или это вообще - плохая идея? :)
 
 
Сообщения:499
Barlog:
Так базы-то разные бывают, например MapDB.

к базе я склоняюсь аш2, дело в том, что в теме скул запросов я немного плаваю, в теме ЖПА я уже практически совсем ноль, а как работать с коллекциями, итерацией, выборкой и т.п. в яве мне проще. или не морочить голову себе голову и делать всё по-людски?
 
 
Сообщения:129
Клиент у базы один будет? То есть приложению всего-лишь нужно сохранить свои данные? Даже если один объект будет занимать 10 килобайт, то пара тысяч таких объектов - это мелочь. Не нужен тут SQL никакой, даже встраиваемый H2.
MapDB - это и есть коллекция, которая умеет сохраняться на диск.
 
 
Сообщения:499
да, это небольшое веб приложение на спринге. спасибо за наводку вам. это яп сказал идеально просто что можно будет избавиться от базы вовсе.
 
 
Сообщения:7989
Quote:

Клиент у базы один будет? То есть приложению всего-лишь нужно сохранить свои данные? Даже если один объект будет занимать 10 килобайт, то пара тысяч таких объектов - это мелочь. Не нужен тут SQL никакой, даже встраиваемый H2.

Ну вот я автора топика так и не понял - нужно ли ему ещё кроме сохранения уметь как-то данные индексировать и выбирать или нет :)

Просто если дело закончится построением собственных головоломных запросов на мэпах - это ненужный гемор :)

Quote:

MapDB - это и есть коллекция, которая умеет сохраняться на диск.

Некоторое время назад я её сам рекомендовал вместе с cqengine упомянутым. Однако...

К сожалению недавно я решил в неё немного поконтрибутить...
Робяты, там такой гуанокод :)
Кроме того при попытке запустить тестовый пример с ней она стала валиться с NPE - хотя года два назад работала.

Я нашёл баг с NPE (там тупо работа с файловой системой не кроссплатформенная была), зафиксил - и это был единственный мой контрибушн в этот проект. Контрибутить дальше мне туда расхотелось :D

И кстати, это не просто "коллекция которая умеет сохраняться на диск", как и Berkeley DB она умеет ещё всякие первичные и вторичные индексы и много других странных штук в которых на самом деле разобраться может быть не проще чем в SQL.

Если просто коллекцию нужно сохранять - то её можно банально в json-файл сериализовать. Заодно и редактировать можно если что.

Quote:

да, это небольшое веб приложение на спринге. спасибо за наводку вам. это яп сказал идеально просто что можно будет избавиться от базы вовсе.

Для небольших веб-приложений я сам H2 юзал вполне. С одной стороны базу можно вместе с приложением запускать - с другой нет проблем с расширением функционала, и если припрёт то совершенно легко переключиться на более мощную базу.

Необязательно юзать JPA для неё, можно spring-jdbc легко обходиться. Вот у меня есть пример приложеньки со спрингом и H2, общение с базой там в пакете dao (удивительно, гы):

обратите внимание, именно ветка demoshop

www.codeabbey.com - programming problems for novice coders (+ certificates)
Изменен:19 окт 2014 06:39
 
 
Сообщения:7
Советую почитать, та подробно описывается как в java использовать базы данных.http://www.quizful.net/post/using-jdbc
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет