Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

"Внебрачные отношения." [D6, D7, fb2]

Страницы: 1 2 >
Mike Kouzmine © (2008-01-21 14:22:00)
Имеет место быть.
Манагеры
Клиенты
Фирмы клиентов
Отношения
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 не держал шашек в руках.

ЮЮ (2008-01-22 11:55:00) [1]
> Блин. Надо в NUM_CL добавить ссылку на реквизиты и все.

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

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

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

Petr V. Abramov (2008-01-21 20:24:00) [2]

> 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, манагера выгонят, безнадежные долги клиентов на нем остаться должны, а не на новом. Или в таблице поставок храни ссылку на манагера, тогда прокладка не нужна.

Mike Kouzmine (2008-01-21 16:56:00) [3]
Sergey13 © (21.01.08 16:49) [19] Я это и хотел сделать. Блин. Надо в NUM_CL добавить ссылку на реквизиты и все. Спасибо.

Mike Kouzmine (2008-01-21 16:51:00) [4]
При производстве один завод может иметь несколько фирм для закупки разнородных комплектующих (по стране производителю, таможенной группе или прочими различающимися индивидуальными признаками), таким образом, имея в штате фирмы манагеров, торгующих каждый своим товаром, мы получаем, что с одним заводом может работать несколько манагеров (по разным направлениям и с разным процентом соответственно). Для выверки глобальной, мы должны вмдеть все фирмы, логически работающие под данный завод, проценты манагеров и прочие выборки.

Sergey13 (2008-01-21 16:49:00) [5]
> [17] Mike Kouzmine (21.01.08 16:43)

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

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

Mike Kouzmine (2008-01-21 16:43:00) [7]
Sergey13 © (21.01.08 15:55) [10] Другими словами

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

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

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

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

Sergey13 (2008-01-21 16:41:00) [8]
> [15] Mike Kouzmine (21.01.08 16:38)
> NUM_CLIENT для манагера может открытым множеством.

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

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

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

clickmaker (2008-01-21 16:10:00) [10]

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

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

Kolan (2008-01-21 16:09:00) [11]
> Если строишь физическую модель в каком-нибудь Повер Десигнере,
> то эта проблема решается сама собой — он сам тебе все сгенерит.

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

clickmaker (2008-01-21 16:07:00) [12]

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

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

Kolan (2008-01-21 15:59:00) [13]
> подобные ограничения лучше делать на клиенте.

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

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

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

Sergey13 (2008-01-21 15:55:00) [14]
> [9] Mike Kouzmine (21.01.08 15:47)

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

Mike Kouzmine (2008-01-21 15:47:00) [15]
Sergey13 © (21.01.08 15:39) [7] Да, причем иметь разные проценты.

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

Sergey13 (2008-01-21 15:39:00) [17]
> [4] Mike Kouzmine (21.01.08 15:16)

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

clickmaker (2008-01-21 15:22:00) [18]

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

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

Kolan (2008-01-21 15:18:00) [19]
> Неуверен где — на клиенте или сервере?

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

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

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

Mike Kouzmine (2008-01-21 15:16:00) [20]
У манагера может быть один клиент, у клиента много манагеров, но не больше реквизитов (фирм платящих). Манагеры могут иметь любые фирмы клиентов. Причем, разные манагеры могут иметь реквизиты разных клиентов (контолировать платящие фирмы). Плюс в ареале одного клиента (имеющего много платящих фирм), для каждого манагера (реквизита клиента) имеется свой процент оплаты.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »