Логика: База данных или Приложение/2 (ограничительная проверка)
Я думаю, что вы также можете использовать том EBS, а затем смонтировать его, если экземпляр остановится, ваш том нужно будет снова смонтировать. Файловая система S3 предоставит вам такую же функциональность. Я бы не стал хранить 100 ГБ данных в S3 и использовать S3 SDK, так как запросы GET для многих небольших файлов могут быть очень дорогими.
7 ответов
Во-первых, у Вас должны быть первичный ключ или ограничение на уникальность данных на базу данных для осуществления этой уникальности правильно - никакой вопрос.
Учитывая, что ограничение существует, какой путь необходимо кодировать в приложении? Мое предпочтение состояло бы в том, чтобы попробовать вставку и поймать исключения. Поскольку, по-видимому, большинство, за которым будут следовать вставки, только некоторые будут сбои как дубликаты (это - то, что подразумевает "исключение"!): это неэффективно для выполнения, существует проверка перед каждой вставкой, когда база данных будет выполнением ее собственного ограничения, проверяющего так или иначе.
Кроме того, это теоретически возможно для, существует проверка для несправедливости так или иначе - если кому-то еще удается фиксировать запись с тем же значением ключа в маленьком интервале между Вашим, существует проверка и вставка. Затем если Вы не захватите исключение базы данных, то Вы будете верить вставке, за которой следуют, когда на самом деле это не сделало.
Вы проверяете, что объект существует только в коде приложения и затем когда-то удовлетворил это, он не делает, беспечно сохраняет объект. Но другой параллельный клиент мог бы вставить их собственный объект в момент между Вашими двумя строками кода. Таким образом, Вы получили бы Дублирующееся исключение так или иначе, только на этот раз Вы не ловите его.
Необходимо сделать сохранение () и поймать исключение. Иначе у Вас есть состояние состязания с другими параллельными клиентами, работающими над той же базой данных.
Необходимо поймать исключение базы данных, если Вы не можете гарантировать, что Ваше приложение является единственным, которое когда-либо вставляет строки (и когда-либо будет вставлять строки) в Вашу базу данных.
Править: Я могу иметь, неправильно понимают вопрос, но я все еще утверждал бы, что опция B (HibernateSessionFactory бросает ConstraintException от базы данных) является более оптимальным вариантом. Всегда существует маленький шанс, что другое приложение могло вставить что-то в щепку времени между Вашей проверкой и фактическим вызовом функции. Кроме того, единственный способ проверить на простофилю состоит в том, чтобы выполнить дополнительный запрос, который является просто бесполезным дренажом на производительности.
Мое исходное понимание вопроса было то, что в опции A проверка простофили будет выполнена внутренне (т.е. только при помощи структур данных, которые программа уже создала, и без запроса до ВСТАВКИ). Мой исходный ответ был в ответ на этот метод.
В целом я стараюсь не кодировать, который полагается на ошибки, бросаемые, потому что я сделал что-то не так. Иногда, тем не менее, это - все, что можно сделать. В Вашей ситуации я думаю, что необходимо проверить сначала.
Это повредится (позволяющий дублирующиеся записи), если ограничение будет отброшено по некоторым причинам (обычно работы по техническому обслуживанию, где DBA забыл повторно включать его). Необходимо проверить на эту ситуацию в рамках приложения.
Однако это - хорошее проектирование баз данных, чтобы иметь базу данных, осуществляют ограничение (как Вы вполне справедливо указали), поскольку другие могут также использовать базу данных. Поскольку обобщение лучше предполагать, что приложения и базы данных, живые в отношениях M:M - это будет иметь место почти все время.
Исключения, выданные, в спящем режиме (или любой компонент ORM) имеют тенденцию быть твердым интерпретировать.
Если исключение имеет достаточно информации, что можно произвести сообщение об ошибке, которое на самом деле помогает пользователю, то просто ловят исключение, анализируют его и идут дальше.
Если исключение не имеет достаточной информации, то необходимо проверить на состояние ошибки и произвести полезное сообщение об ошибке для пользователя, что они делают что-то не так.
Вопросом является один из, "насколько непрозрачный исключение"? Некоторые довольно непрозрачны. У других есть достаточно, что можно проанализировать строку сообщения и выяснить, что сказать пользователю.
Однажды будьте в спящем режиме, выдает исключение от сессии, необходимо отбросить сессию (см. раздел 11.2.3). Так, если необходимо проверить на, копирует, и продолжите использовать ту же сессию затем, у Вас нет выбора, кроме как проверять сначала в приложение.
Также существует возможность с кодом в 1-м отрывке, что другой процесс мог вставить запись, которая заставит дублирующееся исключение быть брошенным между временем, которое Вы проверяете на дублирующуюся запись и время, это на самом деле вставляется.