2012-04-27 2 views
0

Мне нужна таблица для хранения пар ключ/значение (например, реестра Windows). Вот что у меня есть:Таблица эффективных значений/значений

CREATE TABLE REG   
(      
    ID VARCHAR(255) NOT NULL, 
    DATA VARCHAR(1024), 
    PRIMARY KEY(ID)   
);      

Я использую SQL Server 2008 R2, 2008 и 2005

Может кто-нибудь предложить более эффективные идеи для хранения пар ключ/значение.

Я хранения ключей, как это:

/USER/REX/AUTO_LOGIN = "Т"

/USER/REX/СООБЩЕНИЕ/1 = "Это более длинное сообщение"

В около 10000 записей Я уже вижу проблемы с производительностью.

+1

Производительность где? Когда первичный ключ установлен в ID, SQL Server должен индексировать этот столбец и запрашивать его, он все равно будет очень быстрым в 10k строк. Предполагая, что вы делаете такие запросы, как: SELECT * из reg WHERE id = '/ USER/REX/AUTO_LOGIN''. Если вы начинаете бросать в подстановочные знаки, которые могут повлиять на вещи ... – Windle

+0

Я использую этот запрос: SELECT DATA FROM REG WHERE ID =? – GenuineRex

+0

и это: UPDATE REG SET DATA =? где KEY =? – GenuineRex

ответ

2

Вы можете ввести дополнительный столбец, который является хэшем имени ключа; например «/ USER/REX/AUTO_LOGIN» может иметь значение hash to 102454. Затем вы можете добавить индекс в столбец хэша (или составной индекс по столбцу хеширования и столбец имени ключа) и включить его в предложение where любых запросов; например

SELECT DATA 
FROM REG 
WHERE HASH = 102454 and ID = '/USER/REX/AUTO_LOGIN' 

Поиска по int колонку должна быть гораздо более эффективными, чем запрашивая varcharID колонки, и должен иметь эффект сужения на несколько строк с одинаковым значением хэша, который затем будет проверяемым для согласования ID значения.

+0

Извините, но это звучит как плохая идея для меня по следующим причинам: (1) вторичные индексы стоят дорого в кластеризованной таблице (вы можете сделать ее некластеризованной, но у нее тоже есть цена). (2) вы не можете избежать индекса на ID в любом случае (так как это PK), так почему бы просто не использовать _it_? Я вовсе не убежден, что не-составной индекс хеша будет на самом деле быстрее на практике (он компактнее, но будут «ложные срабатывания»). OTOH, составной по хешу и ID не имеет никакого смысла. У вас есть практический опыт в этой технике? Вы проводили тесты на реалистичные объемы данных? –

1

Я хотел бы избежать использования varchar(255) в качестве основного ключа, выбор уникального индекса вместо: вопросы

CREATE TABLE REG (
    id bigint identity not null, 
    key VARCHAR(256) NOT NULL, 
    DATA VARCHAR(1024), 
    PRIMARY KEY(ID) 
); 

create unique index reg_key on REG(key); 
+1

Я подумал об этом, но тогда мне понадобится указатель на ключ, и любой запрос SELECT будет считывать индекс по ключу, а затем должен выполнить поиск на основе первичного ключа. Это может сделать обновления быстрее, однако, как только у меня был ПК в памяти. – GenuineRex

+1

@GenuineRex Я бы попробовал все равно: использование больших значений переменной длины в кластерном индексе PK просто не кажется правильным, хотя я могу ошибаться в этом. – dasblinkenlight

Смежные вопросы