Как реализовать масштабируемую таблицу?

Question

[vladimir percov]

Доброго времени суток, господа и дамы!
1. Есть компания с продаваемые продуктами
2. Есть таблица клиентов clients
3. Есть планы начальника на продажу продуктов совсем отличных от поставляемых

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

Как реализовать таблицу clients так, чтобы не пришлось бесконечно добавлять колонки? Или в этом ничего страшного?

Спасибо.

UPD.

Максим Федоров: например, есть таблица products с колонками
----------------------------------
| products |
----------------------------------
| id | prod_name | prod_price |
-----------------------------------
| 1 | Product 1 | 500 |
| 2 | Product 2 | 700 |
| 3 | Product 3 | 1000 |
-----------------------------------

Есть таблица clients
---------------------------------------------
| clients |
---------------------------------------------
| id | attrib1 | attrib2 | attrib3 | attrib4 |
----------------------------------------------
| 1 | testA | testA | testA | testA |
| 2 | testB | testB | testB | testB |
| 3 | testC | testC | testC | testC |
----------------------------------------------

При продаже продукта Product 1, для оформления требуется attrib1 и attrib3 из clients. При продаже продукта Product2, для оформления требуется attrib2 и attrib4 из clients.

При создании нового продукта (пусть будет Product 4), в таблицу clients нужны будет добавить еще пару атрибутов.
Вопрос состоит в том, как организовать эти атрибуты без прямого добавления колонок непосредственно в clients.

P.S. Появилась мысль создать таблицу clients_attrib_for_product, и там вводит данные в виде
------------------------------------------------------
| clients_attrib_for_product |
------------------------------------------------------
| id | prod_id | client_id | att_name | att_value |
-------------------------------------------------------
| 1 | 1 | 2 | attrib1 | testA |
| 2 | 2 | 5 | attrib2 | testB |
| 3 | 3 | 3 | attrib3 | testC |
-------------------------------------------------------
Но не знаю, насколько это правильно.

Comments

[Максим Федоров]

Вы бы примеры структуры таблиц привели или вопрос переформулировали, а то из текущего описания ничего не понятно...

[vladimir percov]

Максим Федоров: добавил в вопрос

[Дмитрий Шицков]

Про clients_attrib_for_product -
так правильно

Answer 1

[lega]

Добавить json в products, а clients тут вообще не надо.

Comments

[vladimir percov]

А если работаю с MySQL?

[gradmax]

As of MySQL 5.7.8, MySQL supports a native JSON data type

[lega]

vladimir percov: json можно в текст заворачивать,
ну это все если поиска по атрибутам не надо

[vladimir percov]

lega: конечно, нужен поиск

[lega]

vladimir percov: дальше зависит от того какой поиск, какие запросы... например можно неплохой параметрический (фасетный) поиск сделать на fulltext индексе который есть в mysql

[vladimir percov]

lega: это уже издевательство)

[lega]

vladimir percov: если оно работает в разы (на порядки) быстрее, то это "архитектура".

Answer 2

[Максим Федоров]

в случае использования реляционной базы можно использовать EAV-модель для хранения подобных данных, либо же переходить на NoSQL базу