«Сурогатные ключи» vs «Естественные» — это давнишний и бесполезный спор.
Есть удачные и неудачные приеменения и того и другого.
В каждом конкретном случае надо делать осознанный выбор.
А этот пост о вполне конкретной технической детали фреймворка. К чему тут спор о ключах не понятно.
Если у вас естественные ключи, то фремворк все рано должен понять, что делать — обновить запись или создать новую.
Об этом и пост.
Генерация Id «на стороне java» требует дополнительное время — это очевидный факт и доказательств не требуется. Однако бывают случаи, когда это подходящее решение.
Вопрос в другом. Какое это имеет отношение к теме поста?
Вы говорите, что можно вычислять ID в приложении, но тогда сразу ставится крест на многоузловой эксплуатации приложения, либо множество узлов не дают уникальности ID.
С этой задачей отлично справляется генерация UUID.
Можете масштабировать на столько услов на сколько надо.
Сурогатные ключи или не сурогатные — это старая дискуссия в мире реляционных БД. Когда-то они полезны, когда-то нет.
Обсуждать идеяю сурогатов без контекста проблемы весьма непросто.
Для процессинга финансовых операций описанный подход не очень подходит.
Т.к. при авторизации транзакции вам надо точно и быстро узнавать остаток на счете.
Фактически надо по индексу читать строку в таблице.
Вы правильно знаете. Карта закрывается при обращении клиента.
А карточный счет примерно через 40 дней, как раз на случай приход клиринга (требований оплаты) без предварительного холда (резервирования денег).
так и есть,
нет гарантий, что даже с синхронным логированием последние сообщения сохранятся.
Асинхронное логирование, конечно, вероятность потерять повышает.
Асинхронность — это одна из опций логирования, и она не для всего подходит.
да, вы правы.
Спасибо, что заметили и сообщили :)
И да, асинхронный логгер действительно может потерять данные. Все, что лежит в очереди, может пропасть.
Подвов в методике проведения микробенчмарков.
Что реально даст подобное измерение на цикле в 25 итераций?
Посмотрите доклады Шепелева про методики оценки производительности кода.
При этом UUID можно генерировать не рандомный, а с привязкой ко времени, тогда возможность сортировки сохранится.
Есть удачные и неудачные приеменения и того и другого.
В каждом конкретном случае надо делать осознанный выбор.
А этот пост о вполне конкретной технической детали фреймворка. К чему тут спор о ключах не понятно.
Если у вас естественные ключи, то фремворк все рано должен понять, что делать — обновить запись или создать новую.
Об этом и пост.
Вопрос в другом. Какое это имеет отношение к теме поста?
С этой задачей отлично справляется генерация UUID.
Можете масштабировать на столько услов на сколько надо.
Обсуждать идеяю сурогатов без контекста проблемы весьма непросто.
Один из вариантов решения — constraints на стороне базы.
т.е. две одинаковые записи, но с разным id все равно будут одинаковыми.
в этом проблема?
Чтобы такого не было, достаточно генерировать id на стороне базы данных.
Или можно, например, GUID создавать в java-коде.
ссылка в конце поста.
Spring Data основан на Hibernate, а Spring Data Jdbc работает поверх jdbc.
За счет этого проще и более предсказуем.
Кластеризация пока мне не нужна, про схему не задумывался.
Т.к. при авторизации транзакции вам надо точно и быстро узнавать остаток на счете.
Фактически надо по индексу читать строку в таблице.
А карточный счет примерно через 40 дней, как раз на случай приход клиринга (требований оплаты) без предварительного холда (резервирования денег).
нет гарантий, что даже с синхронным логированием последние сообщения сохранятся.
Асинхронное логирование, конечно, вероятность потерять повышает.
Асинхронность — это одна из опций логирования, и она не для всего подходит.
Спасибо, что заметили и сообщили :)
И да, асинхронный логгер действительно может потерять данные. Все, что лежит в очереди, может пропасть.
Что реально даст подобное измерение на цикле в 25 итераций?
Посмотрите доклады Шепелева про методики оценки производительности кода.