Начальная страница › Форумы › PostgreSQL › Вопросы по SQL и другие аспекты работы PostgreSQL

REFERENCES наоборот ?

Posted Июль 15th, 2009 by Diem
in

есть таблица meta:

CREATE TABLE meta (
  id serial NOT NULL PRIMARY KEY,
  title varchar(256) NOT NULL,
  description text NOT NULL,
  keywords text NOT NULL
);

а также products:

CREATE TABLE products (
  id serial NOT NULL PRIMARY KEY,
  title varchar(100) NOT NULL,
  content text NOT NULL,
  price float NOT NULL,
  meta_id int NOT NULL
);

Таблица meta используется не только products но и другими таблицами.
Для каждой записи в products будет соотвествовать одна запись в meta.

Внимание вопрос :)
Можно ли стандартными средствами postgres сделать, что бы при удалении записи из products удалялась запись из meta (products.meta_id = meta.id)

‹ есть ли switch в postgresql? PostgreSQL8.3:Как сделать чтобы у пользователя совсем не было прав ни на что, кроме SELECT одной таблицы? ›

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

Это называется FOREIGN

On Июль 15th, 2009 admin says:

Это называется FOREIGN KEY
Читайте:
http://postgresql.ru.net/manual/ddl-constraints.html#DDL-CONSTRAINTS-FK

Да, конечно я в курсе.Но

On Июль 15th, 2009 Diem says:

Да, конечно я в курсе.
Но суть вопроса немного иного характера.

Я например мог бы применить
ALTER TABLE products ADD FOREIGN KEY (meta_id) REFERENCES meta(id) ON DELETE CASCADE;

Но в таком случае я добьюсь только того, что при удалении записи из meta, автоматически удалится запись из products.
А мне нужно как раз наоборот: чтобы при удалении продукта, он потянул за собой запись в meta.

P.S. сделать product_id в meta также не подходит, так как эта meta используется несколькими таблицами.

А что мешает повесить FOREIGN

On Июль 16th, 2009 admin says:

А что мешает повесить FOREIGN KEY не на product а на meta?

ALTER TABLE meta ADD FOREIGN KEY (id) REFERENCES product(meta_id) ON DELETE CASCADE;

Если id используется несколькими таблицами, то и там должен быть FOREIGN KEY, чтобы потом не было неконсистентности данных.

В общем либо я чего-то не понимаю - тогда пишите подробности, либо всё решается простым внешним ключём.

Да, но повторюсь "meta

On Июль 16th, 2009 Diem says:

Да, но повторюсь "meta используется несколькими таблицами"
Я с postgres только начинаю знакомится, поэтому может чего недопонимаю.

Тогда прийдётся какой-то множественный ключь вешать, не только на products(meta_id), но и на pages(meta_id) к примеру, и еще и ешё. Такое возможно ?

Так вообще-то это нормальная

On Июль 16th, 2009 admin says:

Так вообще-то это нормальная практика поддержания целостности данных в нормальных SQL СУБД. Это как правило люди, которые приходят с MySQL где FOREIGN KEY до сих пор реализован через одно место сталкиваются с непониманием ситуации, а во всех нормальных СУБД практика внешних ключей работает в любой сколь-нибудь сложной структуре БД.

Логично, что если есть таблица товаров product и в ней есть id товара, то этот id может использоваться в других таблицах БД, работающих с товаром, например в таблице sales (продажи). Опять же логично сделать id в sales внешним ключём на id в product потому что если такого товара нет, то что мы продаём? Наличие же внешнего ключа ГАРАНТИРУЕТ, что для каждой записи в таблице продаж, касающейся определённого товара, в таблице товаров ОБЯЗАТЕЛЬНО будет существовать данный товар. Соответственно, если мы удаляем товар из таблицы товаров, то ON DELETE CASCADE позволяет удалить и записи в таблице продаж, касающиеся этого продукта. Повторюсь - это обычная и нормальная практика в любой нормальной SQL СУБД.

Разумеется, что кроме таблицы продаж в БД могут существовать и другие таблицы СВЯЗАННЫЕ с таблицей товаров посредством внешних ключей, например таблица наличия данного товара на складе, таблица заказов данного товара и т.д. И здесь наличие внешних ключей гарантирует, что не будет ситуации, когда в таблице складских остатков товар есть, а в таблице товаров его нет.

Надеюсь всё объяснил понятно. Если нет - спрашивайте.

Большое спасибо за помощь. Да

On Июль 16th, 2009 Diem says:

Большое спасибо за помощь.
Да я действительно из mysql. там foreign key реализован, но в innodb, который в отличие от myisam жутко тормозит и вообще ненадёжен.

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

Но вы так и не вникли в суть моего вопроса.
Есть таблица meta

CREATE TABLE meta (
  id serial PRIMAY KEY;
  .........
);

Есть таблицы products, pages, help ...... , у всех присуствует поле meta_id (для каждой записи свой уникальный meta_id не зависимо от таблицы)

CREATE TABLE products (
  id serial PRIMAY KEY;
  meta_id int;
  .........
);

CREATE TABLE pages (
  id serial PRIMAY KEY;
  meta_id int;
  .........
);

CREATE TABLE help (
  id serial PRIMAY KEY;
  meta_id int;
  .........
);

и я хочу чтобы при удалении запсиси будь то products, pages или help
удалялась запись в meta.

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

думаю стоит подумать, оправдана ли такая структура

On Июль 16th, 2009 pwlad says:

А нужна ли вообще тогда таблица meta, может обойтись без неё, а завязать всё на products, если без записи в ней и запись в таблице meta теряет всякий смысл?
P.S.
Прочитал последнее сообщение ещё раз внимательней, и вообще перестал понимать всякий смысл такой структуры. Что за meta такая?

Вы не совсем правы. innodb в

On Июль 16th, 2009 admin says:

Вы не совсем правы. innodb в mysql работает производительней, чем myisam. А вот FOREIGN KEY в mysql даже в innodb реализован через задницу.

По вашему вопросу. Теперь я понял, чего вы хотите :)
Ответ такой. Если у вас meta_id в таблицах product, pages и help не зависят друг от друга, то да - триггером. А если зависят, то лучше бы вам сделать одну таблицу, хранящую meta_id, а в остальных таблицах зацепить на это поле внешние ключи.

Всем спасибо.

On Июль 16th, 2009 Diem says:

Всем спасибо.

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

Back to top

(С) Виктор Вислобоков, 2008-2023