Иван Мельников

Как я понял, под сопоставлением товаров понимается связь типа "Вместе с товаром A в x% случаев покупают товар B". Если так, то такое "сопоставление" изображается направленным взвешенным и достаточно разреженным (если в случае веса дуги 0% считать, что она отсутствует) графом.
Почему вы считаете, что таблица N:M будет неудобна для хранения такой структуры?

id_first (4 байта)
id_second (4 байта)
conn_rate (1 байт)
period_type (1 байт) -- день, неделя, месяц
date (2 байта) -- дата начала периода

Далее, делаем индекс B-tree по полям id_first и id_second .
Пусть, товаров 100 000. Для хранения всех связей за конкретный период понадобится 100 000 * 99 999 ≈ 10 млрд. строк или 90 ГБайт места + примерно столько же для индекса ≈180 ГБайт.
А периодов за 1 год = 365 + 52 + 12 = 429. Итого, для хранения годичных данных понадобится ≈ 77 ТБайт.
Понятно, что это нереализуемо.
Тогда придётся хранить дуги с достаточно большим весом. От этого вряд ли вы что-то потеряете, так как ~ 99-99.99% дуг будут иметь вес x < 0.1%.
А ещё можно оптимизировать требуемый объем, разделив данную табличку на 3: табличка для дневных данных, табличка для недельных и табличка для месячных.

так вот что лучше взять поле id или nickname?

Взять в качестве ссылочного поля внешнего ключа другой таблицы? В некоторых СУБД, например, в MySQL нельзя внешнему ключу назначить не первичный ключ (другой таблицы).

Как насчет модели управления доступом на основе ролей (RBAC) ?
Такие сущности, как ресурс, действие, пользователь и роль выделяются в отдельные отношения. Связываются они табличками вида M:N.

Вроде проще пареной репы.
Создаете таблицу филиал (id, name). А в остальных таблицах, там, где это требуется, определяете внешние ключи на поле id в таблице филиал.

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

Стандартная ситуация, когда полностью отсутствует теоретическая база. Чтобы перестать чувствовать себя слепым котенком, нужно ликвидировать этот пробел. Нужно начать с самых основ – понятие отношения (как ни странно, оно не имеет ничего общего со связями между таблицами), ключи, нормальные формы. Вы должны выучить и понять все 7 нормальных форм и уметь самостоятельно сконструировать таблицу в n-й НФ, но не в n+1-й НФ. А в качестве отдыха следует устранить пробелы в теории множеств, математической логике и системах счисления. Не нужно браться за университетские монографии – это бессмысленно. Вполне достаточно ограничиться школьным курсом математики и информатики. Это может показаться сложным и скучным занятием, но если вы сможете это перетерпеть, то потом наступит облегчение и вы сами удивитесь насколько все логично и упорядочено.

СУБД то какая?
В MySQL, например, просто создается уникальный индекс:

CREATE TABLE dic(
...
dic_value VARCHAR(30) NOT NULL UNIQUE
...);

В первую очередь дело не в количестве полей в таблице, а в уровнях нормализации.
Обычно достаточно, чтобы таблицы находились в 3НФ или НФБК. Если уровень нормализации вашей таблицы ниже, то её нужно декомпозировать.
Есть и другие соображения в пользу декомпозиции таблицы. Например, нужно для таблицы поднять вертикальное партиционирование, но ваша СУБД (в частности MySQL) этого не поддерживает. Тогда приходится делить таблицу на две или более (главное, чтобы потом не пришлось их каждый раз join-ить).