популяция данных семян для конкретного приложения

Question

Конверт: JBoss, (h2, MySQl, postgres), JPA, Hibernate 3.3.x

@Id
@GeneratedValue(strategy = IDENTITY)
private Integer key;

1. В настоящее время наши первичные ключи создаются с использованием приведенной выше аннотации. Мы рассчитываем поддержать большое количество пользователей (~ миллион пользователей), какой ключ следует использовать. Должно ли это быть Integer или Long или я должен использовать неподписанные версии вышеуказанных объявлений.

2. У нас есть приложение j2ee, которое необходимо заполнить некоторыми начальными данными при установке. При покупке клиент создает свои собственные данные поверх приложения. Мы просто хотим убедиться, что места для отправки, изменения или добавления данных для будущих выпусков достаточно. Что было бы лучшим механизмом для поддержки этого, мы рассмотрели запуск всех идентификаторов таблиц с определенного идентификатора (скажем, 1000), но это требует изменения генерации первичного ключа, чтобы иметь генераторы на основе таблиц или последовательностей, и у нас есть около 100 таблиц. Мы не уверены, что это правильная стратегия для этого.

Если мы используем подход со знаком для целых чисел со знаком, имеет ли смысл иметь начальные данные как все, начиная с 0 и ниже (т. Е. -Ve чисел), так что все специфичные для клиента данные будут доступны с 0 и выше (т.е. + ve номера)

Answer 1

В настоящее время наши первичные ключи создаются с использованием вышеуказанной аннотации.Мы рассчитываем поддержать большое количество пользователей (~ миллион пользователей), какой ключ следует использовать.Должно ли это быть Integer или Long, или я должен использовать неподписанные версии вышеуказанных объявлений

Из Примитивных типов данных из учебников Java:

int: Тип данных int представляет собой 32-разрядное целое число с двоичным знаком со знаком 2.Он имеет минимальное значение -2 147 483 648 и максимальное значение 2 147 483 647 (включительно).Для целочисленных значений этот тип данных обычно является выбором по умолчанию, если только нет причины (как указано выше) выбрать что-то еще.Этот тип данных, скорее всего, будет достаточно большим для чисел, которые будет использовать ваша программа, но если вам нужен более широкий диапазон значений, используйте long.

Вам решать, безопасно ли это:)

(...) Мы просто хотим убедиться, что места достаточно для отправки, изменения или добавления.данные для будущих выпусков.Что было бы лучшим механизмом для поддержки этого

Я бы проверил это с упомянутой базой данных, но использование отрицательных идентификаторов для ваших начальных данных кажется более безопасным решением (нет возможных коллизий).Если это не сработает (я думаю, что должно), то я считаю, что стратегия TABLE будет самым переносимым решением.