Шаблон проектирования SQL: как хранить несколько уникальных идентификаторов с разных сайтов в mashup?

Question

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

Моя проблема в том, что у каждого источника данных есть свой способ выдачи уникальных идентификаторов через их REST API. Мне нужны предложения по лучшему шаблону для использования в моей модели данных MySQL.

Мое текущее решение состоит в том, чтобы использовать 1 таблицу для всех элементов и составной ключ, но соединения являются длинными, и cakePHP изначально не работает с составными ключами:

datasource_id smallint,  
datasource_item_id VARCHAR(36), // some datasources issue alpha keys

В: Хорошо / лучше добавить первичный ключ с автоинкрементом в мою таблицу и преобразовать все мои внутренние объединения / индексы из внешних UID в мои внутренние UID? :

id int (10) без знака NOT NULL auto_increment,

В: Являются ли enums эффективным типом данных для хранения datasource_id (должно иметь, возможно, 10 различных источников данных)?

В: Существуют ли другие подходы, которые в долгосрочной перспективе дают лучшие, более масштабируемые результаты?

Answer 1

В основном я могу подтвердить только те решения, которые вы уже рассматривали.

Поскольку тип хранилища, используемый в схеме таблицы, не обязательно должен совпадать с типом данных (именно поэтому SQLite 2 был нетипизирован , а SQLite 3 имеет , поэтому мало типов ), мой первый импульс такой же, как ваше текущее решение.

Следуя другой школе мысли, а именно, что идентификаторы, которые являются произвольными (т. Е. Идентификаторы, не основанные на атрибутах того, что вы моделируете), должны храниться внутри вашей собственной базы данных, предлагает второе решение, которое вы упомянули: добавьте id колонка. Одной из причин этой школы является то, что вы не хотите, чтобы ваши столы зависели от чьих-то внутренних органов, хотя здесь это не так важно. Поскольку cakePHP не поддерживает составные ключи, это наиболее приемлемый вариант.

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

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

Первые три имеют общий недостаток. Каждый источник данных имеет свой собственный тип идентификатора; при хранении идентификаторов из разных источников в одном и том же столбце необходимо определить дополнительные ограничения для обеспечения целостности типов на уровне базы данных, возможно, в форме триггеров (поскольку MySQL не поддерживает предложение CHECK).

В: Являются ли enums эффективным типом данных для хранения datasource_id (должно быть, возможно, 10 различных источников данных)?

требования к хранилищу для ENUM составляют 1 или 2 байта, в зависимости от количества различных значений. В десяти источниках данных для каждой строки должен использоваться только один байт. Это по-прежнему тратит чуть более 4 бит / строка. Будь эффективным, я оставлю до тебя.