MySQL CREATE VIEW, нацеленный на имя переменной таблицы (имена столбцов)

Question

Я хочу определить множество представлений, но модель БД меняется, поэтому мне пришло в голову несколько идей / вопросов:

1. Есть ли способ в MySQL 8 создать представление, которое после FROM не имеет жестко закодированного имени таблицы, но имя таблицы является переменной?

2. Можно ли создать представление с жестко закодированным именем таблицы после FROM, но имена столбцов являются переменными?

3. Является ли хорошей идеей создать представление (A), которое после FROM предназначается не для конкретного (жестко заданного) имени таблицы, а для другого представления (B), которое работает в качестве промежуточной таблицы перевода, которая просто выбирает данные из таблицу (C) и возвращает ее в представление (A) со столбцами, расположенными по псевдониму так, как их ожидает первое представление (A). Короче говоря, второе представление (B) просто действует как переводчик между (A) <=> (C) в терминах имени таблицы и имен столбцов?

Причина, по которой я думаю об этих решениях, заключается в том, что я хочу иметь набор табличных представлений для приложения, которое подключается к БД. И они не должны меняться, но изменится вся модель БД.

Я не хочу касаться представлений доступа, которые являются интерфейсом для приложения, а скорее определяю некоторые соединения между столбцами и таблицами за представлением интерфейса приложения. Также для модели БД потребуются некоторые другие представления для выполнения общих расчетов / отчетов, но данные исходной таблицы для расчетов / отчетов будут со временем изменяться (имена столбцов, имена таблиц).

4. Можно ли применить другой подход? Как вы справляетесь со случаями изменения имен таблиц, имен столбцов в БД без нарушения уже реализованных отчетов и других функций, которые ожидают определенных имен таблиц и столбцов?

Я использую MySQL 8.

Answer 1

1. Нет
2. Нет
3. Вы, безусловно, можете сделать это, и весьма часто иметь представления, основанные на представлениях.Является ли это хорошей идеей, это вопрос мнения.
4. Вы не можете полностью защитить приложения от изменений базовой модели данных.Если вы вводите, удаляете или изменяете столбцы / столбцы в модели данных, вы должны отразить их в отчетах / приложениях, поскольку доступный контент изменится.Если таблица или столбец переименовывается, это можно скрыть от приложения с помощью представлений.Однако, если переименование не так важно, чтобы вы отразили это в отчете / приложении, возникает вопрос, зачем вам нужно переименовывать столбец.

Если ваша структура данных меняется так частотогда продукт на основе SQL может оказаться для вас неподходящим, поскольку SQL требует довольно жесткого определения структуры данных.Возможно, вам придется рассмотреть решение NoSql вместо этого, которое обеспечивает большую гибкость в схеме базы данных.Однако изменения структуры данных будут влиять на приложение / отчетность, даже если вы используете решение NoSql.