#sql-server #hash
#sql-сервер #хэш
Вопрос:
Я думаю кэшировать список адресов и их координат (широта длина) в SQL Server. Обычно я получаю координаты, вызывая веб-службу, и, чтобы избежать обратного перехода к этому WS, я хочу сохранить все эти ответы WS в локальной базе данных SQL Server.
Мне интересно, как оптимально хранить ответы WS в моей локальной базе данных SQL Server, поскольку у меня может быть список из 500 тыс. адресов? Я думал о следующей структуре:
AddressHash BIGINT -- PK, clustered index,
--obtained by applying a hashing algorith (SHA-1?) of
--Street|StreetNumber|Zip|City|County|Country
Lat DECIMAL
Long DECIMAL
1 / О чем вы думаете?
2 / Вы рекомендуете лучший (= более быстрый) алгоритм хеширования?
3 / BIGINT является оптимальным типом данных в этом случае?
4 / Есть ли у вас какой-либо другой оптимальный способ хранения этих данных в SQL Server?
Спасибо за ваш вклад.
Комментарии:
1. Можете ли вы описать общий шаблон доступа к данным?
Ответ №1:
Если бы только был выделенный тип данных для хранения географических данных … о, подождите, есть
Комментарии:
1. тип данных geography не сильно поможет с геокодами. обратные геокоды пространственный индекс, да.
2. Почему география не подходит для этого? Вы собираетесь спросить эту таблицу: «Учитывая этот адрес, где он находится на земном шаре?» и точка географии является подходящим ответом.
3. Географическая точка занимает 22 байта, длина и широта DEC (9,6) занимают по 5 байт каждый, что позволяет сэкономить место. Также стоимость преобразования long и lat в geography во время вставки … затем стоимость обратного преобразования из geography в long и lat. самым большим преимуществом географического типа данных является доступ к их пространственным функциям и индексам. геокодирование не нуждается ни в чем из этого. Если таблица будет использоваться для других целей, требующих этих пространственных функций и индексов, например, обратного геокодирования, тогда конечно.
Ответ №2:
Что касается вопроса bigint, используйте любой тип данных, возвращаемый функцией hashbytes.