Использование представлений для всего - сумасшедшая идея?

Question

Я работаю над созданием базы данных MySQL и думаю, что вместо того, чтобы кодировать кучу сложных запросов на соединение во внешнем интерфейсе, я создам представление для всех необходимых запросов, а затем получу весь код внешнего интерфейса.делать простые SELECT whatever FROM some_view WHERE something=5; запросы.

Это кажется хорошей идеей, поскольку она абстрагирует базовую схему, поэтому внешнему интерфейсу не нужно знать об этом и учитывая, что MySQL может объединять представления в запросы, я думаю, это будет не менее эффективно.чем более прямое решение.

Теперь на вопрос: Это глупая идея по какой-то причине, которую я не замечаю?

---

Примечание: это будет только два уровня глубины, ei представления будут ссылаться только на таблицы, а не представления.

Answer 1

Представления могут упростить объем текста, необходимый для создания запроса, но наложение слоев друг на друга является плохой практикой .

Эта инкапсуляция также рискует плохо выполнять запросы, потому что представления должны быть выполнены до того, как они смогут соединиться друг с другом - вся эта логика внутри может не соответствовать тому, что вам нужно для конечного результата, поэтому ленивость может легко означать запрос, который не работает так, как должен.

Поскольку представления - это запросы, которые выполняются только при вызове, вы не будете знать о пропущенных ссылках до времени выполнения.

Имейте в виду, что при использовании SELECT * в представлении база данных захватывает список столбцов при выполнении оператора CREATE VIEW - если столбцы изменяются, вам необходимо обновить представление, чтобы получить изменения.

Также нет разницы в производительности между представлением и выполнением запроса, на котором основано представление. За исключением материализованных представлений (которые MySQL не поддерживает), представления являются просто подготовленным утверждением. Если достаточно просто, предикаты WHERE могут быть вставлены из FROM view WHERE .... во внутренний запрос, но это означает, что функции не используются и ненадежны.

Заключение

Хорошо, но будьте осторожны.

Answer 2

При условии, что вы не вкладываете свои взгляды, я считаю, что это хорошая идея для кодирования доступа к данным таким способом. (Помните, что MS годами говорила, что CRUD должен выполняться через sp)

Не все согласны со мной, но мне нравится абстракция модели данных таким образом ... думать о вызовах БД как о методах. Хотя я склонен делать это с помощью хранимых процедур, это упрощает изменения модели данных и обеспечивает прозрачность оптимизации запросов для приложения, потребляющего данные.

Лично я думаю, что это заставляет разработчиков приложений обращаться с SQL как с декларативным (как и предполагалось), поскольку вы лишаете их возможности обрабатывать его иначе.