Как насчет этого?
INSERT OR IGNORE INTO EVENTTYPE (EventTypeName) VALUES 'ANI Received'
(Непротестированный, поскольку у меня нет SQLite... однако , эта ссылка является довольно описательной.)
Кроме того, это должно также работать:
INSERT INTO EVENTTYPE (EventTypeName)
SELECT 'ANI Received'
WHERE NOT EXISTS (SELECT 1 FROM EVENTTYPE WHERE EventTypeName = 'ANI Received');
Предполагая, что вы используете по крайней мере jQuery 1.3 (то есть с добавлением Sizzle), наблюдаемая производительность связана с изменением, при котором выполняется обход DOM. Из здесь :
До jQuery 1.2.6 включительно селектор двигателя работал в режиме «сверху вниз» (или «слева направо») способом. jQuery 1.3.x (то есть Sizzle , который встраивает jQuery) представил «снизу вверх» (или "справа налево") подход к запросам DOM.
Во втором примере ( "td.someColumnClass span.editMode input"
) Sizzle эффективно делает следующее:
входные
элементы внутри someTableRow
входного
элемента просмотрите его дерево предков для элементов диапазона
с помощью class = "editMode"
. Удалите элементы input
, у которых нет этих предков span.editMode
, просмотрите его дерево предков для элементов td
с помощью class = "someColumnClass"
. Удалите элементы input
, у которых нет этих предков Однако в вашем первом примере вы явно определяете каждый шаг при каждом вызове find ()
, определение контекста и прохождение вниз оттуда. Вы применяете подход «сверху вниз». Это эквивалентно передаче контекста на каждом шаге, который обычно считается средством повышения производительности :
$('input', $('span.editMode', $('td.someColumnClass', someTableRow)))
Способ, которым JQuery обрабатывает селекторы, по моему опыту немного отличается от CSS.
Сокращение контекста для поиска - это ключ, как указал Джош.
Я нахожу использование двух селекторы параметров действительно быстрые
Как это сравнить по скорости?
Вам не нужны здесь все переменные, просто чтобы прояснить, что я делаю.
var columnClasses = $('.someColumnClass');
var tableCell = $('td', columnclasses);
var editMode = $('.editmode', tableCell);
var spanInside = $('span', editMode);
var inputFinally = $('input', spanInside);
Доброта,
Дэн
Because you are reducing the context for the search.
In case B, it has to search through every DOM element to see if it meets the criteria.
In case A, is can quickly decide to ignore anything that's not "td.someColumnClass", then it can take that subset of the DOM and ignore anything that's not in "span.editMode". So it has a much smaller set of elements to search through to find "input"s now.
A is more calls, but simpler. B is one call, but more complex. In this case, the complexity of the call greatly out-weighs the quantity of calls.
Здесь есть очень интересная статья о производительности селектора: http://blogs.atlassian.com/developer/2009/08/jquery_bondage.html
В ней автор показывает "привязку" расширения jQuery, которое показывает, сколько раз функция оценивается.
Я сам провел небольшое исследование производительности jQuery Selector. Большая проблема - поиск по имени класса в Internet Explorer. IE не поддерживает getElementsByClassName - поэтому jQuery и другие фреймворки «повторно реализуют» его в JavaScript, перебирая все элементы DOM. Ознакомьтесь со следующим аналитическим блогом о производительности селектора jQuery