Блог

У меня есть вопрос, и, надеюсь, вы сможете мне помочь. 🙂

У меня есть такая таблица:

 ID  Col1        Col2        ReverseID
1   Number 1    Number A    
2   Number 2    Number B    
3   Number 3    Number C    
  

Чего я хочу добиться, так это:

• Создайте дубликат каждой записи с переключаемыми столбцами и добавьте их в исходную таблицу
• Добавьте идентификатор дубликата в столбец ReverseID исходной записи и наоборот

Итак, новая таблица должна выглядеть так:

 ID  Col1        Col2        ReverseID
1   Number 1    Number A    4
2   Number 2    Number B    5
3   Number 3    Number C    6
4   Number A    Number 1    1
5   Number B    Number 2    2
6   Number C    Number 3    3

  

То, что я делал до сих пор, работало с временной таблицей:

 SELECT * INTO #tbl
FROM myTable

UPDATE #tbl
SET Col1 = Col2,
    Col2 = Col1,
    ReverseID = ID

INSERT INTO DUPLICATEtable(
        Col1,
        Col2,
        ReverseID
)

SELECT Col1,
       Col2,
       ReverseID
FROM #tbl
  

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

Я думаю, что мог бы пропустить часть SET и изменить столбцы в последнем операторе SELECT, чтобы добиться того же, но я не уверен.

В любом случае — с этим я заканчиваю:

 ID  Col1        Col2        ReverseID
1   Number 1    Number A    
2   Number 2    Number B    
3   Number 3    Number C    
4   Number A    Number 1    1
5   Number B    Number 2    2
6   Number C    Number 3    3

  

Итак, остается вопрос: как мне правильно добавить обратные идентификаторы в исходные записи?

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

Заранее благодарю!

br mrt

Редактировать:

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

.

Прежде всего: мой интерфейс не допускает никаких инструкций SQL, я должен сосредоточиться на классах, атрибутах, отношениях.

Первая основная причина: экземпляры класса B (B1, B2, B3, …) связаны друг с другом отношением класса, это отношения «многие ко многим» одного класса. Мой интерфейс не позволяет объединять таблицы, так что это обходной путь.

Указание пользователя добавляет связь с B1 в качестве первой стороны (я просто назвал ее «левой») и B2 в качестве второй стороны (справа):

При переходе с B1 будут отображаться два отношения (FK_Left, FK_Right), но только одно из них будет содержать значение (скажем, FK_Left).

При переходе из B2 значение будет указано только в другом отношении (FK_Right). Таким образом, со стороны пользователей всегда отображаются два отношения, но это зависит от того, как была введена запись, можно ли найти данные за relation_left или relation_right . Это практически невозможно использовать.

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

Вторая основная причина: интерфейс предоставляет некоторое матричное представление, которое получает класс отношений в качестве входных данных и отображает левых партнеров в столбцах и правых партнеров в строках.

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

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

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

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

 create view MyReversedDataView as

select ID
    , Col1
    , Col2
from MyTable

UNION ALL

select ID
    , Col2
    , Col1
from MyTable
  

Хитрость такого рода заключается в том, чтобы начать с ВЫБОРА, который получает нужные вам данные. В этом случае вам нужен результирующий набор с Col1, Col2, reverseid.

 SELECT Col2 Col1, Col1 Col1, ID reverseid
  INTO #tmp   FROM myTable;
  

Убедите себя, что это правильно — поменялись значениями столбцов и т. Д.

Затем сделайте это:

 INSERT INTO myTable (Col1, col2, reverseid)
SELECT Col1, Col2, reverseid FROM #tmp;
  

Если вы делаете это с помощью графического интерфейса, такого как ssms, не забудьте DROP TABLE #tmp;

НО вы можете получить тот же результат с помощью чистого запроса, без дублирования строк. Почему это так?

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

Вот как вы можете это сделать.

  SELECT Col1, Col2, null reverseid FROM myTable
  UNION ALL
 SELECT Col2 Col1, Col1 Col2, ID reverseid FROM myTable;
  

Вы даже можете превратить это в представление и использовать его, как если бы это была таблица в будущем.

 CREATE VIEW myTableWithReversals AS
SELECT Col1, Col2, null reverseid FROM myTable
 UNION ALL
SELECT Col2 Col1, Col1 Col2, ID reverseid FROM myTable;
  

Затем вы можете сказать SELECT * FROM myTableWithReversals WHERE Col1 = 'value' и т.д.

Позвольте мне предположить, что id столбец автоматически увеличивается. Затем вы можете сделать это в два этапа:

 insert into myTable (Col1, Col2, reverseid)
    select col2, col1, id
    from myTable t
    order by id;  -- ensures that they go in in the right order
  

При этом новые идентификаторы вставляются с правом reverseid . Теперь нам нужно обновить предыдущие значения:

 update t
    set reverseid = tr.id
    from myTable t join
         myTable tr
         on tr.reverseid = t.id;
  

Обратите внимание, что временные таблицы не нужны.