А в чем физический смысл?
Думаю, стоит задуматься над целесообразностью такого подхода, и в конечном итоге, над более детальной проработкой модели БД.
Если забить на всё и сделать так:
CREATE TABLE test1
(
test1 integer NOT NULL,
CONSTRAINT pk_test1 PRIMARY KEY (test1)
)
WITH (OIDS=FALSE);
CREATE TABLE test2
(
test2 integer NOT NULL,
CONSTRAINT pk_test2 PRIMARY KEY (test2)
)
WITH (OIDS=FALSE);
CREATE TABLE test
(
test integer,
CONSTRAINT fk_test1 FOREIGN KEY (test)
REFERENCES test1 (test1) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT fk_test2 FOREIGN KEY (test)
REFERENCES test2 (test2) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
то в столбец test таблицы test можно будет записать только значения, которые есть и в столбце test1 таблицы test1, и в столбце test2 таблицы test2 (а не "или-или")
Условие И неподходит. Опишу по подробнее.
Усть таблица с поставщиками и таблица с сотрудниками, и у обоих есть адреса, причем адрес может быть не один. Вот я и решил сделать отдельную таблицу в которой размещать адрес и указывать чей это адрес (ссылаться). Можно конечно сделать 2 таблицы с адресами, но наклевываются еще пару таблиц для которых тоже будут нужны адреса. Подскажите пожет есть другие варианты?
1. Создать таблицу с адресами, где в качестве первичного ключа будет поле типа integer или например, numeric(6) - кому как нравится.
2. В таблицах с контрагентами и сотрудниками хранить не сами адреса, а создать поле с тем типом, о котором было упомянуто выше.
3. А вот по этим полям и создать Foreign Key на первичный ключ таблицы адресов.
На самом деле, в таблице адресов лучше хранить не сам адрес, а код улицы и номер дома. Т.е. нужна будет еще таблица с улицами с первичным ключем по коду. А в таблицах с контрагентами и поставщиками тогда будет храниться код строения и номер квартиры (кабинета).
И тогда запрос по выборке контрагентов/сотрудников будет похож на этот http://postgresql.ru.net/node/161002
Настоятельно рекомендую почитать литературу по проектированию БД, в частности про нормализацию.
можно для всех таблиц, где будет использоваться адрес, брать значение первичного ключа из одного сиквенса и/или наследовать все эти таблицы от одной базовой. Дальше организовать связь много-ко-многим с адресами.
я не претендую на первое место, просто накидываю варианты, какой удобней - пусть выбирает автор.
Мой вариант предусматривает наличие нескольких адресов для одного контрагента, как изложено в задаче - для этого нужна связь много-ко многим либо, чтобы внешний ключ был на таблице адресов, а так как у нас несколько внешних таблиц, то реализовать "родной" внешний ключ не получится... или я ошибаюсь?
я когда-то работал с ms navision - там это реализовано родными средствами - можно ссылаться на несколько таблиц, используя при связи поле, которое определяло "тип связи" и таблицу
Наличие альтернатив всегда хорошо.
Просто я подхожу с позиций создания достаточно нормализованной БД.
Если необходимо несколько адресов для одного контрагента, то удобно использовать такую схему:
табл. Улицы (КодУлицы pr.key, Имя)
табл. Дома (КодДома pr.key, КодУлицы fr.key, НомерДома)
табл. КлиентАдрес (КодКл fr.key, КодДома fr.key, Кабинет)
табл. Клиент (КодКл pr.key, Имя)
Т.е. многие-ко-многим заменено/реализовано через таблицу посредник КлиентАдрес
вы по-моему просмотрели суть вопроса.
Как будет организована сама таблица адресов - это вопрос десятый.
Самое главное таблица Клиент - не будет одна, будут еще Организации, Сотрудники, Партнеры, и черти еще кто... и их всех надо связать с таблицей адресов, причем у каждого по несколько адресов.
Признаю, не стал расписывать схему, необходимую для вопрошающего.
Как Вам такой вариант:
табл. Улицы (КодУлицы pr.key, Имя)
табл. Дома (КодДома pr.key, КодУлицы fr.key, НомерДома)
табл. Адрес (КодАдресата fr.key, КодДома fr.key, Кабинет)
табл. Адресат (КодАдресата pr.key, Примечания)
табл. Клиенты (КодКлиента pr.key, КодАдресата fr.key, Название, Реквизиты)
табл. Сотрудники (КодСотрудника pr.key, КодАдресата fr.key, ФИО)
табл. ... бог знает кто ещё ...
На самом деле даже и не надо было бы городить всех этих "бог знает кто". Так как сводятся они банально к физ.лицам и юр.лицам.
Да это практически готовая схема по "тех.заданию"!
А ведь наводки для создания такой схемы я уже давал! Нужно было лишь вникнуть в суть и немножко подумать. Кстати, именно так я и представляю себе предназначение форума - указать направление мысли, а не делать всю работу за того, кто спрашивает, ибо это "медвежья услуга".
Реально, сам бы я навряд ли стал строить БД по такой схеме. Дело не в схеме, а в "тех.задании".
Вот очередные наводки:
- в реальности нет необходимости создавать для каждой сущности, имеющей адрес, свою таблицу. т.к. есть "юр.лица" и "физ.лица", а кто они - поставщики, клиенты, субконтрпуперагенты - это лишь деление на группы, для которых и нужно создать таблицу группы.
- сколько в реальности необходимо хранить адресов? для физ.лица - адрес регистрации и адрес проживания, для юр.лиц - юр.адрес и фактический адрес. т.е. надо-то всего лишь по два поля в этих таблицах, а не кучу всяких табличек с сомнительными отношениями.
Пища для размышлений есть. Удачи!
не совсем понятно
А в чем физический смысл?
Думаю, стоит задуматься над целесообразностью такого подхода, и в конечном итоге, над более детальной проработкой модели БД.
Если забить на всё и сделать так:
CREATE TABLE test1
(
test1 integer NOT NULL,
CONSTRAINT pk_test1 PRIMARY KEY (test1)
)
WITH (OIDS=FALSE);
CREATE TABLE test2
(
test2 integer NOT NULL,
CONSTRAINT pk_test2 PRIMARY KEY (test2)
)
WITH (OIDS=FALSE);
CREATE TABLE test
(
test integer,
CONSTRAINT fk_test1 FOREIGN KEY (test)
REFERENCES test1 (test1) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT fk_test2 FOREIGN KEY (test)
REFERENCES test2 (test2) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (OIDS=FALSE);
то в столбец test таблицы test можно будет записать только значения, которые есть и в столбце test1 таблицы test1, и в столбце test2 таблицы test2 (а не "или-или")
Условие И неподходит
Условие И неподходит. Опишу по подробнее.
Усть таблица с поставщиками и таблица с сотрудниками, и у обоих есть адреса, причем адрес может быть не один. Вот я и решил сделать отдельную таблицу в которой размещать адрес и указывать чей это адрес (ссылаться). Можно конечно сделать 2 таблицы с адресами, но наклевываются еще пару таблиц для которых тоже будут нужны адреса. Подскажите пожет есть другие варианты?
конечно есть, единственно верное
1. Создать таблицу с адресами, где в качестве первичного ключа будет поле типа integer или например, numeric(6) - кому как нравится.
2. В таблицах с контрагентами и сотрудниками хранить не сами адреса, а создать поле с тем типом, о котором было упомянуто выше.
3. А вот по этим полям и создать Foreign Key на первичный ключ таблицы адресов.
На самом деле, в таблице адресов лучше хранить не сам адрес, а код улицы и номер дома. Т.е. нужна будет еще таблица с улицами с первичным ключем по коду. А в таблицах с контрагентами и поставщиками тогда будет храниться код строения и номер квартиры (кабинета).
И тогда запрос по выборке контрагентов/сотрудников будет похож на этот http://postgresql.ru.net/node/161002
Настоятельно рекомендую почитать литературу по проектированию БД, в частности про нормализацию.
можно для всех
можно для всех таблиц, где будет использоваться адрес, брать значение первичного ключа из одного сиквенса и/или наследовать все эти таблицы от одной базовой. Дальше организовать связь много-ко-многим с адресами.
ну или так
но тут придется констрейнты заменить на проверки и триггеры
лучший вариант?
Не сочтите за наезд, но Вы считаете это лучшим вариантом или предложили в качестве "давайте разомнем мозги" ?
я не претендую
я не претендую на первое место, просто накидываю варианты, какой удобней - пусть выбирает автор.
Мой вариант предусматривает наличие нескольких адресов для одного контрагента, как изложено в задаче - для этого нужна связь много-ко многим либо, чтобы внешний ключ был на таблице адресов, а так как у нас несколько внешних таблиц, то реализовать "родной" внешний ключ не получится... или я ошибаюсь?
я когда-то работал с ms navision - там это реализовано родными средствами - можно ссылаться на несколько таблиц, используя при связи поле, которое определяло "тип связи" и таблицу
я не о том, кто круче
Наличие альтернатив всегда хорошо.
Просто я подхожу с позиций создания достаточно нормализованной БД.
Если необходимо несколько адресов для одного контрагента, то удобно использовать такую схему:
табл. Улицы (КодУлицы pr.key, Имя)
табл. Дома (КодДома pr.key, КодУлицы fr.key, НомерДома)
табл. КлиентАдрес (КодКл fr.key, КодДома fr.key, Кабинет)
табл. Клиент (КодКл pr.key, Имя)
Т.е. многие-ко-многим заменено/реализовано через таблицу посредник КлиентАдрес
вы по-моему
вы по-моему просмотрели суть вопроса.
Как будет организована сама таблица адресов - это вопрос десятый.
Самое главное таблица Клиент - не будет одна, будут еще Организации, Сотрудники, Партнеры, и черти еще кто... и их всех надо связать с таблицей адресов, причем у каждого по несколько адресов.
ключевым было: "многие-ко-многим" через таблицу-посредник
Признаю, не стал расписывать схему, необходимую для вопрошающего.
Как Вам такой вариант:
табл. Улицы (КодУлицы pr.key, Имя)
табл. Дома (КодДома pr.key, КодУлицы fr.key, НомерДома)
табл. Адрес (КодАдресата fr.key, КодДома fr.key, Кабинет)
табл. Адресат (КодАдресата pr.key, Примечания)
табл. Клиенты (КодКлиента pr.key, КодАдресата fr.key, Название, Реквизиты)
табл. Сотрудники (КодСотрудника pr.key, КодАдресата fr.key, ФИО)
табл. ... бог знает кто ещё ...
На самом деле даже и не надо было бы городить всех этих "бог знает кто". Так как сводятся они банально к физ.лицам и юр.лицам.
такой вариант уже вполне съедобный
--
"уже вполне" :-)
Да это практически готовая схема по "тех.заданию"!
А ведь наводки для создания такой схемы я уже давал! Нужно было лишь вникнуть в суть и немножко подумать. Кстати, именно так я и представляю себе предназначение форума - указать направление мысли, а не делать всю работу за того, кто спрашивает, ибо это "медвежья услуга".
Реально, сам бы я навряд ли стал строить БД по такой схеме. Дело не в схеме, а в "тех.задании".
Вот очередные наводки:
- в реальности нет необходимости создавать для каждой сущности, имеющей адрес, свою таблицу. т.к. есть "юр.лица" и "физ.лица", а кто они - поставщики, клиенты, субконтрпуперагенты - это лишь деление на группы, для которых и нужно создать таблицу группы.
- сколько в реальности необходимо хранить адресов? для физ.лица - адрес регистрации и адрес проживания, для юр.лиц - юр.адрес и фактический адрес. т.е. надо-то всего лишь по два поля в этих таблицах, а не кучу всяких табличек с сомнительными отношениями.
Пища для размышлений есть. Удачи!