powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Java [игнор отключен] [закрыт для гостей] / Запись Properties в БД
17 сообщений из 42, страница 2 из 2
Запись Properties в БД
    #39819383
mr_virtus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,

авторсмешно.
А маппинг аннотациями как?
А сохранение один ко многим?
Смешно.

На самом деле не смешно. А так да, это прийдется пописать ручками.
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819398
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mr_virtusтак да, это прийдется пописать ручками.пишите
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819400
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mr_virtusTsyklop,

автор Хотя где шансы что запросы с jdbc будут оптимальными?

Я думал хибер внутри юзает jdbc. Но могу ошибаться.
Да. Хибер работает "via JDBC". Это написано на титульной страничке hibernate.org/orm/
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819408
mr_virtus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

авторДа. Хибер работает "via JDBC". Это написано на титульной страничке hibernate.org/orm/

Не только там, открой для себя гугл. Что сказать-то хотел?
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819409
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mr_virtusmayton,

авторДа. Хибер работает "via JDBC". Это написано на титульной страничке hibernate.org/orm/

Не только там, открой для себя гугл. Что сказать-то хотел?
(пожимая плечами)

Какая странная реакция. Ну как будет угодно.
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819410
mr_virtus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

Нормальная реакция на твой сарказм в предыдущем ответе. Если его там не было, то ок - был неправ.
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819498
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolasarПод типовые запросы на запись - хранимые процедуры.ну хранимки могут и не только типрвые запросы, они много больше могут
и
Petro123Быстрее будет.
Molasar+ Hibernate.
вот только от хибера избавиться надо
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819525
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя,
тебе повезло. В биллинге хибер не нужен.
А ты разве не знал, что хибер для CRUD.
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819618
Molasar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123вадя,
тебе повезло. В биллинге хибер не нужен.
А ты разве не знал, что хибер для CRUD.
Я планирую делать 2 реализации на Хибере и JDBC. Потом буду тестить под нагрузкой оба варианта. О результатах сообщу.
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819629
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molasar, я бы начал тестировать ваше железо+базу на момент выдержки нагрузки и нужной вам производительности. Может так случится, что после тестирования хибер сам собой отпадет...
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819634
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molasar,
Да. Присоединяюсь ко всем - тестируйте. А оба варианта это скилы.
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819662
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MolasarВсем привет!

Есть класс Event:
Код: java
1.
2.
3.
4.
5.
6.
7.
public class Event implements Serializable {
   
    private Long id;
    private Properties properties;
    ...

}


Необходимо сохранять объекты класса Event в БД через Spring + Hibernate.

В каком виде лучше хранить данную сущность:?
1. Одна таблица Event, но тогда поле properties будет как BLOB.
2. Сделать две таблицы, отношение один ко многим. В 1-ой таблице id, во 2-ой id, key, value. Соответственно сначала добавляем запись в 1-ю, получаем id и записываем соответствующую запись в 2-ю таблицу.
Способ хранения может быть любым. В данном случае (1) и (2) правильные.

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

Вариант 1: Вся сущность event сериализируется в JSON и так и хранится в одной табличке. Как varchar.
Этот вариант хорош когда модификаций не будет. Место экономится. Или BLOB если varchar уже закончился
по размеру.

Вариант 2: Сущности properties (key,value) хранятся в отдельной табличке оптимизированной под частые изменения.
При этом получаем скорость обновления пропертей. Если конечно это необходимо. Расход места будет чуть больше.

И прочие варианты. Смешанные. Например если properties содержит в себе такие-же объекты properties (дерево) то
можно просто делать 1 табличку дерево где есть родительские и дочерние записи. Вобщем вариантов на самом деле еще
больше.

И поле id, я-бы сделал не враппером а примитивом. Всё таки id предполагает что это всегда NOT NULL.
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819674
chpasha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonИ поле id, я-бы сделал не враппером а примитивом. Всё таки id предполагает что это всегда NOT NULLэто оно в бд not null, а до базы это вообще-то признак нового объекта
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819675
Molasar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonMolasarВсем привет!

Есть класс Event:
Код: java
1.
2.
3.
4.
5.
6.
7.
public class Event implements Serializable {
   
    private Long id;
    private Properties properties;
    ...

}


Необходимо сохранять объекты класса Event в БД через Spring + Hibernate.

В каком виде лучше хранить данную сущность:?
1. Одна таблица Event, но тогда поле properties будет как BLOB.
2. Сделать две таблицы, отношение один ко многим. В 1-ой таблице id, во 2-ой id, key, value. Соответственно сначала добавляем запись в 1-ю, получаем id и записываем соответствующую запись в 2-ю таблицу.
Способ хранения может быть любым. В данном случае (1) и (2) правильные.

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

Вариант 1: Вся сущность event сериализируется в JSON и так и хранится в одной табличке. Как varchar.
Этот вариант хорош когда модификаций не будет. Место экономится. Или BLOB если varchar уже закончился
по размеру.

Вариант 2: Сущности properties (key,value) хранятся в отдельной табличке оптимизированной под частые изменения.
При этом получаем скорость обновления пропертей. Если конечно это необходимо. Расход места будет чуть больше.

И прочие варианты. Смешанные. Например если properties содержит в себе такие-же объекты properties (дерево) то
можно просто делать 1 табличку дерево где есть родительские и дочерние записи. Вобщем вариантов на самом деле еще
больше.

И поле id, я-бы сделал не враппером а примитивом. Всё таки id предполагает что это всегда NOT NULL.
В данном случае данные будут только добавляться в таблицу. Это что-то типа лога, журнала событий. В дальнейшем необходимо будет читать таблицу, делать выборку, поэтому вариант с одной таблицей и BLOB не подходит, т.к. для того чтобы что-то выбрать необходимо будет выкачивать всю базу, превращать BLOB в HashMap. JSON как varchar по этой причине тоже отпадает.
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819695
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1) Какая предполагается нагрузка? Количество сообщений в день, количество запросов на выборку?
2) Если нагрузка небольшая то в принципе пофиг на чем писать, что на хибере что ждбс что бд что nosql, если же нагрузка большая, то имеет смысл подумать о чем-то нереляционном, в том числе elasticsearch.

Но что-то мне подсказывает что там нагрузка небольшая, так что..
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819742
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molasar,
Ты запиши логи. А потом отдельный процесс их разгребет.
Биллинг это вроде отдельный подход и технологии. И даже область знаний)
Как в OLAP/OLTP
...
Рейтинг: 0 / 0
Запись Properties в БД
    #39819822
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Molasarmaytonпропущено...

Способ хранения может быть любым. В данном случае (1) и (2) правильные.

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

Вариант 1: Вся сущность event сериализируется в JSON и так и хранится в одной табличке. Как varchar.
Этот вариант хорош когда модификаций не будет. Место экономится. Или BLOB если varchar уже закончился
по размеру.

Вариант 2: Сущности properties (key,value) хранятся в отдельной табличке оптимизированной под частые изменения.
При этом получаем скорость обновления пропертей. Если конечно это необходимо. Расход места будет чуть больше.

И прочие варианты. Смешанные. Например если properties содержит в себе такие-же объекты properties (дерево) то
можно просто делать 1 табличку дерево где есть родительские и дочерние записи. Вобщем вариантов на самом деле еще
больше.

И поле id, я-бы сделал не враппером а примитивом. Всё таки id предполагает что это всегда NOT NULL.
В данном случае данные будут только добавляться в таблицу. Это что-то типа лога, журнала событий. В дальнейшем необходимо будет читать таблицу, делать выборку, поэтому вариант с одной таблицей и BLOB не подходит, т.к. для того чтобы что-то выбрать необходимо будет выкачивать всю базу, превращать BLOB в HashMap. JSON как varchar по этой причине тоже отпадает.
Так ты сам спросил - сам и ответил?
...
Рейтинг: 0 / 0
17 сообщений из 42, страница 2 из 2
Форумы / Java [игнор отключен] [закрыт для гостей] / Запись Properties в БД
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]