Нормальная идея, если нужно.
на одном проекте я реализовал так всю доменную область.
так что динамически даже ActiveRecord модели создаются. В словаре типов сущностей указывался класс этой сущности.
в итоге многие универсальные паттерны стали единственными для всех сущностей.
например таблица многие-ко-многим для любых сущностей выглядит вот так:
Код: Выделить всё
CREATE TABLE `wf_m2m` (
`id` int NOT NULL AUTO_INCREMENT,
`e_onoff` tinyint unsigned DEFAULT '64',
`e_id_left` int NOT NULL,
`k_id_left` tinyint unsigned NOT NULL,
`e_id_right` int NOT NULL,
`k_id_right` tinyint unsigned NOT NULL,
`e_name` varchar(250),
`e_info` json DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `el_idx` (`e_id_left`),
KEY `er_idx` (`e_id_right`)
)
e - entity
k - kind of entity
или таблица расчетов (типа журнала Расчетов в 1С:Зарплата)
для какой угодно сущности, в рамках какого угодно "периода", "отдела", ..., ...
Код: Выделить всё
CREATE TABLE `wf_calc_results` (
`id` int NOT NULL AUTO_INCREMENT,
`e_onoff` tinyint DEFAULT '64',
`subject_id` int NOT NULL,
`subject_kind` tinyint unsigned NOT NULL,
`scene_id` int NOT NULL,
`scene_kind` tinyint unsigned NOT NULL,
`group_id` tinyint unsigned NOT NULL COMMENT 'group of calculation',
`group_result` int DEFAULT NULL,
`updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`e_info` json DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `subject_idx` (`subject_id`),
KEY `scene_idx` (`scene_id`)
)
Индексировать kind поля смысла нет. Выборки без хотя бы одного id редки, а повторяемость значений в kind поле сведет на нет индекс по нем.
Сейчас прикручиваю бух учет, но там решил что за kind будет отвечать номер счета. то есть счета будут типизированы для сущности.
По опыту работы с такой организацией могу сказать что для большинства задач - избыточная система, как и DDD
Хотя и удобная, все становится унифицированным и простым
Особенно упрощается работа с типичными патернами, один-ко-многим, многие-ко-многим, EAV
Нужно такое если писать какую-то систему типа Magento, то есть которая будет кастомизироваться не вами, и неизвестно заранее для каких бизнес-задач
Не желайте странного, и не будет у вас головной боли чтобы достичь этого странного.
Тем более что окажется что оно вам и не нужно было, странное это.