Добрый день.
Пример из головы. Есть каталог магазина. В нем есть товары, относящиеся к разным категориям, но часть параметров совпадает у всех товаров. Например: кухонные плиты, телевизоры и мультиварки. Поля - описание, цена, габариты, вес есть и у первого типа и у второго и у третьего. Но в у каждого типа есть и свои - уникальные параметры. У телевизора - диагональ, у мультиварки - количество программ, а у плиты - количество конфорок. Вопрос - как организовать хранение и обработку всего этого добра. На каждый товар свою модель? Но тогда будет много кода повторяться. Одна модель на все, с полем принадлежности товара к определенном типу? Тоже вроде нерационально - у каждого товара большинство полей из-за такой универсальности будет пустовать, да и запутаться в таком количестве параметров легко.
Приходят в голову мысли о наследовании, но слышал, что очень не рекомендуется. Недавно узнал про концерны (я очень начинающий разработчик), но они вроде как для методов, а не для данных. В общем - как быть?
Современные базы данных, например PostgreSQL, имеют специальные типы данных на такие случаи - JSON, hstore. Посмотрите в их сторону. Они очень удобны, но могут уступать обычным полям в плане производительности.
В любом случае вам придется решить вопрос валидаций, иначе модель превратится в нечитамое месиво из условных валидаций. Тут уже либо STI, либо выносить валидации в отдельные объекты - form objects.
Чисто теоретически - что такое общие параметры и что такое уникальные параметры?
Собственно, вторые отличаются от первых только тем, что нужно хранить и выводить не только значение, но и название параметра.
Те же уникальные параметры, для которых нужно что-то большее (форматированный текст, фото-видео, карты и пр.) - лучше все-таки вынести в общие. Не так уж много их будет.