Просьба о мнениях: Одна последовательность для всех таблиц
Проверьте этот поток для Цветных опций темы для Visual Studio https://, stackoverflow.com/questions/141371/which-visual-studio-color-theme
И консоли являются моим любимым шрифтом
5 ответов
В зависимости от того, как последовательности реализованы в базе данных, всегда попадание в одну и ту же последовательность может быть лучше или хуже. Когда только несколько или только один поток запрашивают новые значения, проблем с блокировкой не возникает. Но плохая реализация может вызвать перегрузку.
Другая проблема - откат транзакций: последовательности не откатываются (потому что кто-то уже мог запросить более высокое значение), поэтому у вас могут быть большие пробелы, которые съедят ваше числовое пространство намного быстрее, чем вы могли ожидать. OTOH, потребуется некоторое время, чтобы съесть 2 или 4 миллиарда идентификаторов (если вы "только" используете 32-битные (подписанные) целые числа), поэтому на практике это редко является проблемой.
Наконец, вы не можете легко сбросить последовательность если нужно. Но если вам нужна последовательность перезапуска (скажем, количество записей с полуночи), вы можете указать Hibernate создать / использовать вторую последовательность.
Основным преимуществом является то, что вы можете однозначно идентифицировать объекты в любом месте БД только по идентификатору. Это означает, что вы можете значительно сократить объем информации журнала, который вы пишете в производственной системе, и все равно что-то найти, если у вас есть только идентификатор.
Могут возникнуть проблемы с производительностью, когда весь код получает значения из одной последовательности - см. этот поток Ask Tom .
Использование одной последовательности имеет несколько недостатков: -
- снижение параллелизма. Выдача следующего значения последовательности включает синхронизацию.
Я предпочитаю иметь одну последовательность для каждой таблицы. Это происходит из одного общего наблюдения: некоторые таблицы («главные таблицы») имеют относительно небольшое количество строк и должны храниться «вечно». Например, таблица клиентов в ERP.
В других таблицах («таблицах транзакций») много строк создается постоянно, но через некоторое время эти строки могут быть заархивированы (или просто удалены). Наиболее ярким примером является таблица трассировки, используемая для отладки; он может увеличиваться на сотни строк в секунду, но каждая строка устареет через несколько дней.
Маленькие идентификаторы в главных таблицах упрощают работу непосредственно с базой данных, например, для целей отладки.
select * from orders where customerid=415
vs
select * from orders where customerid=89461836571
] Но это лишь мелочь. Более серьезная проблема - это езда на велосипеде. Если вы используете одну последовательность для всех таблиц, вы просто не можете позволить ей перезапустить. Используя одну последовательность для каждой таблицы, вы можете перезапустить последовательности для таблиц транзакций, когда вы заархивировали или удалили старые данные. В главных таблицах почти никогда не бывает такой проблемы, поскольку они растут намного медленнее.
Я не вижу особой пользы в том, чтобы иметь только одну последовательность для всех таблиц. Приведенные до сих пор аргументы меня не убеждают.
Конечно, у однопоследовательного варианта есть свои плюсы и минусы. -последовательный подход к таблице.Лично я считаю, что возможность назначать действительно уникальный идентификатор строке, делая каждый столбец идентификатора uuid, является достаточным преимуществом, чтобы перевесить любые недостатки. Как лаконично пишет Аарон Д.:
вы можете однозначно идентифицировать объекты в любом месте БД только по идентификатору
. И для большинства приложений из-за того, как Hibernate3 группирует операторы IMPORT, это не будет узким местом производительности, если только массовые количество записей соперничает за один и тот же ресурс базы данных (SELECT hibernate_sequence.nextval FROM dual).
Кроме того, это отображение последовательности не поддерживается в последней версии (1.2) Grails. Хотя он поддерживался в Grails 1.1 (!). Теперь для обходного пути требуется создание подкласса одного из диалектных классов Hibernate.
Для тех, кто использует Grails / GORM, обратите внимание на эту запись JIRA: