Trigger - kontrola wprowadzonych danych

0

Witajcie. MS SQL Server 2008 R2.

W uproszczonym modelu: mam tabelkę z dwiema kolumnami:

CREATE TABLE [dbo].[Products](
	[Design Code] [nvarchar](20) NOT NULL,
	[Material] [nvarchar](100) NOT NULL)

Mam jakieś produkty, których [Material] może być użyty tylko i wyłącznie w przypadku, gdy Material istnieje w tej tabeli jako [Design Code].

Przykład:

INSERT INTO Products([Design Code], [Material])
VALUES ('Przykladowy', 'Przykladowy')

musi być w tabeli zanim będę mógł wprowadzić np.:

INSERT INTO Products([Design Code], [Material])
VALUES ('Przykladowy_1', 'Przykladowy'),
('Przykladowy_2', 'Przykladowy'),
('Przykladowy_3', 'Przykladowy'),
('Przykladowy_4', 'Przykladowy')

czyli wariant _1, _2 itd danego materiału. Żeby dodać Design Code z jakimś Material, ten Material musi być wcześniej utworzony jako Design Code. [Design Code] = [Material] czyli ta sama wartość w obu kolumnach w jakimś wierszu.

Chciałbym to zrobić triggerem "after insert, update" i po części skleiłem jakiś kod, ale jest nieoptymalny, sypie mi błędami i ogólnie jest jakaś masakra, szczególnie w linked table z accessem.

Jak powinien wyglądać ten trigger? Może być to zapisane pseudokodem lub algorytmem opisowym.

Dzięki.

0

Ale po co tu trigger? Tu jest potrzebny klucz obcy.

0
somekind napisał(a):

Ale po co tu trigger? Tu jest potrzebny klucz obcy.

W jaki sposób? Bo przypadek wymusza żeby to była jedna tabela, mało tego [Design Code] jest unikatowy (zapomniałem napisać), a w zasadzie jest kluczem podstawowym.

0

nvarchar jako klucz podstawowy, no cóż, widocznie wydajność nie jest potrzebna...

Ja nie bardzo rozumiem, co ma zrobić ten trigger. Ani czemu to jest jedna tabela, skoro od razu widać, że powinny być dwie.

0

Nie jest, w tabeli jest około 300 rekordów, docelowo będzie około 600, ta baza nie ma nic wspólnego z good practices...

Już sobie poradziłem triggerem, udało się to zrobić za pomocą INSTEAD OF a nie AFTER.

Do zamknięcia.

1 użytkowników online, w tym zalogowanych: 0, gości: 1