Nekifrovv,

абсурд - это i_, t_
детский сад. Давайте, еще называйте таблицы dim_, fact_

Nekifrovv,

я не знаю каков бизнес-смысл в tickets, но абстрагируюсь.

Допустим, вы взялись за нелегкую задачищу по формализации продуктового каталога
таблицы:
product_category - категория продуктов
product_subcategory - под. категория продуктов
product - продукты
Каждая из этих таблиц имеет собственные атрибуты

Допустим, эти продукты должны M:M включаться в комплекты, тогда:
product_kit - список продуктовых комплектов (из предположения, что комплектам присваиваются какие-то коды, номера, наименования)
product_kit_product - включение (многие-ко-многим) продуктов в продуктовые комплекты;
наименование придумал в лоб, хотя может быть бизнес оперирует понятием комплектация, тогда - product_package

Таким образом, любой аналитик кто подключится к вашей БД, легко увидит все таблицы, которые относятся к теме продуктов.


Если же в разных бизнес-сущностях у вас есть также категории, но они сводятся к виду id, name, и нет вероятности расширения их до отдельных сущностей с N-атрибутами, то создают lookUp-справочник для всех таких перечислений.

По поводу dim_, fact_ - сегодня у вас табилца как измерение, а завтра она стала и фактОвой тоже.


Еще круче, если сначала создадите, согласуете словарь бизнес-терминов, в котором будут основные термины и бизнес-синонимы,
всё это введете в Power Designer и модель данных будете проектировать в CASE-средстве с декомпозицией, PK-FK и логическими связими и т.п.
Кстати, Power Designer позвоялет контролировать длину системных наименований полей, правила именования и т.д.