Быстрый способ найти строку, связанную с данным Guid, во многих базах данных и таблицах SQL.

У меня есть несколько баз данных SQL, каждая из которых содержит множество таблиц. Они преимущественно имеют случайно сгенерированные идентификаторы в качестве первичных ключей строк. Я хотел бы найти способ найти данные таблицы и строки, связанные с данным Guid (без информации о типе).

Поэтому я рассматривал возможность настройки фильтра Блума для каждой таблицы и кэширования его где-нибудь. Я бы сначала протестировал Guid против фильтра, а затем запросил бы данные в базе данных или кеше (или для ложного срабатывания). Однако я никогда раньше с ними не работал и поэтому не знаю, каковы их ТТХ и будут ли они эффективным решением моей проблемы.

Характеристики базы данных:

  • ~100 столов на выбор. Некоторые из них выбираются с гораздо большей вероятностью, чем другие.

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

  • Больше структуры, чем данных! Все помещается на один сервер.

Стоит ли исследовать это решение? Лучше ли мне придерживаться кэширования более традиционных структур поиска? Если я выберу Блума, есть ли какие-нибудь ярлыки для функций хеширования, учитывая, что Guids — очень независимый ввод?


sql database sql-server-2008 data-structures bloom-filter
person sh54    schedule 07.07.2011    source источник
comment
Вы говорите, что лучше внедрите фильтры Блума в код приложения, чем будете искать зависимости внешнего ключа в системных таблицах? (Конечно, нет никакой гарантии, что каждое использование ключа, GUID или нет, происходит через ссылку внешнего ключа, но все же.)   -  person Mike Sherrill 'Cat Recall'    schedule 07.07.2011
comment
Под «системными таблицами» вы подразумеваете, что есть метаданные базы данных, которые я могу запросить? Я не знаю, как обойти эти таблицы, поэтому, пожалуйста, просветите меня. Существует большая вероятность того, что каждый фрагмент данных, на который ссылается GUID, который мне нужен, появляется во внешнем ключе.   -  person sh54    schedule 07.07.2011
comment
Каждая база данных SQL имеет по крайней мере один способ запроса метаданных. Стандартный способ — использовать представления INFORMATION_SCHEMA. Но, поскольку обычно это представления, построенные поверх системных таблиц, некоторые платформы также позволяют напрямую запрашивать базовые таблицы. (Не знаю, какую платформу вы используете, но вы можете пометить ею свой вопрос.)   -  person Mike Sherrill 'Cat Recall'    schedule 07.07.2011
comment
SQL-сервер. Достаточно недавно закончил колледж, поэтому я инстинктивно склонен пытаться алгоритмизировать вещи, если лучшее решение не находится у меня под носом.   -  person sh54    schedule 07.07.2011
comment
Когда дело доходит до баз данных SQL, имейте это в виду, независимо от вашей проблемы: вы не первый. Вы, вероятно, даже не первый человек с вашей конкретной проблемой сегодня.   -  person Mike Sherrill 'Cat Recall'    schedule 07.07.2011

Ответы (2)


arrow_upward
0
arrow_downward

Найдите в справке вашей платформы «INFORMATION_SCHEMA» или «системные таблицы». Насколько мне известно, каждая СУБД SQL имеет как минимум один способ запроса метаданных. "Стандартным" способом является использование представлений INFORMATION_SCHEMA, но их содержимое зависит от поставщика СУБД.

В информационной схеме PostgreSQL этот запрос покажет вам всю таблицу и имена столбцов, которые имеют ограничения внешнего ключа, а также имена их целевых таблиц и столбцов.

select kc2.table_name as fk_table_name, kc2.column_name as fk_column_name, 
       kc1.table_name as ref_table_name, kc1.column_name as ref_column_name
from INFORMATION_SCHEMA.referential_constraints rc
inner join INFORMATION_SCHEMA.key_column_usage kc1 
        on rc.constraint_catalog = kc1.constraint_catalog
       and rc.constraint_schema = kc1.constraint_schema
       and rc.unique_constraint_name = kc1.constraint_name
inner join INFORMATION_SCHEMA.key_column_usage kc2 
        on rc.constraint_catalog = kc1.constraint_catalog
       and rc.constraint_schema = kc1.constraint_schema
       and rc.constraint_name = kc2.constraint_name
order by kc2.table_name, kc2.column_name

представления схемы информации SQL Server

person Mike Sherrill 'Cat Recall'    schedule 07.07.2011

arrow_upward
0
arrow_downward

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

Так почему бы не создать одну или несколько простых таблиц для хранения этой информации? У вас может быть таблица с двумя столбцами (Guid-Value и Table-ID), которые также образуют первичный ключ, и использовать его в качестве индекса.

person Michael Petito    schedule 07.07.2011