Максимальное значение столбца Identity в DBS SQLite
Попробуйте:
document.getElementById('elmtid').onclick = anotherFunction;
с:
function anotherFunction(evt){
evt = $.event.fix(evt || window.event);//Note need for cross-browser reference to the native event
...
}
3 ответа
Я сомневаюсь, что кто-нибудь знает наверняка, потому что если бы вставлялся миллион строк в секунду , потребуется около 292 471 год, чтобы достичь точки полного риска - а базы данных существуют уже крошечную долю этого времени (на самом деле, как и Homo Sapiens; -).
Я не могу говорить о какой-либо конкретной логике реализации DB2, но описываемое вами "циклическое" поведение является стандартным для чисел, которые реализуют подпись через дополнение до двух .
Что же касается того, что на самом деле произойдет, то вопрос о том, как база данных будет обрабатывать это, полностью неизвестен. Проблема возникает в момент фактического СОЗДАНИЯ идентификатора, который слишком велик для поля, поскольку маловероятно, что движок внутренне использует тип данных более 64 бит. В этот момент можно только догадываться ... внутренний язык, используемый для разработки движка, может вырваться, число могло незаметно обернуться вокруг и просто вызвать нарушение первичного ключа (при условии, что существует конфликтующий идентификатор), мир может прийти к конец из-за вашего переполнения и т. д.
Но прагматично, Алекс прав. Теоретический предел числа строк, участвующих здесь (при условии, что это один-ID для каждой строки, а не какое-либо личность мошенника вставки махинаций) будет в основном делает ситуацию спорным, так как к тому времени, что вы, вероятно, можете указать, что многие строки в даже колоссальную скорость вставки мы все равно умрем, так что это не имеет значения :)
IDENTITY на самом деле не является правильным способом автоматического увеличения в SQLite. Это потребует от вас увеличения уровня приложения. В оболочке SQLite попробуйте:
create table bar (id IDENTITY, name VARCHAR);
insert into bar (name) values ("John");
select * from bar;
Вы увидите, что id просто равен нулю. SQLite не придает особого значения IDENTITY, поэтому это обычный (нетипизированный) столбец.
С другой стороны, если вы это сделаете:
create table baz (id INTEGER PRIMARY KEY, name VARCHAR);
insert into baz (name) values ("John");
select * from baz;
, он будет равен 1, как я думаю, вы ожидаете.
Примечание. что существует также ЦЕЛОЕ АВТОНОМЕРЫ ПЕРВИЧНОГО КЛЮЧА. Основное отличие состоит в том, что AUTOINCREMENT гарантирует, что ключи никогда не будут использоваться повторно. Поэтому, если вы удалите John, 1 никогда не будет повторно использоваться в качестве идентификатора. В любом случае, если вы используете PRIMARY KEY (с необязательным AUTOINCREMENT) и исчерпываете идентификаторы, предполагается, что SQLite завершится ошибкой с SQLITE_FULL, а не циклически.
Используя IDENTITY, вы действительно открываете (вероятно, несущественную) вероятность того, что ваше приложение будет неправильно завершено, если база данных когда-либо была заполнена. Это вполне возможно, потому что столбцы IDENTITY в SQLite могут содержать любое значение (включая отрицательные целые числа). Снова попробуйте:
insert into bar VALUES ("What the hell", "Bill");
insert into bar VALUES (-9, "Mary");
Оба они полностью верны. Они были бы действительны и для баз. Однако , с помощью baz вы можете избежать ручного указания id. Таким образом, в столбце идентификаторов никогда не будет мусора.