Как реализовать таблицу, где несколько атрибутов являются просто ссылками на другой кортеж? - PullRequest
Новая
       11

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

1 голос
/ 24 января 2012

У меня есть таблица Sql, показанная ниже: - 

> select * from table1;
    |--------------------------------------------------|
    | ID | A1 | A2 | B1 | B2 | C1 | C2 | REF_B | REF_C |
    |--------------------------------------------------|
    | 1  | a1 | a1 | b1 | b1|  c1 | c1 |  1    |   1   |
    | 2  | a2 | a2 | b2 | b2|  c1 | c1 |  2    |   1   |
    | 3  | a3 | a3 | b1 | b1|  c1 | c1 |  1    |   1   |
    |--------------------------------------------------|
  • ID - это первичный ключ.
  • A1 и A2 уникальны для каждого кортежа.
  • B1 и B2 - это значения кортежа, на которые указывает атрибут REF_B текущей строки.
  • C1 и C2 - значения кортежа, на которые указывает атрибут REF_C текущей строки.
  • REF_B относится к ID другого кортежа в этой же таблице, откуда мы должны получить значения Bx.
  • REF_C относится к ID другого кортежа в этой же таблице, откуда мы должны получить значения Cx.

В этом вышеупомянутом подходе очевидная проблема, с которой мы сталкиваемся, заключается в распространении изменений, сделанных в кортеже 1, на кортежи 2 и 3. Прямо сейчас мы использовали программный подход (код Java) для достижения этой цели.

Это и сложно, и не красиво.

Предлагаемое изменение

Разделите table1 на три таблицы. 

> select * from table1_a;
    |------------------------------|
    | ID | A1 | A2 | REF_B | REF_C |
    |------------------------------|
    | 1  | a1 | a1 |  1    |   1   |
    | 2  | a2 | a2 |  2    |   1   |
    | 3  | a3 | a3 |  1    |   1   |
    |------------------------------|

> select * from table1_b;
    |--------------|
    | ID | B1 | B2 |
    |--------------|
    | 1  | b1 | b1 |
    | 2  | b2 | b2 |
    |--------------|

> select * from table1_c;
    |--------------|
    | ID | C1 | C2 |
    |--------------|
    | 1  | c1 | c1 |
    |--------------|

table1 будет обновляемым представлением объединения этих трех таблиц.

  • Видите ли вы возможные недостатки в этом подходе?
  • Есть ли более простое решение?
  • Каковы возможные ограничения, которые мы можем иметь на новый table1. table1 напрямую сопоставляется с объектом ADF Entity.

Ответы [ 2 ]

0 голосов
/ 09 марта 2012

Похоже, что предложенное вами решение является нормализацией исходной таблицы, при условии, что вы создаете внешние ключи REF_A & REF_B (хотя я бы сам назвал эти A_ID и B_ID) для table1_b и table1_c.Это то, что ты имеешь в виду?

Одна вещь, которая мне не понятна, это то, зачем вам нужны два столбца (A1 и A2), если они содержат одинаковые данные.Не могли бы вы объединить это в один столбец, а затем просто выбрать дважды, если вам нужно две копии в результате?то есть, предполагая, что у вас есть только один столбец «A» вместо A1 / A2: 

select A, A from table1....

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

Я никогда не использовал ADF, но документация оракула, по-видимому, подразумевает, что вы можете ссылаться на представление:

Объекты сущности отображаются на отдельные объекты в источнике данных.В подавляющем большинстве случаев это> таблицы, представления, синонимы или снимки в базе данных.

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

0 голосов
/ 24 января 2012

Использовать триггер: 

CREATE OR REPLACE TRIGGER upd_table1
BEFORE UPDATE OF a1
    OR UPDATE OF a2
    ON TABLE1
REFERENCING new AS new
BEGIN
   UPDATE table1
      SET b1 = new.a1, b2 = new.a2
    WHERE refb = new.id;
   UPDATE table1
      SET c1 = new.a1, c2 = new.a2
    WHERE refc = new.id;
END;
...