Структура БД.

← →
картман © (2009-07-21 16:21) [0]

Всем доброго времени суток!

Есть редактируемый древовидный список неких тем для сообщений. Есть список шаблонов(для постановки вопроса не важно, что за шаблоны), каждый из которых(список шаблонов) может быть связан с темой, а может и нет.
Т.е. при использовании шаблонов для тем связь между ними должна быть, а при создании - не обязательно. Т.о. внешний ключ не подходит.
Как реализовать? Не решается ли это тем, что называют "ограничением"?

← →
картман © (2009-07-21 16:22) [1]

SQL Server 2005. связь - один к одному, поэтому таблицу вводить не хочется

← →
Ega23 © (2009-07-21 16:25) [2]

> Т.о. внешний ключ не подходит.

Внешний ключ подходит всегда. Читайте про NULL / NOT NULL

З.Ы. Если под термином "ограничение" подразумевается constraint, то спешу тебя огорчить: ключи, как первичный, так и вторичный, тоже являются constraint-ами

← →
картман © (2009-07-21 16:38) [3]

> Ega23 © (21.07.09 16:25) [2]

> Внешний ключ подходит всегда. Читайте про NULL / NOT NULL

Спасибки.

← →
Anatoly Podgoretsky © (2009-07-21 16:51) [4]

> картман (21.07.2009 16:22:01) [1]

Чем обусловлена такая связь? Это же обычно делают из-за недостатков движка.

← →
картман © (2009-07-21 18:26) [5]

> Anatoly Podgoretsky © (21.07.09 16:51) [4]

Пожалуй да, Вы правы, но на данном этапе не совсем ясно, как это должно все быть - не известно, пока, какая из данных сущностей первична

← →
Petr V. Abramov © (2009-07-21 18:53) [6]

> каждый из которых(список шаблонов) может быть связан с темой,

а если шаблон потом поменялся, старые темы будут выглядеть по-новому? :)

← →
картман © (2009-07-21 21:56) [7]

> Petr V. Abramov © (21.07.09 18:53) [6]

нет. Шаблонами задаются критерии поиска и выделения нужного текста в сообщениях, на основании чего они(сообщения) потом связываются с темой. Если поменяется шаблон, то и результаты поиска, соответственно, нужно будет обновить - в этом плане темы будут выглядеть по-новому:)

← →
Petr V. Abramov © (2009-07-21 23:45) [8]

> этом плане темы будут выглядеть по-новому:)

лично я б такой форум выкинул бы после смены шаблоныа
а уж в поиске, если б искал по "картман", а там бы в резалте Anatoly Podgoretsky © - ТУДЫ НИЗАШТО

← →
Юрий Зотов © (2009-07-22 00:04) [9]

А я не въехал, в чем проблема? Вроде бы, все просто. Например:

Таблица тем:
ID (Int, PK, больше 0)
Parent_ID (Int, not null, ссылка на родительскую тему, для корневой темы 0)

Таблица шаблонов:
ID (Int, PK, больше 0)
Body (нужного типа, not null, сам шаблон)
Theme_ID (Int, ссылка на связанную тему или null)

← →
картман © (2009-07-22 00:35) [10]

> Юрий Зотов © (22.07.09 00:04) [9]

да это я, того... не знал(не вспомнил) про null... собсна тут
> Ega23 © (21.07.09 16:25) [2]

все сказали-подсказали

← →
картман © (2009-07-22 00:37) [11]

> Petr V. Abramov © (21.07.09 23:45) [8]

> лично я б такой форум выкинул бы после смены шаблоныа

это не для форума - анализ СМИ:)

← →
Ega23 © (2009-07-22 09:59) [12]

> Parent_ID (Int, not null, ссылка на родительскую тему, для
> корневой темы 0)

э-э-э... А как ты вторичный ключ будешь накладывать на него, если он not null???

← →
Юрий Зотов © (2009-07-22 13:10) [13]

> Ega23 © (22.07.09 09:59) [12]

Не въезжаю, поясни.

← →
Ega23 © (2009-07-22 13:32) [14]

> Не въезжаю, поясни.

Ну, как правило, для сохранения целостности данных, в иерархической таблице накладывают вторичный ключ на саму себя.
В связи с этим вопрос: если поле ParentID not null, то как мы вставим туда корневую запись?

← →
sniknik © (2009-07-22 13:37) [15]

> то как мы вставим туда корневую запись?
а null для этого не обязателен, можно и 0 или -1 например.
главное чтобы он не был UNIQUE... (что может быть если связь как написано в [1] один к одному)

← →
Ega23 © (2009-07-22 13:43) [16]

> а null для этого не обязателен, можно и 0 или -1 например.

О-па...
create table ttt ( id int not null, parid int not null, constraint pk_ttt primary key (id) ) alter table ttt add constraint fk_ttt_ttt foreign key (parid) references ttt (id); insert into ttt values (1,1)

сработало. А раньше такое не прокатывало....

← →
Юрий Зотов © (2009-07-22 14:22) [17]

> если поле ParentID not null, то как мы вставим туда корневую запись?

Я же сразу написал - для корня 0. Не null, а ноль.

Значения в поле ID начинаются с 1, поэтому ноль в поле Parent_ID означает отсутствие родительской записи - то есть, корень.

> Значения в поле ID начинаются с 1, поэтому ноль в поле Parent_ID
> означает отсутствие родительской записи - то есть, корень.

Да пофиг с чего оно начинается. Вторичный ключ - предполагается, что значение должно быть вставлено из множества значений первичного ключа, либо NULL (если он разрешён). А у нас ещё ни одной записи нет.

Вот сейчас у меня запись вставилась. Испытывал на MSSQL 2005 EE. На 2000 такое, вроде, не прокатывало.

> На 2000 такое, вроде, не прокатывало.
проверил [16], работает, да в общем то и не сомневался т.к. у меня до сих пор основной, это 2000й mssql, и если бы ограничение было то где нибудь уже вылезло бы.

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

т.е. с чем то, что (добавление) вырождается в запись типа (изменение id - автоинкремент)

insert into ttt default values update ttt set parid = 2 where id = @@identity

> проверил [16], работает, да в общем то и не сомневался т.
> к. у меня до сих пор основной, это 2000й mssql

Может опять настройки какие?
Вобщем, была у меня такая проблема когда-то. Плюнул слюной и null поставил.

> может ты путаешь с вариантом редактирования типа в гриде
> или еще где

не-не-не, Дэвид Блейн, я в гриде отродясь не редактировал

Юрий Зотов © (22.07.09 14:22) [17]
Тут разница в том, что есть парент not null, то должна существовать общая корневая запись с ID = ParentID = (0)
Если nullable, то ее может не быть, то есть получается лес.

> то есть получается лес.
а какая разница из какого "корня" растет лес?

к примеру выше
insert into ttt values (0, 0)
insert into ttt values (0, 2)
insert into ttt values (0, 3)

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

p.s. имхо, отвлекаетесь на пустяки.

Структура БД. Найти похожие ветки