Информация о структуре таблиц

[algo]

Информация о структуре таблиц

Как можно сделать информацию о структуре (список полей хотя бы) таблице известной скрипту?

Делать постоянные запросы из системных каталогов кажется (?) неэффективным.

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

P.S
База стоит на машине, отдельной от веб-сервера.

P.P.S
PHP 5.1-dev
PostgreSQL 8.0.2

 

[Sad Spirit]

Автор оригинала: algo
Как можно сделать информацию о структуре (список полей хотя бы) таблице известной скрипту?

Делать постоянные запросы из системных каталогов кажется (?) неэффективным.

Можно ли организовать механизм уведомления об изменениях DDL, так что хранится лишь некий редко обновляемый кэш ?

Я как-то слабо понимаю постановку задачи: что, схема базы изменяется часто и кроме того не вполне централизованно?

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

 

[algo]

Автор оригинала: Sad Spirit
Я как-то слабо понимаю постановку задачи: что, схема базы изменяется часто и кроме того не вполне централизованно?

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

Проект находится в разработке, так что схема базы действительно меняется часто.

Если можно сделать обновление настроек автоматически, то лучше это сделать, чем запускать каждый раз апдейт руками.
DDL идет через разные интерфейсы, включая EMS PG Manager, прописать вызов апдейтилки туда довольно сложно.


----------------------
Есть такой вариант:

Стоит опция log_statemenets = 'ddl'.
Лог производится syslog'ом через пайп в мой скрипт (запускается один раз, дальше висит, к БД коннект 1 раз).

Мой скрипт входящие логи смотрит на предмет ALTER, CREATE, DROP statements. Если он находит что-то из этого, то апдейтит табличку из одного элемента, ставит его текущей датой.

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

Проблема: если в SP генерится временная таблица, которая нигде больше не нужна - зачем апдейтить кэш?
Решение: сделать список таблиц, подлежащих трэкингу.
Выводить предупреждение, если программист пытается получить информацию из кэша о не отслеживаемой таблице

DDL statements во время работы скрипта не обновляют кэш, и это нормально, ибо рабочие скрипты над постоянными(трекающимися) таблицами DDL statements не вызывают.

 

[Sad Spirit]

Автор оригинала: algo
Проект находится в разработке, так что схема базы действительно меняется часто.

Если проект ещё в разработке, то не вижу особого смысла напрягаться: можно просто дёргать каждый раз системные таблицы.

В production-то схема меняться уже не будет?

 

[neko]

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

можно для облегчения процедуры поставить newsysview с фаундри

-~{}~ 20.04.05 11:15:

вообще на такие вещи заморачиваться без предварительного тестирования скорости это ужасная идея

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

 

[algo]

Автор оригинала: Sad Spirit
Если проект ещё в разработке, то не вижу особого смысла напрягаться: можно просто дёргать каждый раз системные таблицы.

В production-то схема меняться уже не будет?

Не будет, но минус здесь в наличии "подводного камня".
Если я поменяю что-то(редко, но вполне возможно), то нужно будет тут же обновить информацию о структуре.
Причем это должно делаться мгновенно, в единой транзакции, иначе система глюканет между реальным DDL и апдейтом информации.

-~{}~ 20.04.05 11:41:

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

вообще на такие вещи заморачиваться без предварительного тестирования скорости это ужасная идея

Да, интересно, насколько такое накладно.
Вообще, вся информация выдирается одним запросом.

Пусть таблиц с видами - штук 150. Какова будет нагрузка: послать запрос и распарсить результат в PHP-структуру на месте?
По трафику, похоже, порядочно выходит.

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

 

[neko]

42