Представления?

[Absinthe]

Собственно вопрос мне кажется глупым, но ответа не нашел.
Есть view в СУБД.

У меня как-то не было необходимости в их использовании - проще все джойны/условия в запросе написать.
Да и AR и прочие сущности веб-приложения не поощряют вьюхи.

Вопрос: для чего они нужны на практике в вебе?

 

[флоппик]

На практике в вебе, особенно в мускуле, нафиг не нужны

Можно правда использовать для рефакторинга — когда ломаешь какую-то табличку, ее можно эмулировать вьюхой, пока чинишь/меняешь код.

 

[Вурдалак]

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

 

[Absinthe]

Кстати, вот подумалось, в них же еще можно insert/update делать.
Правда тут тоже возникает вопрос "зачем?"

Вобщем, это костыль такой, как понимаю, когда не хочется нормально что-то править.

 

[флоппик]

Кстати, вот подумалось, в них же еще можно insert/update делать.
Правда тут тоже возникает вопрос "зачем?"

Вобщем, это костыль такой, как понимаю, когда не хочется нормально что-то править.

Не во все виды можно делать insert/update.
Ну и это не костыль. Это вещь необходимая для переноса некоторой логики с приложения на саму БД. Например, если с одной БД работают разные приложения, разных разрабочиков/фирм. Тогда общая логика, вынесенная в область базы, вполне оправдана. Например, в случае наличия очень большого количества разных интерфейсов отображения этих данных.

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

 

[Absinthe]

Тогда общая логика, вынесенная в область базы, вполне оправдана.

А ты с таким работал?
У меня сейчас достался по наследству сайт, там 400+ функций в базе.
Вменяемая отладка отсутствует как класс.
Работать крайне неудобно. Софта нормального для работы с базой нет, есть либо с интерфесом, который писали ногами в лучшем случае(pgadmin), либо не всегда рабочий(EMS SQL Studio).
А, самое главное, я не понял, зачем эта хрень в базе, если задача этого сайтика - обслуживать API-запросы, и напрямую к базе никто другой не попадет.

Какой смысл вносить логику в базу, если можно сделать API-прослойку и сэкономить кучу времени и сил?

 

[флоппик]

А ты с таким работал?

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

 

[fixxxer]

Для оракла и MS SQL есть удобные средства разработки и отладки. В постгресе, к сожалению, с этим очень слабо.

А вообще оба подхода, как отдельный аппсервер, так и СУБД в этой роли имеют право на существование.

Касаемо view, основное применение, на мой взгляд, это materialized views, которыми можно заменить написание всякой агрегации. Обычные вьюхи можно использовать разве что как своего рода "адаптеры" для совместимости.

 

[Absinthe]

А вообще оба подхода, как отдельный аппсервер, так и СУБД в этой роли имеют право на существование.

Но не в мускуле/постгрессе же. Как я понимаю, в других СУБД есть отладчики и т.д.

Касаемо view, основное применение, на мой взгляд, это materialized views, которыми можно заменить написание всякой агрегации.

Но не в мускуле/постгрессе же. Как я понимаю, в других СУБД это реализовано на уровне SQL.

P.S. Под другими СУБД я имел ввиду не всякие Firebird, естественно, а MS SQL/Oracle

 

[fixxxer]

угу

 

[MiksIr]

В постгресе есть дебаг pl/pgsql
materialized view, конечно, в зачаточном состоянии...

 

[fixxxer]

есть, уровня var_dump, а клиенты все убогие в этом плане (или я не знаю о хороших)

 

[флоппик]

А я в оракле тащился с этого

 

[флоппик]

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

 

[Absinthe]

Если честно, то я до этого думал, что в MS SQL/Oracle такая же жопа, как в Firebird/Postgres, а в них, оказывается, даже отладчик есть(ирония).
Что-то грустно с опенсорсом.