Как в реляционных СУБД работать с зависимыми (виртуальными) отношениями, можно ли с ними использовать внешние ключи?
Допустим, есть две таблицы.
Первая (SAL) содержит ключ id, поле name, поле year, поле salary. Зарплата человека в определённый год, трёхстороннее отношение.
Вторая (DEG) содержит ключ id, поле name, поле ed_degree. Отношение между человеком и чем-то (напр., уч. степенями).
В обоих отношениях name не является ключом.
В рамках задачи возникает необходимость работать с отношением, порожденным SAL. Например, SELECT name, MAX(salary) FROM SAL GROUP BY name (ключ name).
Это отношение зависит от SAL, меняется SAL — меняется это отношение. Но пока оно оформлено в виде SQL-запроса, оно
Вопрос 1. Как в MySQL лучше работать с этим отношением? Можно ли ему дать собственное название? Очевидно, я не могу создать таблицу с (name, salary), потому что тогда не будет гарантирована её согласованность с SAL, разве только (1) после каждого изменения SAL я буду вызывать обновление этой зависимой таблицы и (2) не буду изменять её когда бы то ни было ещё. С другой стороны, может, существуют способы кешировать результат запроса, всё-таки это должно быть частой задачей.
Вопрос 2. Можно ли указать, что name в DEG является внешним ключом этого виртуального/зависимого отношения?
P.S. Мой опыт работы с SQL две недели. Возможно, вопрос простой, но я не знаю, по каким словам гуглить.
Поле name идентифицирует человека. Если это строка, то предполагается, что нет полных тезок. Если это число, то значит, это внешний ключ для некой таблицы с данными о людях.
Поле id в двух таблицах нужно лишь затем, чтобы был одноаттрибутный ключ.
The process of setting up a materialized view is sometimes called materialization. This is a form of caching the results of a query, similar to memoization of the value of a function in functional languages, and it is sometimes described as a form of precomputation. As with other forms of precomputation, database users typically use materialized views for performance reasons, i.e. as a form of optimization.
MySQL doesn't support materialized views natively, but workarounds can be implemented by using triggers or stored procedures or by using the open-source application Flexviews
Гуглите про нормализацию базы данных.
1.Вам нужно вынести name в отдельную таблицу, например назовем ее emploee, в которой будет просто список имен, возможно с какой-либо другой информацией и id, уникальный для каждого имени.
2.Тогда в SAL поля name не будет, а будет id_emploee
3.Меняете имя в таблице employee, автоматически оно поменяется везде, т.к. везде у вас будет фигурировать только id_emploee, а не само имя.
Соответственно, там где нужно имя, нужно в запросах делать join с таблицей employee. Но в запросе из примера, можно и не делать join, а группировать по id_emploee, что будет работать гораздо быстрее, чем группировка по текстовому полю.
Нормализация (по крайней мере, до НФ3) проведена. Вопрос был о другом, предложенные преобразования его не решают (мысленно замените все name в исходном вопросе на id_emploee).
youngmysteriouslight, Не знаю, что у вас там проведено, но наличие поля name в SAL и DEG говорит само за себя.
А на счет первого вопроса - как выше писал Станислав Макаров вам поможет view. view вы не должны менять, только исходную таблицу. В "нормальных" SQL серверах кэшированием view занимаются сами сервера автоматически, как работает MySQL - не знаю.
Средний
