Я пытаюсь отменить нормализацию некоторых данных в представлении кросс-таблицы, которое динамически генерируется на сервере MySQL.Из-за полезного ответа здесь я успешно создал хранимую процедуру, которая генерирует это представление кросс-таблицы.
Это моя процедура:
DELIMITER $$
CREATE PROCEDURE `PartFlow`.`DimMatTab` ()
BEGIN
SET @cols = (
SELECT
GROUP_CONCAT(DISTINCT
CONCAT(
'\nSUM(IF(dimension_id = ',
dimension_id,
', value, NULL)) AS ',
name
)
) as column_list
FROM PartFlow.tDimMatMap
JOIN PartFlow.tDimension
on tDimension.id_dimension = tDimMatMap.dimension_id
);
SET @sql = CONCAT(
'CREATE OR REPLACE VIEW `PartFlow`.`vDimMatTab` AS '
'SELECT material_id, ',
@cols,
' FROM tDimMatMap ',
'GROUP BY material_id;');
PREPARE stmt FROM @sql;
EXECUTE stmt;
END
, которая производитпредставление, содержащее этот запрос:
select
`material_id`
,sum(if((`dimension_id` = 2),`value`,NULL)) AS `Width`
,sum(if((`dimension_id` = 3),`value`,NULL)) AS `Height`
,sum(if((`dimension_id` = 5),`value`,NULL)) AS `Thickness`
from `PartFlow`.`tDimMatMap`
group by `material_id`
Я бы хотел, чтобы представление обновлялось при любых изменениях в tDimMatMap, чтобы представление всегда содержало правильные столбцы кросс-таблицы.Я попытался вызвать процедуру при любой вставке, обновлении или удалении в этой исходной таблице.Вот мой код триггера:
create trigger update_view_iMat after insert on tDimMatMap
for each row call DimMatTab();$$
create trigger update_view_uMat after update on tDimMatMap
for each row call DimMatTab();$$
create trigger update_view_dMat after delete on tDimMatMap
for each row call DimMatTab();$$
На мой взгляд, это идеальная настройка, но когда я пытаюсь редактировать таблицу tDimMatMap, я получаю сообщение об ошибке: «Динамический SQL не разрешен в хранимой функцииили триггер ".Есть ли способ обойти это?Я подхожу к проблеме под неправильным углом?Я просто хочу убедиться, что мое представление кросс-таблицы всегда содержит столбец для каждого уникального «измерения_идентификатора», указанного в таблице tDimMatMap.
Я обращаюсь к этим данным из нескольких клиентских интерфейсов, поэтому это централизованное решение кажется правильным,Я уверен, что некоторые скажут, что я должен сгенерировать свой код SQL вне сервера или запустить процедуру для сбора данных без создания представления, но я не могу динамически обновлять это представление в моих клиентах, а также не могу запрашивать, вызываяпроцедура в рамках моих клиентов.Наиболее важно, что это представление будет объединено с другими представлениями и таблицами в некоторых приложениях, поэтому создание представления довольно важно.