Нормализация общего типа идентификатора, разделяемого между таблицами

Question

Это упрощенная версия проблемы.

У нас есть клиенты, которые присылают нам много данных, а затем запрашивают его. Мы обязаны им иметь несколько «открытых» идентификаторов, которые они могут запросить у наших данных. (Большинство из них хотят запросить нашу систему по идентификатору, который они отправляют вместе с данными, но не всегда). Для простоты мы будем называть их «pid», «crid» и «musicbrainzid». У нас есть таблица «entity», которая хранит эту информацию. Это выглядит примерно так («авторитет», кто послал данные):

entity 
-- 
entity_id 
authority // who sent the data 
type  // 'pid', 'crid', 'musicbrainz', etc. 
value  // the actual id value 

Тогда у нас есть отдельные объекты, такие как «серия» «эпизод» и «вещание» (на самом деле, есть намного больше, но я держу его здесь просто). Каждый из них имеет entity_id, указывающий на таблицу сущности.

Как внешние клиенты могут искать через pid или crid и получать соответствующий эпизод или серию, а также правильное определение того, что это такое? Учитывая pid, мы можем получить идентификатор объекта, но тогда нам нужно искать серию эпизодов, серию и широковещательные таблицы для этого значения. Кроме того, не все идентификаторы обязательно будут связаны со всеми другими таблицами, но любой объект (например, «эпизод») может иметь несколько идентификаторов (ИДП, CRID и т.д.)

Стратегии:

1. Найдите идентификатор объекта для pid и найдите все остальные таблицы для pid.
2. Поместите столбец «entity_type» на сущности, но что, если это pid в таблице эпизодов, но мы случайно установили серийный номер episode.type? Мы не хотим дублировать данные, и я не хочу помещать метаданные базы данных в значения столбцов.

Вариант № 1 является медленным и кажется неправильным (далее, различные таблицы имеют различные структуры, создающие проблематичные).

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

Что такое вариант 3?

Сторона примечания: мы знаем, что нам нужно разбить «авторитет» на отдельную таблицу, потому что не все полномочия/комбинации типов действительны.

Answer 1

Если я правильно понял ваш вопрос, я бы с Вариант 1.

Запрос к идентичности строки на основе ENTITY_ID не должно быть медленным, как все, что данные должны быть в индексе ,
Если ваши индексы настроены правильно, это не должно даже обращаться к фактическим данным. (По крайней мере, в SQL Server это не так.)

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

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