Что, если 2^32 просто недостаточно?
Исходя из того, что вы упомянули Xamarin , я думаю, вы должны работать над мобильным приложением.
В основном у вас есть четыре варианта, если вы хотите построить его с помощью AEM:
- Использовать возможности одностраничного приложения (SPA) AEM (требуется AEM 6.4):
- Используйте (унаследованные) возможности PhoneGap AEM .
- Используйте готовые API Sling для предоставления необходимых данных и использования их в приложении Xamarin.
- Напишите собственный API (веб-сервис) и используйте его в своем приложении Xamarin.
Я настоятельно рекомендую взглянуть на поддержку SPA или возможности PhoneGap, если вы не используете AEM 6.4.
Работа с Sling API или создание собственного API - не лучший вариант, если вы новичок в AEM. Существует так много подводных камней, которые вызовут у вас много головной боли, и вы рискуете создать неразрешимый беспорядок в проекте AEM.
9 ответов
Вы могли использовать BIGINT для первичного ключа. Это - 64-разрядное число по умолчанию.
Редактирование № 2: По-видимому, то, что я сказал прежде о варьировании длины байта BIGINT, было неправильно. BIGINT фиксируется в 8-байтовом пределе.
Не делайте Вы думаете a BIGINT UNSIGNED было бы достаточно? Это - диапазон 0 - 18.446.744.073.709.551.615, или один год с 50.539.024.859.478.223 записями в день (365 d/y), 2 105 792 702 478 259 записей в час, 35.096.545.041.304 записи в минуту или 584.942.417.355 в секунду.
С принятыми 600 записями в секунду (без любых чтений) Вы могли записать записям 974 904 028 года на полной скорости записи. Это должно быть достаточно.
Если у Вас есть так много данных, что Вы встречаетесь с этой проблемой, то выбор первичного ключа является, вероятно, наименьшим количеством Ваших проблем.
При использовании механизма InnoDB может быть полезно для производительности выбрать первичный ключ, на котором Вы будете часто искать (особенно, куда поиски возвращают много строк), поскольку это кластеризирует первичный ключ, который делает сканирования диапазона лучше.
Просто используйте 128-разрядные ключи. Нет никакой потребности в неограниченном количестве ключей, так как Вы очень быстро позволяете больше строк, чем количество атомов во вселенной. (где-нибудь приблизительно 256 битов).
Не используйте первичный ключ автопостепенного увеличения - используют GUID или подобный - из статьи Wikipedia:
В то время как каждый генерировал GUID, как, гарантируют, не будет уникален, общее количество уникальных ключей (2^128 или 3.4×10^38) является столь большим, что вероятность того же числа, сгенерированного дважды, является бесконечно мало маленькой. Например, рассмотрите заметную вселенную, которая содержит о 5×1022 звезды; каждая звезда могла затем иметь 6.8×1015 универсально уникальные GUID.
Я запустил бы путем перемещения в BIGINT для 2^64. GUID были бы другой опцией, но необходимо сохранить их сами в "некоторой форме"
Когда Вы добавляете другой столбец к своему ключу, Вы эффективно удваиваете количество индексных сканирований, которые необходимо будет выполнить (хотя на намного меньшем индексе для второго столбца).
Как указано ранее, Вашим лучшим выбором для ОБШИРНЫХ наборов данных является любой GUID (если Ваш RDBMS поддерживает его исходно), или varchar (16).
Хорошая часть об использовании varchar / varbinary - то, что Вы могли автоматически развернуть столбец в будущем в случае необходимости. И плохая часть - то, что varchar / varbinary является плохо работающим ключом, по сравнению с целым числом.
Я не уверен, как генерировать их автоматически в MySQL, и затем, они не обязательно были бы последовательны, но я вполне уверен, что Вы могли использовать GUID и не иметь для волнения по поводу них заполнения.
Вы могли также использовать chars/varchars для своих столбцов ключа и использовать GUID для Ваших ключей. Я не знаю, подверглось ли это потере производительности по сравнению с целочисленными первичными ключами все же.