"Внебрачные отношения."

← →
Mike Kouzmine (2008-01-21 14:22) [0]

Имеет место быть.
Манагеры
Клиенты
Фирмы клиентов
Отношения
1 Клиенты имеют любое количество "фирм клиетнтов" и индекс клиент-фирма клиента - уникален
2 манагеры имеют любые "фирмы клиентов" - один к одному
Что сделал
CREATE TABLE CL_MAN (
CLIENT_NUM INTEGER NOT NULL,
MANAGER_NUM INTEGER NOT NULL
);

CREATE TABLE CLIENTS (
NUM INTEGER NOT NULL,
NICK VARCHAR(20) NOT NULL,
NAME VARCHAR(100) COLLATE PXW_CYRL
);

CREATE TABLE MANAGERS (
NUM INTEGER NOT NULL,
NICK VARCHAR(20) NOT NULL,
FIRSTNAME VARCHAR(20) COLLATE PXW_CYRL,
SECONDNAME VARCHAR(20) COLLATE PXW_CYRL,
LASTNAME VARCHAR(20) COLLATE PXW_CYRL,
NOTE VARCHAR(200) COLLATE PXW_CYRL
);

CREATE TABLE REKVISTS (
NUM INTEGER NOT NULL,
NICK VARCHAR(20) NOT NULL COLLATE PXW_CYRL,
NUM_CLIENT INTEGER,
NAME VARCHAR(40) NOT NULL COLLATE PXW_CYRL,
INN VARCHAR(20) NOT NULL COLLATE PXW_CYRL,
KPP VARCHAR(20) COLLATE PXW_CYRL,
PERCENT DOUBLE PRECISION DEFAULT 0 NOT NULL
);

/******************************************************************************/
/**** Primary Keys ****/
/******************************************************************************/

ALTER TABLE CLIENTS ADD CONSTRAINT PK_CLIENTS PRIMARY KEY (NUM);
ALTER TABLE CL_MAN ADD CONSTRAINT PK_CL_MAN PRIMARY KEY (CLIENT_NUM, MANAGER_NUM);
ALTER TABLE MANAGERS ADD CONSTRAINT PK_MANAGERS PRIMARY KEY (NUM);
ALTER TABLE REKVISTS ADD CONSTRAINT PK_REKVISTS PRIMARY KEY (NUM);

/******************************************************************************/
/**** Foreign Keys ****/
/******************************************************************************/

ALTER TABLE CL_MAN ADD CONSTRAINT FK_CL_MAN_1 FOREIGN KEY (CLIENT_NUM) REFERENCES CLIENTS (NUM) ON DELETE CASCADE ON UPDATE CASCADE;
ALTER TABLE CL_MAN ADD CONSTRAINT FK_CL_MAN_2 FOREIGN KEY (MANAGER_NUM) REFERENCES MANAGERS (NUM) ON DELETE CASCADE ON UPDATE CASCADE;

/******************************************************************************/
/**** Indices ****/
/******************************************************************************/

CREATE UNIQUE INDEX MANAGERS_IDX1 ON MANAGERS (NICK);
CREATE UNIQUE INDEX REKVISTS_IDX1 ON REKVISTS (NICK);
CREATE INDEX REKVISTS_IDX2 ON REKVISTS (NUM_CLIENT);
CREATE UNIQUE INDEX REKVISTS_IDX3 ON REKVISTS (INN);

Что надо
Сделать вышеуказанные отношения.
Неуверен где - на клиенте или сервере?
Если где, то как лучше?

Подробностей не надо, только развернутый намек, ибо лет 7 не держал шашек в руках.

← →
clickmaker © (2008-01-21 15:00) [1]

> Неуверен где - на клиенте или сервере?

в каком смысле на клиенте сделать отношения?

← →
Mike Kouzmine (2008-01-21 15:01) [2]

Имеется "прокладка"
CREATE TABLE CL_MAN (
CLIENT_NUM INTEGER NOT NULL,
MANAGER_NUM INTEGER NOT NULL
);
Нужна ли она. Если нужна, то кде поля заполнять или можно сделать это с помощью сервера?

← →
clickmaker © (2008-01-21 15:08) [3]

CREATE TABLE CL_MAN (
CLIENT_NUM INTEGER NOT NULL,
MANAGER_NUM INTEGER NOT NULL
);

это что за отношение?
клиенты манагера?

← →
Mike Kouzmine (2008-01-21 15:16) [4]

У манагера может быть один клиент, у клиента много манагеров, но не больше реквизитов (фирм платящих). Манагеры могут иметь любые фирмы клиентов. Причем, разные манагеры могут иметь реквизиты разных клиентов (контолировать платящие фирмы). Плюс в ареале одного клиента (имеющего много платящих фирм), для каждого манагера (реквизита клиента) имеется свой процент оплаты.

← →
Kolan © (2008-01-21 15:18) [5]

> Неуверен где  на клиенте или сервере?

Связки, что-ли ? На сервере ессною

> У манагера может быть один клиент, у клиента много манагеров

Странновато, там скорее ногие ко многим связь в действительности&#133

← →
clickmaker © (2008-01-21 15:22) [6]

> У манагера может быть один клиент, у клиента много манагеров,
> но не больше реквизитов (фирм платящих).

подобные ограничения лучше делать на клиенте. При условии, конечно, что в базу напрямую никто не лезет.
При ограничених на серваке, юзер получит ничего не говорящее ему исключение типа constraint violation и чего он будет делать?
Описать эти ограничения можно и в самой базе, чтобы при изменении условий (а вдруг) не пришлось править if"ы в коде

← →
Sergey13 © (2008-01-21 15:39) [7]

> [4] Mike Kouzmine (21.01.08 15:16)

А одна фирма может обслуживаться несколькими менеджерами?

← →
Mike Kouzmine (2008-01-21 15:45) [8]

clickmaker © (21.01.08 15:22) [6] Я так и буду делать. Единственно, смущает прокладка. Безусловно процедура (на фб2 я видел возможность ее инициализации по событию) универсальнее, но нет ли подводных и прочих камней?
Kolan © (21.01.08 15:18) [5] Было бы именно так в чистом виде, вопросов не возникло бы.

← →
Mike Kouzmine (2008-01-21 15:47) [9]

Sergey13 © (21.01.08 15:39) [7] Да, причем иметь разные проценты.

← →
Sergey13 © (2008-01-21 15:55) [10]

> [9] Mike Kouzmine (21.01.08 15:47)

Тогда NUM_CLIENT можно добавить в таблицу манагеров. А вместо CL_MAN сделать REKVISTS_MAN, куда и писать эти самые проценты. Я бы наверное так сделал.

← →
Kolan © (2008-01-21 15:59) [11]

> подобные ограничения лучше делать на клиенте.

Странный совет, а какже ссылочная целостность?

> При ограничених на серваке, юзер получит ничего не говорящее
> ему исключение типа constraint violation и чего он будет
> делать?

Сервер должен правильно работать, в не зав от клиента. То есть на нем должны быть правильные ограничения.
А чтобы не пугать пользователя constraint violation надо чтобы и клиент проверял&#133

← →
clickmaker © (2008-01-21 16:07) [12]

> Странный совет, а какже ссылочная целостность?

Если строишь физическую модель в каком-нибудь Повер Десигнере, то эта проблема решается сама собой - он сам тебе все сгенерит.
И, плюс к этому, нужно грамотно добавление-удаление делать.
Лично я вообще противник всяких триггеров-каскадных операций - логика скрыта от внимания.
Лучше все делать в хранимках, в транзакциях.

← →
Kolan © (2008-01-21 16:09) [13]

> Если строишь физическую модель в каком-нибудь Повер Десигнере,
> то эта проблема решается сама собой  он сам тебе все сгенерит.

Ну ты же советуешь как я понял. Просто сделать нужные таблицы, а за всеми связями следить на клиенте&#133

← →
clickmaker © (2008-01-21 16:10) [14]

> а за всеми связями следить на клиенте

я не за связями советовал следить, а за ограничениями

← →
Mike Kouzmine (2008-01-21 16:38) [15]

Sergey13 © (21.01.08 15:55) [10] Тогда NUM_CLIENT можно добавить в таблицу манагеров. А вместо CL_MAN сделать REKVISTS_MAN, куда и писать эти самые проценты. Я бы наверное так сделал.

Неправильно объяснил. NUM_CLIENT для манагера может открытым множеством. Как устроить?

← →
Sergey13 © (2008-01-21 16:41) [16]

> [15] Mike Kouzmine (21.01.08 16:38)
> NUM_CLIENT для манагера может открытым множеством.

Не понял. Один менеждер может работать с несколькими фирмами ТОЛЬКО ОДНОГО клиента? Так.

← →
Mike Kouzmine (2008-01-21 16:43) [17]

Sergey13 © (21.01.08 15:55) [10] Другими словами

- Фирма1 - процент1
- Клиент1 - Фирма2 - процент2

Манагер - Клиент2 - Фирма3 - процент3

- Клиент1 - Фирма4 - процент4

Пример одного манагера

← →
Mike Kouzmine (2008-01-21 16:44) [18]

Sergey13 © (21.01.08 16:41) [16] Нет несколько манагеров может работать с одним клиентом, имеющим разные реквизиты (платящие фирмы) и, соответственно, имеющими разные проценты оплаты для манагера.

> [17] Mike Kouzmine (21.01.08 16:43)

Ах вон как! Ну тогда наверное надо дополнить CL_MAN ссылкой на REKVISTS и добавить туда же процент.

← →
Mike Kouzmine (2008-01-21 16:51) [20]

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

← →
Mike Kouzmine (2008-01-21 16:56) [21]

> Mike Kouzmine (21.01.08 15:01) [2]
> Имеется "прокладка"
> CREATE TABLE CL_MAN (
> CLIENT_NUM INTEGER NOT NULL,
> MANAGER_NUM INTEGER NOT NULL
> );
> Нужна ли она. Если нужна, то кде поля заполнять или можно
> сделать это с помощью сервера?

нужна, добавь туда date_from и date_to, манагера выгонят, безнадежные долги клиентов на нем остаться должны, а не на новом. Или в таблице поставок храни ссылку на манагера, тогда прокладка не нужна.

> Блин. Надо в NUM_CL добавить ссылку на реквизиты и все.

Тогда
1) ссылка на клиента - лишняя
2)
>что с одним заводом может работать несколько манагеров (по разным направлениям и с разным процентом соответственно).

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

Поэтому проценты всё-таки лучше - в таблицу связи.

"Внебрачные отношения." Найти похожие ветки