Таблицы не являются ограниченным ресурсом (при разумной практике), поэтому не зацикливайтесь на том, чтобы создавать множество из них, «теряя» их.Точно так же в большинстве современных баз данных нулевые столбцы не занимают места (в postgresql, за исключением минимальных издержек «нулевой битовой маски»), поэтому они также не являются особенно ценным ресурсом.
Возможно, имеет смысл иметьтаблица для представления отдельных наборов атрибутов, которые могут быть определены вместе (это, по сути, одно из общих правил нормализации базы данных).Если вы хотите иметь дело с «действиями» в общем виде, вы можете захотеть иметь общие атрибуты в общей таблице, например, базовый класс в ООП ... или нет.
Например, выможет иметь:
jogging(activity_id int, a type, b type, c type)
football(activity_id int, a type, d type, e type)
и затем создать представление для объединения их вместе при желании:
create view activity as
select 'jogging', activity_id, a, b, c, null as d, null as e from jogging
union all
select 'football', activity_id, a, null, null, d, e from football
В качестве альтернативы вы можете иметь:
activity(activity_id int, a type)
jogging(activity_id int, b type, c type)
football(activity_id int, d type, e type)
и затем:
create view activity as
select case when jogging.activity_id is not null then 'jogging'
when football.activity_id is not null then 'football'
end,
activity_id, a, b, c, d, e
from activity
left join jogging using (activity_id)
left join football using (activity_id)
Эти модели в основном эквивалентны, главное отличие в том, что вторая обеспечивает четкий путь к отдельному идентификатору activity_id, что является одной из причин, по которой многие люди предпочитают его, особенно при использовании ORM для сохраненияданные (хотя вы можете сделать это и первым способом, поделившись последовательностью).