привет. У меня такой вопрос.
Есть две таблицы. Обе таблицы хранят данные описываюсчие графический обьект определенного типа. Причем 1 Таблица содержит уникальный номер фигуры и текстовое обозначение на чертеже. Другая Таблица хранит данные о свойствах фигуры таких как (к примеру) цвет, размер и т.д. Также в этой таблице содержится как foreign key Уникальный номер фигуры.
Сейчас возникла необходимость для фигуры другого типа иметь отдельную таблицу для свойств, аналогичную выше описанной.
Поскольку структуры новой и старой таблицы полностью совпадают,можно использовать уже имеющуюся таблицу.
Проблема в foreign key :
Сейчас foreign key позволяет мне автоматически(каскадом) стирать и обновлять данные в таблице где храняться данные о свойствах Фигуры.
Если я подключу еще одну таблицу к таблице для хранения свойств Фигур, то я должен буду убрать связи по foreign key .
Как можно сделать что бы эффект каскада при стирании и обновлении данных даных все же сохранялся?
Можно ли для этого использовать триггеры?
P.S. Работаю с Microsoft SQL Server 2000

не совсем понятно, почему FK придется убрать, выложи скрипты таблиц?

конечно. AFTER DELETE на таблицу с PK.

Как можно сделать что бы эффект каскада при стирании и обновлении данных даных все же сохранялся?
------
Указать, что разрешено каскадное удаление. Но надо смотреть, чтобы структура позволяла выполнить это удаление.
Можно ли для этого использовать триггеры?
-----
Да, но это избыточно для простого каскадного удаления.

--
-- Structure for table Function :
--
CREATE TABLE [dbo].[Function] (
[FunctionID] nvarchar(50) COLLATE Latin1_General_CI_AS NOT NULL,
[Function] nvarchar(255) COLLATE Latin1_General_CI_AS,
[Check] nvarchar(50) COLLATE Latin1_General_CI_AS
)
ON [PRIMARY]
GO
--
-- Structure for table FunctionProp :
--
CREATE TABLE [dbo].[FunctionProp] (
[Id] int IDENTITY(1, 1) NOT NULL,
[FunctionId] nvarchar(50) COLLATE Latin1_General_CI_AS,
[Label] nvarchar(255) COLLATE Latin1_General_CI_AS,
[Property] nvarchar(80) COLLATE Latin1_General_CI_AS,
[Value] nvarchar(255) COLLATE Latin1_General_CI_AS,
[SortKey] nvarchar(50) COLLATE Latin1_General_CI_AS,
)
ON [PRIMARY]
GO
ALTER TABLE [dbo].[FunctionProp]
ADD CONSTRAINT [FK_FunctionProp_Function] FOREIGN KEY ([FunctionId])
REFERENCES [dbo].[Function] ([FunctionID])
ON UPDATE CASCADE
ON DELETE CASCADE
GO
-- Structure for table FunctionGroup :
--
CREATE TABLE [dbo].[FunctionGroup] (
[FunctionGroupID] nvarchar(50) COLLATE Latin1_General_CI_AS NOT NULL,
[FunctionGroup] nvarchar(50) COLLATE Latin1_General_CI_AS,
[Facility] nvarchar(50) COLLATE Latin1_General_CI_AS,
[FileName] nvarchar(255) COLLATE Latin1_General_CI_AS,
[Check] nvarchar(50) COLLATE Latin1_General_CI_AS
)
ON [PRIMARY]
GO
ON [PRIMARY]
GO
ALTER TABLE [dbo].[Function]
ADD CONSTRAINT [PK_Function]
PRIMARY KEY CLUSTERED ([FunctionID])
ON [PRIMARY]
GO
ALTER TABLE [dbo].[FunctionGroup]
ADD CONSTRAINT [PK_FunctionGroup]
PRIMARY KEY CLUSTERED ([FunctionGroupID])
ON [PRIMARY]
GO
ALTER TABLE [dbo].[FunctionProp]
ADD CONSTRAINT [PK_FunctionProp]
PRIMARY KEY CLUSTERED ([Id])
ON [PRIMARY]
GO
надеюсь что из кода видно, что существует связь между таблицей Function и FunctionProp.
Если я аналогично через Foreign Key свяжу FunctionGroup.FunctionGroupID и FunctinProp.FunctionID (и в том и в другом случае ето уникальный ключ) то при попытке внести новое значение в FunctionProp vозникает ошибка, поскольку если ID существует в таблице Function оно не существует в FunctionGroup и наоборот.

Т.е. если несколько перефразировать вопрос:
Можно ли создать одну подчиненную таблицу с двумя главными?
Это когда думаешь: одна голова - хорошо, а две лучше. А начальник должен быть все же один: у двух нянек - таблица без ключа.
Если уж так невмоготу, то добавь недостающие до FunctionGroup поля в Function и пользуйся одной главной и одной подчненной таблицей.
А лучше сделать FunctionGroupProp: окорочка к окорочкам, а раковые шейки - отдельно.

Можно просто добавить FunctionGroupID в FunctionProp.

Это как же надо ненавидеть базы данных, чтобы такое придумать.
По всем рекомандациям на связные столбцы подчиненной таблицы должны быть проиндексированы. А как же бедняжка там искать будет, если там половина NULL торчать будет. А без индекса скучно за join-ами наблюдать будет.

Это как же надо ненавидеть базы данных, чтобы такое придумать.
------
Годике этак в 2001-м я выкладывал настоящий шедевр под названием "Ужас ДБА".
Причем этот "Ужас ДБА" полностью соответствовал описанию той задачи, над
которой я тогда трудился... там было с десяток таблиц, каждая из которых имела
девять остальный в качестве Мастер-таблиц... Надо будет найти ту картинку...

именно об этом и идет речь:
создать одну подчиненную таблицу с двумя главными
Я и сделал отдельную подчиненную таблицу, но шефа это не устраивает: обе подчиненных таблицы имеют одинаковую структуру: Отличие только в названии столбцов
[FunctionID] и [FunctionGroupID] (суть таже)

Тогда воспользуйся советом scorpi_ и будет шефу счастье. Только предупреди, что возможно тормозить будет при работе.

А индекс на bool - поле видеть не доводилось? УЖОС!

А если все таки тригерры для главных таблиц для реагирования на стрирание и обновление строчек примерно такого содержания?
CREATE TRIGGER [Update_FunctionProps] ON [dbo].[Functions]
FOR UPDATE
AS
DECLARE @orig_id nvarchar(50), @new_id nvarchar (50)
SELECT @orig_id= FunctionID from deleted
SELECT @new_id = FunctionID from inserted
if( @orig_id<>@new_id)
BEGIN
UPDATE FunctionProperties
SET FunctionProperties.FunctionID= @new_id
where FunctionID IN(select FunctionID from deleted)
END
CREATE TRIGGER [DELETE_ID] ON [dbo].[Functions]
FOR DELETE
AS
DELETE
FROM [FunctionProperties]
where [FunctionProperties].FunctionID IN (SELECT FunctionID FROM Deleted)

Индекс - куда не шло - вот вместо индекса разбитие на четыре таблицы - это таки и есть "УжосНах"...

Тут попутный вопросик возник - у тебя _ключи_ формата NVARCHAR(50) - это какое-то специальное извращение или просто используется что-то введенное пользователем? (шутю)

Индекс будет работать совершенно нормально. Мне кажется, ты не вполне понимаешь, как они имплементируются, и какая у них временная сложность.

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

В данном случае я бы назвал это программирование для программирования. В MS SQL есть стандартные On delete Cascade и On Update Cascade. Не думаю, что trigger будет работать быстрее.

Огульно не могу ни поддержать, ни опровергнуть. Принцип разделяй и властвуй еще никто не отменял.
Например, таблица заказов: активные и архив. Почему бы их не разделить, если в повседневке мне только с активными работать, а в архив может вообще никто не заглянет?
Хотя 4, наверное, все же многовато.

Хотя 4, наверное, все же многовато.
-------
труеб фалсе, нулл, еррерс...

Во-первых, это не таблица. Это обычно дерево, чаще всего B-Tree. А в нём как известно увеличение количества записей вдвое увеличивает время доступа на константную величину. Грубо говоря на одно сравнение. Во-вторых вовсе не факт, что некая конкретная имплементация индекса вообще сохраняет нулевые значения в индексе. Ибо нулевое значение по определению не равно никакому другому.

Это обычно дерево, чаще всего B-Tree.
-----
В данном случае - наполовину вырожденное.
Во-вторых вовсе не факт, что некая конкретная имплементация
индекса вообще сохраняет нулевые значения в индексе.
-------
Это подразумевает анализ _значения_ данных - маловероятно, тем более, что данные могут быть (практически) любого типа... (Но как тер.возможность - принимается).

Тебе объяснить, что значит B? Balanced - оно не может быть вырожденным.

Ни фига не понял.

Тебе объяснить, что значит B? Balanced - оно не может быть вырожденным.
------
Ну попробуй. Правда перед этим рекомендую порыться в Кнутте. Если помню правильно - том 3-й по изданию 71-го года.
Ни фига не понял.
------
Ты говоришь, что какие-то записи могут быть неиндексированными (не включенными в индекс), при )_условии_, что _значения_ индексируемых (ключевых) полей - NULL.

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

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

если ты хочешь что-либо доказать мне, то приводи конкретные цитаты.
------
Для этого надо искать Кнута - под руками его нет. Да и не требуется - Деревья, двоичные, сбалансированные предполагают что их можно сбалансировать. При одинаковых значениях балансировка не получается и придумываются различные расширения... Вообщем - посмотри у Кнута условия применимости...
Hence, Oracle indexes will not include NULL values.
------
Хммм... буду знать, что под Ораклом возможны проблемы с non-enforced реляциями...

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

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

они гарантируют сбалансированность после каждой операции.
-------
Дерево балансируется после определения положения нового элемента. И именно *предполагается* что положение элемента можно определить однозначно, что, однако, достижимо не всегда.
Заданные ключи:
1. аааааа
2. аааааа
3. аааааа
Приведи дерево и обоснуй почему оно такое. Детали найдешь именно там где было указано - Кунут, т3, 6.2.3. Сбалансированные деревья.

При чём тут однозначность? B-дерево всегда полностью сбалансировано. Как будут расположены одинаковые ключи абсолютно никого не волнует. Вообще мне кажется, что ты путаешь B-tree и binary search tree.

B-дерево всегда полностью сбалансировано.
------
В свое время я "переводил" кнутовское описание в сишный код. Там есть вполне определенное условие сохранения сбалансированности дерева. Нарушение этого условия непозволяет иметь сбалансированное дерево. Любой вариант обхода этого ограничения предполагает какую-либо специализированную обработку "листьев", содержащих более одного элемента.
Вообще мне кажется, что ты путаешь B-tree и binary search tree.
------
В смысле - организованную хранимую структуру и аналогичный метод? - это врядли, я еще не настолько пьян...

Вот для BST как раз и возможны случаи с линейной зависимостью. Для B-дерева - нет.

ОК, я уже понял, что ты не знаешь, что такое B-дерево. Сравни - http://en.wikipedia.org/wiki/B-tree и http://en.wikipedia.org/wiki/Binary_search_tree