db4o против sql, sqlite в java сервере

Question

Я создаю веб-сервер Java для хранения строк JSON с данными о местоположении (широта, долгота и время) Интересно, есть ли какие-либо преимущества (производительность, масштабируемость, обслуживание и т. Д.) Для использования db4o, который кажется более простым в использовании в java вместо sql, sqlite. Кроме того, каковы различия между Hibernate и db4o;

Answer 1

DB4O работает совершенно иначе, чем традиционная СУБД на основе SQL.

Вам необходимо лучше определить свои требования.Например, DB4O может относительно легко следить за графиками - конкретная структура, представляющая JSON, может очень хорошо вписаться в эту область.С другой стороны, DB4O абсолютно не пригоден для запросов (особенно отчетов и агрегирования), которые не вписываются в ранее определенный график.

Редактировать: Выше приведено моего опыта с DB4O (я использую DB40 в сочетании с SQL RDMB) - я (и буду) все еще использовать DB4O, потому что я думаю, что у него много достоинств.Тем не менее, я чувствую, что он гораздо больше подходит для конкретных приложений , которые должны быть четко определены ( молоток с раздвоенным хвостом ), в то время как традиционные SQL RDMB ( кувалда ) имеют многоболее широкие возможности и могут относительно хорошо справляться даже с плохими или плоскими схемами, и, за исключением соображений производительности, могут быть заменены на "нарезку и нарезание кубиками".Оба являются инструментами с перекрытием, но различного назначения - можно забить гвоздь кувалдой (это может быть не красиво), но хорошо выглядеть, пытаясь сбить цементную стену молотком с раздвоенным хвостом.

Answer 2

«o» в «db4o» обозначает «объекты».Это объектная база данных, поэтому, если ваша проблема не является «истинной» объектно-ориентированной, это может быть не для вас.Объектные базы данных действительно работают очень хорошо для задач с глубокими объектными графами, длинными ссылочными цепочками (например, CAD или геометрические данные конечных элементов).

Прочитайте их справочное руководство .

Что касается хранения описанных вами строк JSON, я думаю, что любая технология персистентности подойдет.Убедитесь, что знаете, что делаете, когда отказываетесь от SQL.Я не спорю, что SQL и реляционные базы данных - единственный ответ.Я просто предостерегаю вас от предположения, что у вас будут проблемы с производительностью, масштабируемостью и возможностями в целом, прежде чем у вас будут какие-то данные, чтобы доказать это.

Answer 3

Если вы можете отобразить свои строки JSON на общеизвестные типы объектов (класс, определенный на стороне сервера с теми же полями, и преобразовать / отобразить из JSON в эти общеизвестные типы при получении запроса), тогда db4o будет отлично работать для вас. Но так будет и ряд других решений. Существует также ряд баз данных NoSQL со специализированной поддержкой объектов и запросов JSON. (например, Mongo DB или Couch DB), но (как уже говорилось в duffymo), когда вы выбираете базу данных NoSQL, вам обычно приходится отказываться от чего-то другого, например от транзакционности, возможности компоновки (возможность запрашивать столбцы 1 и 3 и присоединяться к другому случайная таблица) или другие функции, которые большинство людей пришло к выводу из базы данных. (подобно Hibernate) db4o, как и многие другие в этом отношении, db4o имеет дело только с хорошо известными типами объектов и графиками. Это не позволяет вам вывести ваши объекты в любую другую форму, но они были в момент вставки. Но db4o позволяет вам запрашивать любое поле любого объекта. (некоторые базы данных NoSQL требуют предварительно определить, какие / какие поля являются запрашиваемыми значениями)