|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
Petro123, авторсмешно. А маппинг аннотациями как? А сохранение один ко многим? Смешно. На самом деле не смешно. А так да, это прийдется пописать ручками. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2019, 15:25 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
mr_virtusтак да, это прийдется пописать ручками.пишите ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2019, 15:43 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
mr_virtusTsyklop, автор Хотя где шансы что запросы с jdbc будут оптимальными? Я думал хибер внутри юзает jdbc. Но могу ошибаться. Да. Хибер работает "via JDBC". Это написано на титульной страничке hibernate.org/orm/ ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2019, 15:44 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
mayton, авторДа. Хибер работает "via JDBC". Это написано на титульной страничке hibernate.org/orm/ Не только там, открой для себя гугл. Что сказать-то хотел? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2019, 15:58 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
mr_virtusmayton, авторДа. Хибер работает "via JDBC". Это написано на титульной страничке hibernate.org/orm/ Не только там, открой для себя гугл. Что сказать-то хотел? (пожимая плечами) Какая странная реакция. Ну как будет угодно. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2019, 15:59 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
mayton, Нормальная реакция на твой сарказм в предыдущем ответе. Если его там не было, то ок - был неправ. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2019, 16:01 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
MolasarПод типовые запросы на запись - хранимые процедуры.ну хранимки могут и не только типрвые запросы, они много больше могут и Petro123Быстрее будет. Molasar+ Hibernate. вот только от хибера избавиться надо ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2019, 20:47 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
вадя, тебе повезло. В биллинге хибер не нужен. А ты разве не знал, что хибер для CRUD. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2019, 22:43 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
Petro123вадя, тебе повезло. В биллинге хибер не нужен. А ты разве не знал, что хибер для CRUD. Я планирую делать 2 реализации на Хибере и JDBC. Потом буду тестить под нагрузкой оба варианта. О результатах сообщу. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2019, 09:11 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
Molasar, я бы начал тестировать ваше железо+базу на момент выдержки нагрузки и нужной вам производительности. Может так случится, что после тестирования хибер сам собой отпадет... ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2019, 09:32 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
Molasar, Да. Присоединяюсь ко всем - тестируйте. А оба варианта это скилы. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2019, 09:38 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
MolasarВсем привет! Есть класс Event: Код: java 1. 2. 3. 4. 5. 6. 7.
Необходимо сохранять объекты класса 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. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2019, 10:33 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
maytonИ поле id, я-бы сделал не враппером а примитивом. Всё таки id предполагает что это всегда NOT NULLэто оно в бд not null, а до базы это вообще-то признак нового объекта ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2019, 10:52 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
maytonMolasarВсем привет! Есть класс Event: Код: java 1. 2. 3. 4. 5. 6. 7.
Необходимо сохранять объекты класса 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 по этой причине тоже отпадает. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2019, 10:57 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
1) Какая предполагается нагрузка? Количество сообщений в день, количество запросов на выборку? 2) Если нагрузка небольшая то в принципе пофиг на чем писать, что на хибере что ждбс что бд что nosql, если же нагрузка большая, то имеет смысл подумать о чем-то нереляционном, в том числе elasticsearch. Но что-то мне подсказывает что там нагрузка небольшая, так что.. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2019, 11:16 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
Molasar, Ты запиши логи. А потом отдельный процесс их разгребет. Биллинг это вроде отдельный подход и технологии. И даже область знаний) Как в OLAP/OLTP ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2019, 12:09 |
|
Запись Properties в БД
|
|||
---|---|---|---|
#18+
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 по этой причине тоже отпадает. Так ты сам спросил - сам и ответил? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2019, 13:45 |
|
|
start [/forum/topic.php?fid=59&gotonew=1&tid=2121286]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
151ms |
get topic data: |
11ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 282ms |
0 / 0 |