LINUX.ORG.RU

postgresql наследование таблиц


0

1

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

итого общие параметры вынесены в отдельную таблицу:

id              SERIAL PRIMARY KEY,          -- id записи
happen          TIMESTAMP NOT NULL,          -- когда произошло событие
processed       BOOL NOT NULL DEFAULT false, -- данное событие обработано

события после того как накопятся в должном количестве еще и обсчитываются скопом, отсюда последний флаг.

и вот с постгрисом оказалось удобно очень, что родительская таблица позволяет выбрать одним простым запросом «все необработанные записи» из всех таблиц вообще.

но тут очень не хватает еще и знания в какой из дочерних таблиц лежат эти данные.

можно ли как-то SELECT'ом по родительской таблице получить в выборке дополнительный столбик - имя дочерней таблицы?

★★

Ответ на: комментарий от guilder

в mysql много чего нет постгрисового. сейчас начал только с постгрисом возиться - дык рулез какой-то по сравнению с мускулем :)

правда некоторых вещей в нем нет INSERT ON DUPLICATE KEY например. можно создать правило, будет такой инсерт эмулировать, но не будет справляться с дублями внутри самого такого инсерта. а так все остальное - руль. например структуры и массивы (в т.ч. структур) в виде столбиков, процедуры на перле, возможность при INSERT сразу и обратно получить вставленные данные итп итд

кроме того я тут сваял тест: у меня вот эти самые устройства копят данные в БД. на тестовом хосте (десктоп слабая машинка) mysql на innodb делает примерно 200 инсертов в секунду. postgresql (при том что я в его админинге, в отличие от mysql ни бум бум еще, просто поставил) - делает 500. мне прямо это все подозрительным кажется. не бывает столько халявы-то зараз. где-то видимо расплатиться все равно придется :)

rsync ★★ ()

Конечно можно. Заведи ещё одно общее поле с типом устройства которое одновременно будет неявно указывать и на таблицу.

anonymous ()
Ответ на: комментарий от anonymous

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

rsync ★★ ()
Ответ на: комментарий от rsync

Попробуй спроси на sql.ru, но афаик иначе нельзя.

anonymous ()

http://www.postgresql.org/docs/9.0/static/ddl-inherit.html

In some cases you might wish to know which table a particular row originated from. There is a system column called tableoid in each table which can tell you the originating table:

SELECT c.tableoid, c.name, c.altitude
FROM cities c
WHERE c.altitude > 500;
which returns:
 tableoid |   name    | altitude
----------+-----------+----------
   139793 | Las Vegas |     2174
   139793 | Mariposa  |     1953
   139798 | Madison   |      845
(If you try to reproduce this example, you will probably get different numeric OIDs.) By doing a join with pg_class you can see the actual table names:
SELECT p.relname, c.name, c.altitude
FROM cities c, pg_class p
WHERE c.altitude > 500 AND c.tableoid = p.oid;
which returns:
 relname  |   name    | altitude
----------+-----------+----------
 cities   | Las Vegas |     2174
 cities   | Mariposa  |     1953
 capitals | Madison   |      845

anonymous ()

чую можно по ссылкам в FK но пока на практике не применял.

exception13 ★★★★★ ()
Ответ на: комментарий от anonymous

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

rsync ★★ ()
Ответ на: комментарий от rsync

> где-то видимо расплатиться все равно придется
не знаю, как там сейчас, но раньше расплачиваться приходилось при первом же vacuum :)
Причём никакой autovacuum не помогал.

SOmni ★★ ()
Ответ на: комментарий от rsync

Недопол. Что значит — не пишем, а только читаем? Индекс при записи — вообще исключительно головная боль, кою терпят исключительно из-за выигрыша при чтении. Или ты о том, что родительская таблица пустая? Тогда от индексов толку, скажем так, ровно столько же, сколько и от полей оной таблицы — они нужны исключительно для планирования запросов...

fat-II ()
Ответ на: комментарий от rsync

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

fat-II ()
Ответ на: комментарий от fat-II

Что значит — не пишем, а только читаем?

поскольку родительская таблица содержит только метаданные (данные проходящие сквозняком сквозь все таблицы), то запись в нее смысла не имеет.

а вот чтение имеет (запрос вида: «а в каких у нас таблицах остались необработанные данные?»)

и, насколько я понимаю, запрос из родительской таблицы он неявно преобразует в запрос из таблицы 1 объединенный с запросом из таблицы 2 и так далее

то есть индексы по родительской таблицы не нужны, если она не содержит ни одной записи?

rsync ★★ ()
Ответ на: комментарий от rsync

Ни индексы, ни внешние ключи, ни первичные ключы, ни констрайнты не имеют никакого значения на родительской таблице если вы не храните там данные.

SELECT * from parent аналогичен

select * from parent
union all
select * from child_1
union all
select * from child_2
union all
...
union all
select * from child_n

PS: посмотрите еще про constraint exclusion - незаменимая вешь для таблиц > 10Gb

grassmeister ()
Ответ на: комментарий от rsync

Таки да. Перечёл доки. Не наследуются. Только check и not bull constraints. Действительно, индексы смысла не имеют.

fat-II ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.