Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Дубликаты в primary key parent-таблицы / 15 сообщений из 15, страница 1 из 1
21.02.2013, 23:47:40
    #38161566
DmGr
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
CREATE TABLE public.parent
(
  recordid integer NOT NULL,
  CONSTRAINT pk_parent_recordid PRIMARY KEY (recordid)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.parent
  OWNER TO postgres;

CREATE TABLE public.child1
(
  test1 integer DEFAULT 0,
  CONSTRAINT pk_child1_recordid PRIMARY KEY (recordid)
)
INHERITS (public.parent)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.child1
  OWNER TO postgres;

CREATE TABLE public.child2
(
  test2 integer DEFAULT 0,
  CONSTRAINT pk_child2_recordid PRIMARY KEY (recordid)
)
INHERITS (public.parent)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.child2
  OWNER TO postgres;

insert into public.child1 (recordid, test1) values (1,2);
insert into public.child2 (recordid, test2) values (1,2);
select * from public.parent;


Получаю две одинаковые записи

Я правильно понимаю, что CONSTRAINT pk_parent_recordid будет проверять только для строк ЯВНО вставленных в parent?
И все проверки для child таблиц будут проигнорированы?
...
Рейтинг: 0 / 0
22.02.2013, 02:14:15
    #38161631
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
DmGr
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
CREATE TABLE public.parent
(
  recordid integer NOT NULL,
  CONSTRAINT pk_parent_recordid PRIMARY KEY (recordid)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.parent
  OWNER TO postgres;

CREATE TABLE public.child1
(
  test1 integer DEFAULT 0,
  CONSTRAINT pk_child1_recordid PRIMARY KEY (recordid)
)
INHERITS (public.parent)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.child1
  OWNER TO postgres;

CREATE TABLE public.child2
(
  test2 integer DEFAULT 0,
  CONSTRAINT pk_child2_recordid PRIMARY KEY (recordid)
)
INHERITS (public.parent)
WITH (
  OIDS=FALSE
);
ALTER TABLE public.child2
  OWNER TO postgres;

insert into public.child1 (recordid, test1) values (1,2);
insert into public.child2 (recordid, test2) values (1,2);
select * from public.parent;


Получаю две одинаковые записи

Я правильно понимаю, что CONSTRAINT pk_parent_recordid будет проверять только для строк ЯВНО вставленных в parent?
И все проверки для child таблиц будут проигнорированы?

да правильно
...
Рейтинг: 0 / 0
22.02.2013, 08:33:59
    #38161701
кактотаг
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
Maxim BogukDmGr[src PLSQL]
<>
Я правильно понимаю, что CONSTRAINT pk_parent_recordid будет проверять только для строк ЯВНО вставленных в parent?
И все проверки для child таблиц будут проигнорированы?

да правильно
нет неправильно
"все проверки" не будут проигнорированы,
просто в чайлд 1 своя свадьба (читай - "унаследованный" ПК), в чайлд2 - своя, а в парент - наоборот третья (сс).

т.е. никаких кросс-проверок нет, и пока кросс-таблицу не создать ручками, обвязав ФК(что чревато) (или пока разрабы ПЖ это не изменят, а они не собираются) - это так и будет.


кактотаг
...
Рейтинг: 0 / 0
22.02.2013, 09:34:34
    #38161744
DmGr
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
Подскажите тогда, как грамотно сделать ограничение уникальности для parent, с учетом, что все записи вставляются в child?
...
Рейтинг: 0 / 0
22.02.2013, 10:03:03
    #38161776
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
DmGrПодскажите тогда, как грамотно сделать ограничение уникальности для parent, с учетом, что все записи вставляются в child?

эффективно надежно и быстро - никак...

PS: кстати " пока кросс-таблицу не создать ручками, обвязав ФК(что чревато) " - совершенно не защищает от того что между партициями будут дубликаты (т.е. максимум некоторая защита если триггера не сломаны)...
но это хоть какое то решение да...
...
Рейтинг: 0 / 0
22.02.2013, 11:22:33
    #38161901
DmGr
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
А можно поподробнее...

И почему разработчики не собираются кросс-проверки в PG делать?
Ткните ссылкой - почитать.
...
Рейтинг: 0 / 0
22.02.2013, 12:14:40
    #38162008
DmGr
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
Сейчас посмотрел в доках, долистал до 7.4...
inherit
This deficiency will probably be fixed in some future release.

Неужели это вообще никому не нужно?
Как же люди изворачиваются то?
Или наследование - это костыль, которым лучше вообще не пользоваться?
...
Рейтинг: 0 / 0
22.02.2013, 12:35:17
    #38162046
Misha Tyurin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
DmGr,

это иногда удобный костыль НЕ для случаев, когда нужен форейн кей.

никто не пользуется похоже, да
...
Рейтинг: 0 / 0
22.02.2013, 12:39:16
    #38162059
DmGr
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
Misha Tyurin
Да фиг с ним с FK, хотя бы primary key работал :(
...
Рейтинг: 0 / 0
22.02.2013, 12:44:02
    #38162071
Misha Tyurin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
DmGr,

ну и пк туда же )
...
Рейтинг: 0 / 0
22.02.2013, 13:38:42
    #38162197
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
DmGrСейчас посмотрел в доках, долистал до 7.4...
inherit
This deficiency will probably be fixed in some future release.

Неужели это вообще никому не нужно?
Как же люди изворачиваются то?
Или наследование - это костыль, которым лучше вообще не пользоваться?

костыль... в основном для

1)архива отчетов/операций...
2)или там где уникальность по PK идет а он из sequence генерируется...
3)или там где таблица уже под сотню гигов и ее надо резать на куски любой ценой ради какой то управляемости хотя бы...

а зачем вам вообще партиционирование то в вашей задаче?
если вариант 1 - то зачем там вам где то уникальность не понятно...
если вариант 2 - то там и проблемы то нет на самом деле
если вариант 3 - то а)у вас вариантов особо нет б)вы и сами достаточно грамотный чтобы придумать что сделать

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

PS: cross-table unique check крайне нетривиально реализовать так чтобы это не тормозило.


--
Maxim Boguk
Senior Postgresql DBA
http://www.postgresql-consulting.ru/
...
Рейтинг: 0 / 0
22.02.2013, 13:58:50
    #38162239
DmGr
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
Maxim Boguk,

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

Примерный смысл такой
Parent - таблица документов (общий журнал всех документов)
номер
дата
тип документа
и т.д.

Child1 таблица
тип документа 1 и его спец часть

Child2 таблица
тип документа 2 и его спец часть

и т.д.

Получилось красиво, но вот нарвался...

Я прекрасно понимаю, что без наследования прекрасно можно обойтись.
Будем считать, что это был мой не совсем удачный опыт.

Хотя мне сначала это показалось очень удобным вариантом.
...
Рейтинг: 0 / 0
20.02.2014, 10:55:31
    #38567175
kengoo
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
Вот такое решение:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
CREATE TABLE doc_id (
  id integer NOT NULL,
  CONSTRAINT doc_id_pk PRIMARY KEY (id)
);

CREATE TABLE doc (
  id integer NOT NULL,
  basicdata text
); -- в doc вставка запрещена триггером, это "виртуальная" таблица

CREATE TABLE doc_specific1
(
-- Inherited from table doc:  id integer NOT NULL,
-- Inherited from table doc:  basicdata text
  specificdata1 text,
  CONSTRAINT doc_specific1_fk_id FOREIGN KEY (id) REFERENCES doc_id (id),
)
INHERITS (doc);

-- Аналогично doc_specific2,3,4,...



При вставке в наследника триггером добавляется id в doc_id, чем проверяется уникальность.
При удалении из наследника триггером удаляется id из doc_id.
Следующим уровнем наследования идут партиции по месяцам (doc_specific1_p201401,...).
Есть возможность делать внешние ключи "на doc" (фактически на doc_id.id).

Кто так делал, в чём грабли? :)
Покритикуйте, пожалуйста...
...
Рейтинг: 0 / 0
20.02.2014, 11:54:56
    #38567278
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
kengooВот такое решение:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
CREATE TABLE doc_id (
  id integer NOT NULL,
  CONSTRAINT doc_id_pk PRIMARY KEY (id)
);

CREATE TABLE doc (
  id integer NOT NULL,
  basicdata text
); -- в doc вставка запрещена триггером, это "виртуальная" таблица

CREATE TABLE doc_specific1
(
-- Inherited from table doc:  id integer NOT NULL,
-- Inherited from table doc:  basicdata text
  specificdata1 text,
  CONSTRAINT doc_specific1_fk_id FOREIGN KEY (id) REFERENCES doc_id (id),
)
INHERITS (doc);

-- Аналогично doc_specific2,3,4,...



При вставке в наследника триггером добавляется id в doc_id, чем проверяется уникальность.
При удалении из наследника триггером удаляется id из doc_id.
Следующим уровнем наследования идут партиции по месяцам (doc_specific1_p201401,...).
Есть возможность делать внешние ключи "на doc" (фактически на doc_id.id).

Кто так делал, в чём грабли? :)
Покритикуйте, пожалуйста...

само по себе решение как абстрактная штука - рабочее...
но как я уже писал партиционирование надо в 3х случаях


1)архива отчетов/операций...
2)или там где уникальность по PK идет а он из sequence генерируется...
3)или там где таблица уже под сотню гигов и ее надо резать на куски любой ценой ради какой то управляемости хотя бы...

в варианте 1 и 2 ваше решение просто не надо )...
в варианте 3 не будет работать так как задача то не создавать таблицу на несколько миллиардов записей... а у вас в doc_id именно это и будет... (со всеми связанными проблемами).

Т.е. да решение... но для несуществующей задачи...
...
Рейтинг: 0 / 0
20.02.2014, 22:06:06
    #38568126
Sergei.Agalakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дубликаты в primary key parent-таблицы
Партиции несомненно нужны, но когда партиции в стиле Оракла будут реализованы - бог весть.
А вот для наследования я не нашел достойного применения, кроме как костыли для партиций в Постгресе здесь и сейчас. Все можно сделать через вью ничем не хуже.
...
Рейтинг: 0 / 0
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Дубликаты в primary key parent-таблицы / 15 сообщений из 15, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]