Как правильно организовать связь между таблицами

← →
Новичок (2007-11-12 18:13) [0]

Есть таблица /список физ.клиентов/ с полем Телефон
Есть таблица /список организаций/ с полем Телефон
Есть таблица /список телефонов/ с полем Телефон

Так вот мне хотелось бы связать эти таблицы, чтобы телефоны заносились в одну таблицу /список телефонов, по уникальному значению ИД клиентов, а поля телефон из двух первых таблиц убрать.

У меня вопрос, можно ли подчинить одну таблицу телефонов двум таблицам /физ.клиенты и организации/ ?

Если нет, то как правильно это сделать ?

← →
Reindeer Moss Eater © (2007-11-12 18:22) [1]

Это оптимизация ради оптимизации.
Одно мемо поле в каждой таблице и в нем список телефонов.
Третью таблицу удалить.

← →
Новичок (2007-11-12 21:03) [2]

> Одно мемо поле в каждой таблице и в нем список телефонов.
>
> Третью таблицу удалить.

Не плохо. Тогда вопрос:
в Мемо можно отследить повтор одинакового телефона. 3-я таблица сортировалась по телефону и если повтор то просто ссылка на существующий.

← →
vpbar © (2007-11-12 21:46) [3]

можно вроде

← →
Новичок (2007-11-12 22:50) [4]

Мастера поделитесь мненией, как бы вы поступили. Использовать Мемо или таблицу. Кроме этого я хочу использовать таблицу телефонов для обратного поиска.
Пример: зная телефон я могу найти клиента или организацию. С Мемо такое возможно ?

Заранее спасибо.

← →
ЮЮ © (2007-11-13 06:25) [5]

> Есть таблица /список физ.клиентов/ с полем Телефон
> Есть таблица /список организаций/ с полем Телефон

Во-первых, у физ.клиента, не говоря уж об организации, запросто может быть несколько телефонов.
Поэтому это д.б. не поле Телефон, а таблицы ТелефоныКлиентов и ТелефоныОрганизаций со связью один ко многим с
Клиенты и Организации, соответственно.

> Есть таблица /список телефонов/ с полем Телефон

Это имело бы смысл, если бы это было объектом предметной оласти, т.е. ты реально "создавал" номера телефонов и распределял их Клиентам и Организациям. А так номер телефона - просто атрибут.

> Пример: зная телефон я могу найти клиента или организацию.
> С Мемо такое возможно ?

Если клиентов и органицаций не очень много и полный скан таблицы не смущает, то - ради бога.
Почему сразу Мемо? VarChara не хватит?

← →
Sergey13 © (2007-11-13 08:16) [6]

А я бы еще подумал над объединением первых двух таблиц - возможно здорово облегчит жизнь в дальнейшем.

← →
Anatoly Podgoretsky © (2007-11-13 09:11) [7]

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

> чтобы телефоны заносились в одну таблицу /список телефонов,
> по уникальному значению ИД клиентов

И это тоже неверно, не по ИД клиентов надо связывать, а клиентов по ИД телефона. К клиента может быть более одного телефона и телефон может относиться более чем к одному клиенту. Так потребуется еще и организация связи Многие ко Многим.

> У меня вопрос, можно ли подчинить одну таблицу телефонов
> двум таблицам /физ.клиенты и организации/ ?

Если сделать как я написал, то можно но не нужно. Найти одним простым запросом принадлежность телефона клиенту будет нельзя.

← →
Новичок (2007-11-13 10:26) [8]

> Тут не с телефонов надо начинать, а с таблиц - разделение
> на физических лиц и организации уже не позволит делать нужное
> - поиск по номеру телефона.

Каюсь не уточнил. В таблице телефонов есть поле отвечающее за название (код) внешней таблицы.

Приведу таблицу.
CREATE TABLE "TEL_LIST"
(
"TEL_PHONE" VARCHAR(16) CHARACTER SET WIN1251 NOT NULL,
"TEL_ROD_CODE" INTEGER NOT NULL,
"TEL_REM" VARCHAR(25) CHARACTER SET WIN1251 NOT NULL,
"TEL_TYPE" SMALLINT,
"TEL_CODE" INTEGER,
"TEL_SUB" SMALLINT,
PRIMARY KEY ("TEL_PHONE")
);

← →
ЮЮ © (2007-11-13 10:39) [9]

> Каюсь не уточнил. В таблице телефонов есть поле отвечающее
> за название (код) внешней таблицы.

Это уже серьезнее, чем просто номер. Это уже на телефонную станцию похоже. :) Правда по идентификаторов полей фиг поймещь, что они значат.

> Так вот мне хотелось бы связать эти таблицы, чтобы телефоны
> заносились в одну таблицу /список телефонов, по уникальному
> значению ИД клиентов, а поля телефон из двух первых таблиц
> убрать.

Учитывая, что PRIMARY KEY ("TEL_PHONE"), то поля телефон в двух первых таблицах и есть поле связи с таблицей TEL_LIST, т.е. один телефон может быть у многих клиентов и организаций. Если ты хочешь организовать связь многие ко многим, то нужны отдельные таблицы см[5] c полями Клиент и Телефон, тогда поле Телефон из таблицы Клиент и впрямь можно убрать

← →
Новичок (2007-11-13 10:54) [10]

> тогда поле Телефон из таблицы Клиент и впрямь можно убрать

Правильно понял.

> Правда по идентификаторов полей фиг поймещь, что они значат.

TEL_TYPE - здесь 0 - организация, 1 - физ.лицо
TEL_ROD_CODE - уникальное значение записи благодаря триггеру
TEL_SUB - дополнительный номер для МиниАТС
TEL_REM - краткое описание КРТ
TEL_CODE уникальное значение записи благодаря триггеру (лишнее ?!)

← →
Новичок (2007-11-13 10:55) [11]

> TEL_ROD_CODE - уникальное значение записи благодаря триггеру

забыл дописать: внешней таблицы

← →
ЮЮ © (2007-11-13 11:10) [12]

> TEL_TYPE - здесь 0 - организация, 1 - физ.лицо
> TEL_ROD_CODE - уникальное значение записи благодаря триггеру
> TEL_SUB - дополнительный номер для МиниАТС
> TEL_REM - краткое описание КРТ
> TEL_CODE уникальное значение записи благодаря триггеру (лишнее
> ?!)

Ну вот, не телефонная станция :(

C такими атрибутами не стоит порождать сущность, которой нет. Т.е. надобности в такой таблице нет. А поле Телефон из Клиенты/Организации вынести в другую таблмцу исключительно для связи один ко многим. [5]

А причиной того, что таких таблиц получается 2 - одна для физ лиц, другая - для организаций, возможная ошибка в проектировании (не был выделен общий предок для этих двух сущностей).

> TEL_CODE уникальное значение записи благодаря триггеру (лишнее
> ?!)

Как раз самое нужное, только обычно это называют ID
А вот TEL_TYPE как раз лишнее, особенно если расматривать вариант, что телефон может принадлежать не одному лицу, в том числе возможен вариант, что это и организация и частное лицо. Принадлежность в таблице телефонов вообще быть не должно, это делается в другом направление или от клиента к телефонам, или таблица Многие ко многим, что правильнее.

> TEL_ROD_CODE - уникальное значение записи благодаря триггеру
> TEL_SUB - дополнительный номер для МиниАТС

Эти поля вообще не понятны, какой еще ROD, а TEL_SUB это часть номера, а не отдельный номер. То есть таблицу можно уменьшить до двух полей ID и REM

Найди информацию по нормальным формам, иначе у тебя получится (уже есть) уродец, трудно управляемый, с аномалиями.

← →
Новичок (2007-11-13 19:02) [15]

> Anatoly Podgoretsky © (13.11.07 11:30) [13]

Спасибо большое

> Anatoly Podgoretsky © (13.11.07 11:31) [14]

Уже нашел

Имелось в виду ID (Integer, PK), PhoneNumber(varchar), Rem(Text/Memo)

← →
Новичок (2007-11-13 21:24) [17]

еще один вопрос. Как сделать TIMESTAMP при сохранения записи.

В парадоксе это просто :

TABLE1.BEFOREPOST
BEGIN
TABLE1.TIMESTAMP:=NOW;
END;

← →
Новичок (2007-11-13 21:36) [18]

Так нагляднее:

procedure TDataModule1.Table1BeforePost(DataSet: TDataSet);
begin
table1.FieldByName("LastModify").AsDateTime:=Now;
end;

> Anatoly Podgoretsky © (13.11.07 19:12) [16]
> Имелось в виду ID (Integer, PK), PhoneNumber(varchar), Rem(Text/Memo)

Еще раз спасибо

Как правильно организовать связь между таблицами Найти похожие ветки