Хранение нескольких ссылок в одном поле

Question

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

Я думал об использовании кода «двоичного типа», поэтому для каждой таблицы у меня будет «0/1», а для пяти таблиц у меня будет от «00000» (без ссылок) до «11111» (для пяти ссылок).

Итак, если у меня есть только ссылки в таблице 3, я буду хранить «00100».

Теперь вот мои вопросы:

1) Является ли это хорошая идея? Есть ли лучшие решения?

2) Какое поле мне нужно использовать? (Я думал ENUM)

EDIT (ПРОЯСНИТЬ)

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

Пять таблиц - это веб-таблицы, поэтому мне нужно знать, могу ли я найти информацию на столе или нет.

EDIT 2 (дальнейшее уточнение)

Я не запрашивать веб-таблицы: Я получаю информацию от них кодом. Код читает из моей БД, чтобы узнать, сколько веб-таблиц нужно получить, а какой из 5 существующих.

Answer 1

Я бы, скорее всего, сохранил информацию в Relational Database Management System реляционно; как можно ближе к 3-й нормальной форме или лучше. Это означает, что у меня будет две таблицы.

В одной таблице перечислены доступные параметры. Во второй таблице перечислены все параметры, связанные с этим объектом, который обращается к 5 веб-таблицам.

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

Теперь, если это ГАРАНТИРОВАНО, чтобы этого не произошло, я мог видеть, как хранить значения в одном поле, где имеет место положение; возможно, используя тип данных «SET». Но, учитывая, что есть несколько гарантий, я бы, скорее всего, не воспринял этот подход только потому, что он не масштабируется без изменения кода и не работает также под томом.

Для решения ваших конкретных вопросов:

1) Является ли это хорошая идея? Есть ли лучшие решения?

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

2) Какое поле мне нужно использовать?(Я думал, ENUM)

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

Но мое воздействие и использование для ENUM ограничено в этом контексте; поэтому у меня может не быть опыта, который бы сделал это разумным подходом.