Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Составной Primary key  [new]
SerjInsane
Member

Откуда:
Сообщений: 30
есть Primary Key в 2 таблицах, которые используются другими подчиненными таблицами. Для одной из подчиненных таблиц необходимо установить отношения с теми двумя Primary Key в одном поле. возможно ли такое и как это реализовать? подскажите, пожалуйста.
22 окт 13, 16:51    [15016205]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
Glory
Member

Откуда:
Сообщений: 104751
SerjInsane
возможно ли такое и как это реализовать?

Возможно. Просто создать два отношения - для каждой из таблиц
22 окт 13, 16:56    [15016251]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
SerjInsane
Member

Откуда:
Сообщений: 30
Glory
SerjInsane
возможно ли такое и как это реализовать?

Возможно. Просто создать два отношения - для каждой из таблиц

ну вот я делаю два отношения, затем в подчиненной таблице ввожу в поле, в котором установлены отношения с двумя ПК, значение, которое скажем есть в одной из таблиц с ПК. тогда вылазит ошибка, что во второй таблице такого значения нет.
22 окт 13, 17:13    [15016368]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
Гость333
Member

Откуда:
Сообщений: 3683
SerjInsane,

А как, по-вашему, сервер должен выбрать, с какой из таблиц проверять внешний ключ?
22 окт 13, 17:15    [15016380]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
Glory
Member

Откуда:
Сообщений: 104751
SerjInsane
ну вот я делаю два отношения, затем в подчиненной таблице ввожу в поле, в котором установлены отношения с двумя ПК, значение, которое скажем есть в одной из таблиц с ПК. тогда вылазит ошибка, что во второй таблице такого значения нет.

Ну так, все правильно. Оба отношения работают независимо друг от друга.
22 окт 13, 17:54    [15016622]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34703
SerjInsane,

Лучше напиши всё в терминах CREATE TABLE...
Я лично ничего не понимаю.
22 окт 13, 18:00    [15016647]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
перевожу
Guest
MasterZiv,

у ТС 2 таблицы, в одной четные ид, и это ПК, в другой нечетные, и это тоже ПК.
он хочет содержимое двух таблиц слить в одну, не сливая физически в 3-ю таблицу.
и чтоб это стало "виртуальным ПК".
т.е. у него четвертая таблица может иметь ид и четные, и нечетные. и чтоб сие ФК
имело ПК то-ли из 1-ой таблицы, то-ли из второй,
короче, там значения 1,2,3,4,.. и это все ФК на юнион обоих ПК из первых двух таблиц
22 окт 13, 18:06    [15016682]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
Гость333
Member

Откуда:
Сообщений: 3683
SerjInsane,

Если для подчинённой таблицы у вас определён критерий того, с какой именно из родительских таблиц нужно проверить отношение для текущей строки, то можно сделать так.
Добавляете в подчинённую таблицу два вычисляемых столбца. Пишете для них формулу:
CASE WHEN <критерий выбора родительской таблицы> THEN ПроверяемыйСтолбец ELSE NULL END

Создаёте внешние ключи на этих столбцах.
22 окт 13, 18:06    [15016684]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
SerjInsane
Member

Откуда:
Сообщений: 30
перевожу
MasterZiv,

у ТС 2 таблицы, в одной четные ид, и это ПК, в другой нечетные, и это тоже ПК.
он хочет содержимое двух таблиц слить в одну, не сливая физически в 3-ю таблицу.
и чтоб это стало "виртуальным ПК".
т.е. у него четвертая таблица может иметь ид и четные, и нечетные. и чтоб сие ФК
имело ПК то-ли из 1-ой таблицы, то-ли из второй,
короче, там значения 1,2,3,4,.. и это все ФК на юнион обоих ПК из первых двух таблиц

отличный перевод. вот такое мне и надо реализовать.
23 окт 13, 15:55    [15021638]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Хотеть не вредно.

Проблема в том что плохо когда левая пятка и красатулечки главенствует над здравым смыслом.

Если есть что-то что является общим и на него ссылается, и не важно что это общее бывает 2х видов, то должна быть представлена в виде таблы (для контроля).

Более того, зуб даю что это у этих двух табель есть что-то общее, иначе нет смысла было соединять в одно.
Иначе SerjInsane или сам не знает чего хочет, или нужно совершенно другое (два FK в подчинённой, т.е. два поля).

ИМХО, всё дело в лени. У большинства неправильное представление о скорости рефакторинга (которое можно достичь).
Если чего-то вы не видите, это не значит что его много.
Нужно автоматизировать не только заказчика, но и свое производственное дело (рабочее место/среду).
23 окт 13, 22:15    [15023307]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
SandalTree
Member

Откуда: Перехлёсток восьми батог
Сообщений: 28146
Mnior
Хотеть не вредно.

Проблема в том что плохо когда левая пятка и красатулечки главенствует над здравым смыслом.

Если есть что-то что является общим и на него ссылается, и не важно что это общее бывает 2х видов, то должна быть представлена в виде таблы (для контроля).

Более того, зуб даю что это у этих двух табель есть что-то общее, иначе нет смысла было соединять в одно.
Иначе SerjInsane или сам не знает чего хочет, или нужно совершенно другое (два FK в подчинённой, т.е. два поля).


А ты зря так.
Вот у меня недавно была простая задачка:
Есть люди и есть фирмы. У тех и тех есть адреса: Домашний, почтовый, второй домашний, загородная вилла, штаб квартира, филиал.....

Так вот варианта только 2:
1. Строить 2 таблицы с адресами.
2. Строить 2 референса к адресной табличке.

Если-бы была возможность ссылаться из адресов в любую табличку по выбору.... но это только фантазии.
24 окт 13, 03:11    [15023814]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
SandalTree
Member

Откуда: Перехлёсток восьми батог
Сообщений: 28146
SerjInsane
есть Primary Key в 2 таблицах, которые используются другими подчиненными таблицами. Для одной из подчиненных таблиц необходимо установить отношения с теми двумя Primary Key в одном поле. возможно ли такое и как это реализовать? подскажите, пожалуйста.


С одним столбцом это невозможно, а с двумя вполне получается

use tempdb
GO
Create Table t1(id int identity(1,1), f1 char(1), CONSTRAINT PK_t1 PRIMARY KEY CLUSTERED (id ASC));
GO
Create Table t2(id int identity(1,1), f2 char(1), CONSTRAINT PK_t2 PRIMARY KEY CLUSTERED (id ASC));
GO
Create Table r(id_1 int, id_2 int, f char(1));
GO
ALTER TABLE r Add CONSTRAINT CHK_r CHECK (NOT (id_1 is null and id_2 is null) and NOT (id_1 is not null and id_2 is not null))
GO
ALTER TABLE r ADD CONSTRAINT FK_t1
	FOREIGN KEY (id_1) REFERENCES t1 (id) 
		ON UPDATE  NO ACTION ON DELETE NO ACTION 
GO
ALTER TABLE r ADD CONSTRAINT FK_t2
	FOREIGN KEY (id_2) REFERENCES t2 (id) 
		ON UPDATE  NO ACTION ON DELETE NO ACTION 
GO
INSERT INTO t1(f1) VALUES ('A'),('B'),('C'),('D'),('E')
GO
INSERT INTO t2(f2) VALUES ('X'),('Y'),('Z'),('V'),('W')
GO
INSERT INTO r(id_1,f) VALUES (1,'F'),(2,'G'),(3,'H'),(4,'I'),(5,'J')
GO
INSERT INTO r(id_2,f) VALUES (1,'K'),(2,'L'),(3,'M'),(4,'N'),(5,'O')
GO
-- Error 1
INSERT INTO r(f) VALUES ('P')
GO
-- Error 2
INSERT INTO r(id_2,f) VALUES (6,'R')
GO
-- Error 3
INSERT INTO r(id_1,id_2,f) VALUES (1,1,'Q')
GO
CREATE VIEW v_r as
SELECT ISNULL(id_1,id_2) as id, f,
  CASE WHEN id_1 IS NULL then 2 ELSE 1 END as t
FROM r
GO
SELECT * FROM v_r 
INNER JOIN t1 on v_r.t = 1 and v_r.id = t1.id
GO
SELECT * FROM v_r 
INNER JOIN t2 on v_r.t = 2 and v_r.id = t2.id
GO
SELECT r.f, ISNULL(t1.f1, t2.f2) as ff
FROM r
LEFT JOIN t1 on t1.id = r.id_1
LEFT JOIN t2 on t2.id = r.id_2
24 окт 13, 03:29    [15023822]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
LexusR
Member

Откуда: Novosibirsk
Сообщений: 1887
SandalTree
Mnior
Хотеть не вредно.

Проблема в том что плохо когда левая пятка и красатулечки главенствует над здравым смыслом.

Если есть что-то что является общим и на него ссылается, и не важно что это общее бывает 2х видов, то должна быть представлена в виде таблы (для контроля).

Более того, зуб даю что это у этих двух табель есть что-то общее, иначе нет смысла было соединять в одно.
Иначе SerjInsane или сам не знает чего хочет, или нужно совершенно другое (два FK в подчинённой, т.е. два поля).


А ты зря так.
Вот у меня недавно была простая задачка:
Есть люди и есть фирмы. У тех и тех есть адреса: Домашний, почтовый, второй домашний, загородная вилла, штаб квартира, филиал.....

Так вот варианта только 2:
1. Строить 2 таблицы с адресами.
2. Строить 2 референса к адресной табличке.

Если-бы была возможность ссылаться из адресов в любую табличку по выбору.... но это только фантазии.


В данном случае по феншую не таблица адресов ссылается на 2 таблицы а 2 таблицы ссылаются БЕЗ ПРОБЛЕМ на справочник адресов
24 окт 13, 07:04    [15023892]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
SandalTree
1. Строить 2 таблицы с адресами.
Накуя?
Одна табла: адреса фирмы, где есть поле тип адреса.

SandalTree
Если-бы была возможность ссылаться из адресов в любую табличку по выбору.... но это только фантазии.
А накуя это? LexusR всё написал.

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

Более того, если бы вы понимали как работают запросы (селективность и всё такое), в чём затыки и как оптимизируются, вы бы так смотреть на структуры табель перестали бы.

IMXO
24 окт 13, 15:58    [15027325]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
SandalTree
Member

Откуда: Перехлёсток восьми батог
Сообщений: 28146
LexusR
SandalTree
пропущено...


А ты зря так.
Вот у меня недавно была простая задачка:
Есть люди и есть фирмы. У тех и тех есть адреса: Домашний, почтовый, второй домашний, загородная вилла, штаб квартира, филиал.....

Так вот варианта только 2:
1. Строить 2 таблицы с адресами.
2. Строить 2 референса к адресной табличке.

Если-бы была возможность ссылаться из адресов в любую табличку по выбору.... но это только фантазии.


В данном случае по феншую не таблица адресов ссылается на 2 таблицы а 2 таблицы ссылаются БЕЗ ПРОБЛЕМ на справочник адресов
Вы забыли про то что у фирмы и у человека может быть много адресов и нужно будет создавать ещё 2 промежуточных таблицы
24 окт 13, 17:17    [15027810]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
SandalTree
Member

Откуда: Перехлёсток восьми батог
Сообщений: 28146
SerjInsane
есть Primary Key в 2 таблицах, которые используются другими подчиненными таблицами. Для одной из подчиненных таблиц необходимо установить отношения с теми двумя Primary Key в одном поле. возможно ли такое и как это реализовать? подскажите, пожалуйста.


Кстати, а вы не расскажете что у вас там в этих таблицах?

Нам для примера.
24 окт 13, 17:18    [15027817]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
SandalTree
Member

Откуда: Перехлёсток восьми батог
Сообщений: 28146
Mnior
SandalTree
1. Строить 2 таблицы с адресами.
Накуя?
Одна табла: адреса фирмы, где есть поле тип адреса.

SandalTree
Если-бы была возможность ссылаться из адресов в любую табличку по выбору.... но это только фантазии.
А накуя это? LexusR всё написал.

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

Более того, если бы вы понимали как работают запросы (селективность и всё такое), в чём затыки и как оптимизируются, вы бы так смотреть на структуры табель перестали бы.

IMXO
Дело в том что если будет только одно поле ссылки на родителя то вы не сможете построить FK.

Если вы считаете что я в корне ошибаюсь то приведите мне скрипт стойкой структуры, это меня убедит.
24 окт 13, 17:24    [15027856]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Выбирайте себе любую комбинацию (убирая лишние колонки/таблицы).
+ Скрипт
CREATE TABLE [dbo].[Address] (
	[ID]		Int	IDENTITY		CONSTRAINT [PK_Address]	PRIMARY KEY
,	[AddressFull]	NVarChar(1024)	NOT NULL
)
CREATE TABLE [dbo].[Client] (
	[ID]			Int	IDENTITY	CONSTRAINT [PK_Client]	PRIMARY KEY
,	[Address]		Int	NOT NULL	CONSTRAINT [FK_Client_Address]	REFERENCES [dbo].[Address] ([ID])
,	[AddressAlternate]	Int	    NULL	CONSTRAINT [FK_Client_AddressAlternate]	REFERENCES [dbo].[Address] ([ID])
,	[AddressFull]		NVarChar(1024)	NOT NULL
)
CREATE TABLE [dbo].[ClientAddress] (
	[ID]		Int	IDENTITY	CONSTRAINT [PK_ClientAddress]	PRIMARY KEY
,	[Client]	Int	NOT NULL	CONSTRAINT [FK_ClientAddress_Client]	REFERENCES [dbo].[Client] ([ID])
,	[Type]		Int	NOT NULL--	CONSTRAINT [FK_ClientAddress_Type]	REFERENCES [dbo].[AddressType] ([ID])
					--	CONSTRAINT [UQ_ClientAddress]	UNIQUE ([Client],[Type])	-- CLUSTERED/PRIMARY KEY
,	[Address]	Int	    NULL	CONSTRAINT [FK_ClientAddress_Address]	REFERENCES [dbo].[Address] ([ID])
,	[AddressFull]	NVarChar(1024)	    NULL
)
Вместо [AddressFull] можете подразумевать структуру (набор колонок)
24 окт 13, 22:34    [15029010]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
SandalTree
Member

Откуда: Перехлёсток восьми батог
Сообщений: 28146
Mnior
Выбирайте себе любую комбинацию (убирая лишние колонки/таблицы).
+ Скрипт
CREATE TABLE [dbo].[Address] (
	[ID]		Int	IDENTITY		CONSTRAINT [PK_Address]	PRIMARY KEY
,	[AddressFull]	NVarChar(1024)	NOT NULL
)
CREATE TABLE [dbo].[Client] (
	[ID]			Int	IDENTITY	CONSTRAINT [PK_Client]	PRIMARY KEY
,	[Address]		Int	NOT NULL	CONSTRAINT [FK_Client_Address]	REFERENCES [dbo].[Address] ([ID])
,	[AddressAlternate]	Int	    NULL	CONSTRAINT [FK_Client_AddressAlternate]	REFERENCES [dbo].[Address] ([ID])
,	[AddressFull]		NVarChar(1024)	NOT NULL
)
CREATE TABLE [dbo].[ClientAddress] (
	[ID]		Int	IDENTITY	CONSTRAINT [PK_ClientAddress]	PRIMARY KEY
,	[Client]	Int	NOT NULL	CONSTRAINT [FK_ClientAddress_Client]	REFERENCES [dbo].[Client] ([ID])
,	[Type]		Int	NOT NULL--	CONSTRAINT [FK_ClientAddress_Type]	REFERENCES [dbo].[AddressType] ([ID])
					--	CONSTRAINT [UQ_ClientAddress]	UNIQUE ([Client],[Type])	-- CLUSTERED/PRIMARY KEY
,	[Address]	Int	    NULL	CONSTRAINT [FK_ClientAddress_Address]	REFERENCES [dbo].[Address] ([ID])
,	[AddressFull]	NVarChar(1024)	    NULL
)
Вместо [AddressFull] можете подразумевать структуру (набор колонок)


Вы или на до мной издеваетесь, либо абсолютно не поняли о чём речь.

В вашем случае описана стандартная структура м2м.
Я привёл возможный сценарий когда у нас есть 3 таблицы: Фирмы, Люди и Адреса.

При вашем подходе вам требуется ещё 2 таблицы Фирмы_Адреса и Люди_Адреса.
Это проверенный временем и всеми рекомендуемый стандарт.

Однако, нужно заметить что связи между таблицами Фирмы и Фирмы_Адреса, и Люди и Люди_Адреса будут фактически о2о.
Конечно можно перенести тяжесть типов адресов на Фирмы_Адреса и Люди_Адреса, сделав тем самым эти связи о2м, но тогда вы получите связи с таблицей Адреса как о2о.

Т.е. мы имеем двойную избыточность и соответственно две ненужных таблички которые нужно поддерживать.

Надеюсь вы не воспринимаете мой подход как попытку вас обидеть.
25 окт 13, 02:26    [15029369]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
SandalTree
Вы или на до мной издеваетесь, либо абсолютно не поняли о чём речь.
Надеюсь вы учитываете что я могу думать про вас также.
SandalTree
Надеюсь вы не воспринимаете мой подход как попытку вас обидеть.
Мне можно испортить настроение только глупостью. Троллинг одно из его проявлений.
SandalTree
Это проверенный временем и всеми рекомендуемый стандарт.
Давайте без этого. Каждая задача решается под те нужды которые необходимы. Физика базы и логика данных не связаны.

SandalTree
Я привёл возможный сценарий когда у нас есть 3 таблицы: Фирмы, Люди и Адреса.
Да хоть 100500 таблиц.
SandalTree
При вашем подходе вам требуется ещё 2 таблицы Фирмы_Адреса и Люди_Адреса.
Это в 2х из 6ти мною приведённых. И почему вы на них акцентируете внимание в данном случае?
Ага выкинем два кубика и будем рассуждать почему выпали разные номера?!

SandalTree
Однако, нужно заметить что связи между таблицами Фирмы и Фирмы_Адреса, и Люди и Люди_Адреса будут фактически о2о.
Нафига эти подчинённые таблы непонятно? Иначе это не о2о.
Чем вам не устраивает случай есть только "Адреса", "Фирмы", "Люди"?
SandalTree
Конечно можно перенести тяжесть типов адресов на Фирмы_Адреса и Люди_Адреса, сделав тем самым эти связи о2м, но тогда вы получите связи с таблицей Адреса как о2о.
Также не верно - всё зависит от стратегии. Можно и ссылаться на один и тот же адрес с разных мест.
Да к тому же - что вас смущает? Допустим логический (не физический) o2o и что? Не по феншую? На то она и реалиционка, что табла с одной стороны о2о, а с другой о2м, с дополнительным набором свойств.
SandalTree
Т.е. мы имеем двойную избыточность и соответственно две ненужных таблички которые нужно поддерживать.
Никакой избыточности, тем более двойной. Не надо ничего "поддерживать дополнительно в напряг", уберите этот пафос (в каждом предложении). А то он размножится заполонит всё тут.

Допустим некая необходимость (сверх динамический и большой набор типов адресов, может постоянно читаемая их историчность) вынудило добавить Фирмы_Адреса и Люди_Адреса (да хоть 100500). И что?
Необходимость это "непрактичный напряг"?
Или вас смущает одинаковость этих таблиц по внешнему виду?

Но и не в этом суть. Суть в "приведите случай когда надо у одного поля ставить FK на да PK". Не уходите от темы.
Делать FK многоарным - маразм, таблицы для этого и придуманы.

Мне кажется вас гложет совершенно другое - лень писать код. Аля "тут надо делать два инсерта".
Может вы тогда присоединитесь к тем кто требует от разрабов скуля одновременного (в одном запросе) изменение множества объектов? И кстати такие системы существуют.
А может вы просто не умете его (код) готовить.
25 окт 13, 05:26    [15029420]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
SandalTree
Member

Откуда: Перехлёсток восьми батог
Сообщений: 28146
Mnior
Мне кажется вас гложет совершенно другое - лень писать код. Аля "тут надо делать два инсерта".
Может вы тогда присоединитесь к тем кто требует от разрабов скуля одновременного (в одном запросе) изменение множества объектов? И кстати такие системы существуют.
А может вы просто не умете его (код) готовить.

Вобщем-то всё остальное не важно. Тут вы уловили суть.
Я лично считаю что если можно сделать всего один инсерт вместо двух, то так и нужно делать.

Надеюсь вы не будете устраивать религиозный холивар по этому вопросу.
25 окт 13, 21:17    [15034443]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
SandalTree
Надеюсь вы не будете устраивать религиозный холивар по этому вопросу.
Ну не я же его начал.
Горе проггеров тьма.
25 окт 13, 23:48    [15035112]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
SerjInsane
Member

Откуда:
Сообщений: 30
прошу прощения, что долго не отвечал. за ранее хочу сказать, что мне очень стыдно, но с базами данных я знаком совсем недавно и много еще не знаю, поэтому некоторые из приведенных здесь решений мне не совсем понятны. быть может ответ на мой вопрос был уже дан. а может и вовсе надо мне все делать по-другому. опишу что конкретно поставлено в моей задаче:
разрабатывается ПО Домашняя бухгалерия, имеется таблица Family с именами членов семьи и их возрастном статусе(взрослый, ребенок), есть таблица CostsCathegory с названиями категорий расходов(кварт плата, продукты питания и т.д.), и есть таблица расходов Costs, одной из колонок является "категория", которая ФК из таблицы CostsCathegory. но в эту колонку "категория" также должны вписываться имена из таблицы Family, чей возрастной статус равен ребенок.
З.Ы. таблица CostsCathegory должна сохранять целостность своих собственных данных, т.е. переписать в нее имена из таблицы Family не вариант.
28 окт 13, 14:42    [15041450]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
Гость333
Member

Откуда:
Сообщений: 3683
SerjInsane,

Лучше покажите DDL этих таблиц.
28 окт 13, 15:11    [15041632]     Ответить | Цитировать Сообщить модератору
 Re: Составной Primary key  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34703
SerjInsane
перевожу
MasterZiv,

у ТС 2 таблицы, в одной четные ид, и это ПК, в другой нечетные, и это тоже ПК.
он хочет содержимое двух таблиц слить в одну, не сливая физически в 3-ю таблицу.
и чтоб это стало "виртуальным ПК".
т.е. у него четвертая таблица может иметь ид и четные, и нечетные. и чтоб сие ФК
имело ПК то-ли из 1-ой таблицы, то-ли из второй,
короче, там значения 1,2,3,4,.. и это все ФК на юнион обоих ПК из первых двух таблиц

отличный перевод. вот такое мне и надо реализовать.


Бред какой-то...
28 окт 13, 16:49    [15042186]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить