Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
View на все поля таблицы
|
|||
|---|---|---|---|
|
#18+
Вопрос прост: почему PostgreSQL при создании view на все поля таблицы, а именно create view "vw_Test" as select * from "tbl_Test" создает мне view с перечислением всех полей таблицы? Зачем мне это нужно? Я не хочу в будущем переделывать view каждый раз после внесения изменений в таблицу. Как создать view на все поля таблицы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2007, 17:24 |
|
||
|
View на все поля таблицы
|
|||
|---|---|---|---|
|
#18+
Вроде как Никак. Так как при создании представления постгрес создаёт и соответствующий тип данных, который связан с представлением и определяет какие поля возвращает представление. А в типе данных поля должны быть четко прописаны. Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2007, 17:41 |
|
||
|
View на все поля таблицы
|
|||
|---|---|---|---|
|
#18+
Dan BlackВроде как Никак. Так как при создании представления постгрес создаёт и соответствующий тип данных, который связан с представлением и определяет какие поля возвращает представление. А в типе данных поля должны быть четко прописаны. Код: plaintext 1. не совсем так docsViews in PostgreSQL are implemented using the rule system. In fact, there is essentially no difference between Код: plaintext 1. Код: plaintext 1. 2. т.е. создается таблица, аналогичная структуре представления, на которую (таблицу) вешается rule ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2007, 18:23 |
|
||
|
View на все поля таблицы
|
|||
|---|---|---|---|
|
#18+
А выражение "(same column list as mytab)" никого не смущает? CREATE TABLE myview (same column list as mytab) ; CREATE RULE "_RETURN" AS ON SELECT TO myview DO INSTEAD SELECT * FROM mytab; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2007, 18:50 |
|
||
|
View на все поля таблицы
|
|||
|---|---|---|---|
|
#18+
Да и выражение "DO INSTEAD SELECT * FROM mytab;" само говорит за себя. Проверил я этот способ. Postgre не способен анализировать relation, а тупо отображает те поля, которые были на момент создания представления. Итог: очень убого. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2007, 20:34 |
|
||
|
View на все поля таблицы
|
|||
|---|---|---|---|
|
#18+
А если подумать - то зачем нужны вьюшки - ограничивать доступ к данным. Следовательно - нах мне резиновая структура вьюшки, которая будет жрать дополнительные ресурсы на синхнонизацию с изменившейся структурой таблиц? Ну вот пример - есть прайс и есть вьюшки для общего доступа скажем со для вебстранички - без колонок "Диллер1","Диллер2" , но вот я добавляю в таблицу прайса колонку "Диллер3". Теперь, если мне нужно её показать - делаю это явным образом. В вашем же варианте - мне бы пришлось удалять эту и все добавляемые колонки из кучи вьюшек в кооторых они явно излишни. В итоге получается что данная постановка вопроса не убожество а вполне обоснованный подход. А запросы "select *..." - извините, но мн кажется это признак лени или незнания структуры базы. Ладно если я подобное пихаю в Sqlplus/psql - и то - там где база новая и я непомню/не знаю что там а в структуру лезть лениво/нетвремени... Но пихать подобное в код приложения - еще раз сорри за резкость - бред достойный первокурсника. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2007, 06:02 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=292&tid=2005241]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
46ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
2ms |
| others: | 249ms |
| total: | 394ms |

| 0 / 0 |
