|
|
|
виртуальная таблица
|
|||
|---|---|---|---|
|
#18+
Добрый день, Есть такая задача Существует таблица items , а так же существует "чужая" таблица items_remote Возможно ли написать некое правило, что бы при запросе таблицы items на несуществующие в ней ID, запрашивалась таблица items_remote ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2014, 15:21:19 |
|
||
|
виртуальная таблица
|
|||
|---|---|---|---|
|
#18+
lamo102, если структура таблиц похожая, то можно items_remote унаследовать от items, тогда при обычных запросах в родительскую таблицу будут данные с обеих таблиц подгружаться. можно и view создать, в котором объединить обе таблицы. естественно, желательно чтобы первичные ключи у таблиц не пересекались. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2014, 18:04:07 |
|
||
|
виртуальная таблица
|
|||
|---|---|---|---|
|
#18+
Это "чужая" таблица. FOREIGN table. От нее ничего не унаследуешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2014, 18:53:49 |
|
||
|
виртуальная таблица
|
|||
|---|---|---|---|
|
#18+
lamo102Это "чужая" таблица. FOREIGN table. От нее ничего не унаследуешь. то что вы хотите сделать - сделать нельзя (в той постановке как вы задачу поставили). уж тем более не понятно что в вашей постановке вопроса отвечать на запроса select * from items; только из основной таблицы или все из основной и FOREIGN или еще как... Можно сделать хранимку которая будет делать то что вы запросили (но прийдется вызывать select * from get_item(id) вместо select * from items where id=1) есть еще вариант через view но он я боюсь сильно хуже по производительности будет. --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 05:48:01 |
|
||
|
виртуальная таблица
|
|||
|---|---|---|---|
|
#18+
Суть в том, что запрос изменить нельзя, так как это небольшой "колхоз" над чужим софтом. на select * - не столь важно, софт не делает таких запросов Он делает запрос - select * from items where id IN (x,y,z) . Можно ли каким-то образом "распарсить" эти ИД с помощью хранимки или расширения и синхронизировать из items_remote в items эти записи до того как он вернет их ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 11:40:31 |
|
||
|
виртуальная таблица
|
|||
|---|---|---|---|
|
#18+
lamo102, напишите вьюху с запросом вида Код: sql 1. 2. 3. но скорее всего вас не устроит скорость работы. вообще же стоит идти от обратного - ловить изменения на уровне чужой БД (а там хоть postgresql?) и мержить их в локальную. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 12:01:12 |
|
||
|
виртуальная таблица
|
|||
|---|---|---|---|
|
#18+
lamo102Суть в том, что запрос изменить нельзя, так как это небольшой "колхоз" над чужим софтом. на select * - не столь важно, софт не делает таких запросов Он делает запрос - select * from items where id IN (x,y,z) . Можно ли каким-то образом "распарсить" эти ИД с помощью хранимки или расширения и синхронизировать из items_remote в items эти записи до того как он вернет их ? нет нельзя... можно переделать items на view но будет очень меденно и update/delete/insert по таблице items сломаются ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 14:02:08 |
|
||
|
виртуальная таблица
|
|||
|---|---|---|---|
|
#18+
lamo102Добрый день, Есть такая задача Существует таблица items , а так же существует "чужая" таблица items_remote Возможно ли написать некое правило, что бы при запросе таблицы items на несуществующие в ней ID, запрашивалась таблица items_remote ? Сделай регулярный процесс обновления items из items_remote недостающими данными!! Это самое верное и быстрое решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 15:01:22 |
|
||
|
виртуальная таблица
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, подскажите пожалуйста, почему через вьюху будет сильно медленнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2014, 19:51:17 |
|
||
|
виртуальная таблица
|
|||
|---|---|---|---|
|
#18+
По FOREIGN table недоступна статистика, поэтому в общем случае оптимизатор запросов не сможет создать хороший план. Попробуйте создать view items с триггером INSTEAD OF для закрытия проблем update/delete/insert по таблице items, а внутри view делайте либо LEFT JOIN, либо UNION ALL с not exists... Если скорость устроит,то все хорошо. Ели нет, то для производительности лучше (как уже советовали) иметь локальную копию нужных данных из items_remote, и регулярно ее обновлять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2014, 23:31:41 |
|
||
|
виртуальная таблица
|
|||
|---|---|---|---|
|
#18+
Sergei.AgalakovПо FOREIGN table недоступна статистика, поэтому в общем случае оптимизатор запросов не сможет создать хороший план.Вроде доступна: http://www.postgresql.org/docs/9.3/static/postgres-fdw.html F.31.1.3. Cost Estimation Options ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 00:53:07 |
|
||
|
виртуальная таблица
|
|||
|---|---|---|---|
|
#18+
Гость_0Sergei.AgalakovПо FOREIGN table недоступна статистика, поэтому в общем случае оптимизатор запросов не сможет создать хороший план.Вроде доступна: http://www.postgresql.org/docs/9.3/static/postgres-fdw.html F.31.1.3. Cost Estimation Optionsдоступна (даже для чужеродной), а толку ? если ора таблицу ешё можно хитро принудить попользовать индекс (для min/max хотя бы) (следя тщательно за планами и ора-запросами в них). то от родного пж такая же форейгн-тыйбла будет вести себя как куча субстанции, без ындексов (все выберется на, потом будет взят агрегат от всего выбратого, на). по крайней - предыдущий последнему враппер вел себя так. (т.е проще руками в дблинке шаманить, чем заставит эту радость вести себя прилично). а локальную копию можно, хотя бы, отиндексировать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2014, 01:17:17 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=126&tid=1998601]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
786ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 243ms |
| total: | 1117ms |

| 0 / 0 |
