youngmysteriouslight
@youngmysteriouslight
ТК, ТТ, JS, FP, WM

Как в реляционных СУБД работать с зависимыми (виртуальными) отношениями, можно ли с ними использовать внешние ключи?

Допустим, есть две таблицы.
Первая (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 две недели. Возможно, вопрос простой, но я не знаю, по каким словам гуглить.
  • Вопрос задан
  • 42 просмотра
Решения вопроса 1
https://dev.mysql.com/doc/refman/5.7/en/views.html
MySQL supports views, including updatable views. Views are stored queries that when invoked produce a result set. A view acts as a virtual table.

Вообще гуглите про представления (views) и в частности про материализованные представления (materialized views), это боольшая тема про зависимые таблицы и их согласования.
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.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@res2001
Developer, ex-admin
Гуглите про нормализацию базы данных.
1.Вам нужно вынести name в отдельную таблицу, например назовем ее emploee, в которой будет просто список имен, возможно с какой-либо другой информацией и id, уникальный для каждого имени.
2.Тогда в SAL поля name не будет, а будет id_emploee
3.Меняете имя в таблице employee, автоматически оно поменяется везде, т.к. везде у вас будет фигурировать только id_emploee, а не само имя.

Соответственно, там где нужно имя, нужно в запросах делать join с таблицей employee. Но в запросе из примера, можно и не делать join, а группировать по id_emploee, что будет работать гораздо быстрее, чем группировка по текстовому полю.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы
Badoo Development Москва
от 140 000 до 180 000 руб.
Badoo Development Москва
от 180 000 до 250 000 руб.
Делис Инфо Москва
от 70 000 до 80 000 руб.
18 авг. 2018, в 17:54
6000 руб./за проект
18 авг. 2018, в 16:00
60000 руб./за проект