Объявление Индекса как уникальный в SQL Server
Вы определяете docRef в constructor, поэтому вы можете получить к нему доступ только в пределах constructor.
constructor(){
super()
const docRef = firestore.doc("samples/sandwichData")
docRef.set({
hotDogStatus: "not a sandwich!"
})
}
Если вы хотите, чтобы он был доступен где-либо внутри класса, вы должны определить его как свойство экземпляра, как метод получения или установить его в `this.
Пример использования свойства. Это зависит от нового стандарта JS .
class ReduxFirebase extends connect(store)(LitElement) {
docRef = firestore.doc("samples/sandwichData")
constructor(){
super()
this.docRef.set({
hotDogStatus: "not a sandwich!"
})
}
render() {
return html`
`
}
writeToDb() {
this.docRef.set({
hotDogStatus: "may be a sandwich"
})
}
}
Пример использования геттера.
class ReduxFirebase extends connect(store)(LitElement) {
constructor(){
super()
this.docRef.set({
hotDogStatus: "not a sandwich!"
})
}
get docRef() {
return firestore.doc("samples/sandwichData")
}
render() {
return html`
`
}
writeToDb() {
this.docRef.set({
hotDogStatus: "may be a sandwich"
})
}
}
Пример настройки на this.
class ReduxFirebase extends connect(store)(LitElement) {
constructor(){
super()
this.docRef = firestore.doc("samples/sandwichData")
this.docRef.set({
hotDogStatus: "not a sandwich!"
})
}
render() {
return html`
`
}
writeToDb() {
this.docRef.set({
hotDogStatus: "may be a sandwich"
})
}
}
Обратите внимание, что вы хотите убедиться, что firestore.doc("samples/sandwichData") не выполняет кучу работы, прежде чем она понадобится, и определить это на соответствующей стадии жизненного цикла компонента .
5 ответов
Короче говоря: если ваши данные внутренне УНИКАЛЬНЫ , вы извлечете выгоду из создания UNIQIE указатель на них.
См. Статью в моем блоге для подробного объяснения:
Теперь, кровавые подробности.
As @ Мерада сказал: УНИКАЛЬНОСТЬ влияет на расчетное число строк в конструкторе планов. Индекс [1124] UNIQUE обладает максимально возможной избирательностью, поэтому:
SELECT *
FROM table1 t2, table2 t2
WHERE t1.id = :myid
AND t2.unique_indexed_field = t1.value
почти наверняка будет использовать NESTED LOOPS , в то время как
SELECT *
FROM table1 t2, table2 t2
WHERE t1.id = :myid
AND t2.non_unique_indexed_field = t1.value
может извлечь выгоду из HASH JOIN , если оптимизатор считает, что non_unique_indexed_field не является селективным.
Если ваш индекс CLUSTERED ] (т.е. сами строки содержатся в индексных листах) и не УНИКАЛЬНЫЕ ,затем к каждому ключу индекса добавляется специальный скрытый столбец под названием uniquifier , что делает ключ больше и индекс медленнее.
Вот почему индекс UNIQUE CLUSTERED фактически немного больше эффективнее, чем неУНИКАЛЬНЫЙ КЛАСТЕРНЫЙ .
В Oracle соединение для УНИКАЛЬНОГО ИНДЕКСА требуется для так называемого сохранения ключа , который гарантирует, что каждая строка в таблице будет выбрана не более одного раза, и делает представление обновляемым.
Этот запрос:
UPDATE (
SELECT *
FROM mytable t1, mytable t2
WHERE t2.reference = t1.unique_indexed_field
)
SET value = other_value
будет работать в Oracle , а этот:
UPDATE (
SELECT *
FROM mytable t1, mytable t2
WHERE t2.reference = t1.non_unique_indexed_field
)
SET value = other_value
Это не проблема с SQL Server , однако.
Еще одна вещь: для такой таблицы,
CREATE TABLE t_indexer (id INT NOT NULL PRIMARY KEY, uval INT NOT NULL, ival INT NOT NULL)
CREATE UNIQUE INDEX ux_indexer_ux ON t_indexer (uval)
CREATE INDEX ix_indexer_ux ON t_indexer (ival)
, этот запрос:
/* Sorts on the non-unique index first */
SELECT TOP 1 *
FROM t_indexer
ORDER BY
ival, uval
будет используйте TOP N SORT , тогда как этот:
/* Sorts on the unique index first */
SELECT TOP 1 *
FROM t_indexer
ORDER BY
uval, ival
будет использовать только сканирование индекса.
Для последнего запроса нет смысла в дополнительной сортировке на ival , поскольку uval в любом случае уникальны, и оптимизатор принимает это во внимание.
В примерах данных из 200 000 строк ( id == uval == ival ) первый запрос выполняется в течение 15 секунд, а второй - мгновенный.
Конечно, оптимизатор будет учитывать уникальность. Это влияет на ожидаемое количество строк в планах запросов.
Производительность отрицательно сказывается при вставке данных. Нужно проверить уникальность.
Возможно, еще важнее: уникальность защитит целостность данных. Производительность будет причиной игнорировать это.
На производительность может повлиять положительно или отрицательно, или не повлиять вовсе: это будет зависеть от запроса, если индекс будет использоваться и т. Д.