Выделенная таблица SQL, содержащая только уникальные строки

Question

Я не могу найти примеров того, кто делает это в Интернете, поэтому интересно, может быть, есть причина для этого (или, может быть, я не использовал правильные условия поиска) , Может быть, уже есть термин для этого, о котором я не знаю?

Чтобы сохранить содержимое базы данных для регулярных повторных строк, я собираюсь создать таблицу MySQL с именем unique_string. Это будет иметь только две колонки:

1. "ID": INT: primary_key индекс
2. "строка": VARCHAR (255): УНИКАЛЬНЫЙ индекс

Любые другие таблицы в любом месте в база данных затем может использовать столбцы INT вместо столбцов VARCHAR. Например, поле varchar под названием браузер вместо этого будет полем INT, которое называется browser_unique_string_id.

Я бы не использовал это ни для чего, где важна производительность. В этом случае я использую его для отслеживания сведений о каждом запросе страницы (регистрации веб-статистики) и «аудиторской проверки» действий пользователя в интрасети, но также и других вещей.

Я также знаю, что запросы SELECT будут сложными, поэтому я не беспокоюсь об этом. Скорее всего, я напишу код для генерации запросов, чтобы вернуть «реальные» строковые данные.

Мысли? Я чувствую, что, возможно, я проглядываю что-то очевидное здесь.

Спасибо!

Answer 1

Это очень распространенный шаблон проектирования в базах данных, где мощность данных относительно небольшая по сравнению с таблицей транзакций, с которой она связана. Запросы не будут очень сложными, просто простое соединение с поисковой таблицей. Вы можете включить в таблицу поиска больше, чем просто строку, другую информацию, которая обычно повторяется. Вы просто используете normalizing, чтобы удалить дубликаты данных.

Пример:

Запрос Таблица:

Date  
Time 
IP Address  
Browser_ID 

Browser Таблица:

Browser_ID 
Browser_Name 
Browser_Version 
Browser_Properties 

Answer 2

Если вы планируете на каротажных данных в режиме реального времени (в отличие от пакетного задания), то вы хотите, чтобы ваше время для записи записи в базу данных было так же быстро, как возможно BLE. Если вы регистрируетесь синхронно, то, очевидно, время создания записи напрямую повлияет на время, необходимое для завершения HTTP-запроса. Если это асинхронно, то медленное время создания записи приведет к узкому месту. Однако, если это пакетное задание, тогда производительность не будет иметь значения, если вы можете уверенно создать все упакованные записи до следующего запуска партии.

Для того, чтобы сократить время, необходимое для создания записи вы действительно хотите, чтобы выровнять структуру базы данных, ваш текущий запрос в псевдо может выглядеть

SELECT @id = id from PagesTable 
WHERE PageName = @RequestedPageName 

IF @id = 0 
THEN 
    INSERT @RequestedPageName into PagesTable 
    @id = SELECT @@IDENTITY 'or whatever method you db supports for    
          'fetching the id for a newly created record 
END IF 

INSERT @id, @BrowserName INTO BrowersLogTable 

Где, как и в плоской структуре вы бы просто need 1 INSERT

Если вас беспокоит целостность данных, которой вы должны быть, то обычно вы нормализуете эти данные, запрашивая при написании их в отдельный набор таблиц (или отдельную базу данных) через регулярные промежутки времени и используя это для запроса.

Answer 3

Я использовал эту структуру для аналогичного приложения - отслеживание URI для веб-журналов. В этом случае база данных была Oracle.

Проблемы с производительностью не являются минимальными. По мере роста базы данных существует десятки миллионов URI. Таким образом, просто определение правильной строки во время INSERT является сложной задачей. Мы справились с этим, построив большую часть логики обновления в hadoop, поэтому таблица базы данных была, по сути, просто копией таблицы хаопов.

В обычной базе данных вы можете обойти это, создав индекс, как вы предлагаете в своем вопросе. И индексное решение будет хорошо работать с вашей доступной памятью. На самом деле, это довольно вырожденный случай для индекса, потому что вам действительно нужен только индекс, а не базовая таблица. Я не знаю, признают ли mysql или SQL Server это, хотя столбчатые базы данных (такие как Vertica) должны.

У SQL Server есть другой вариант. Если вы объявляете строку как VARCHAR (max), тогда она не хранит отдельную страницу данных из остальной части данных. Во время полного сканирования таблицы нет необходимости загружать дополнительную страницу в память, если столбец не ссылается на запрос.