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

Описываю суть:
например есть данные:
- таблица поставщики - главный,
- таблица товар - подчиненный,
- таблица клиенты - подчиненный.
Вариант 1 (более чем распространенный):
- создать таблицу "поставщик-товары",
- создать таблицу "поставщик-клиенты";
Вариант 2 (предлагаемый):
- создать таблицу "параметры",
- создать таблицу "тип параметров" - это и есть "товар", "клиенты",
- создать таблицу "значения параметров" со столбцами разного формата.
- создать таблицу "поставщик-параметры", с одним из столбцов - тип параметра и сделать индекс "поставщик - тип параметра - параметр".

а если в таблицу "значения параметров" вогнать еще и тип параметра - могу сделать партиционирование по типу. В таблице "значения параметров" внешним ключом сделать "код параметра, тип параметра", в таблице "поставщик-параметры"-первичным ключом. Как такой вариант?
Где?
а не будет ли при предлагаемых мной условиях - это сильно незначительным замедлением?

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

авторВам аббревиатура EAV что-нибудь говорит?
пока нет...если по теме, можно ссылочку (в ya.ru что то толком ничего не написано)?

to BELY: за ссылку спасибо, довольно наглядно и понятно. Если по поводу сравнения методов архитектуры (быстродействие) есть у кого мукулатура (желательно на русском) - буду признателен.