powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура БД и совместное использование двух сущностей
2 сообщений из 2, страница 1 из 1
Структура БД и совместное использование двух сущностей
    #35551829
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Прошу прощения за повтор. Стало понятно, что конкретную задачу в общем виде решить сложно, поэтому изложу проблему пдробнее и попрошу вашей помощи снова.
Разрабатывается задача по ремонту оборудования.
В базе данных (ORACLE) хранится информация об оборудовании завода (далее - основные фонды, ОФ). Струтктура хранения этой ифнормации разрабоатвывается сторонней организацией и не может быть изменена, поэтому используется как есть.
А есть вот что (приведу только текст вьюшки)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
create or replace view repair_basic_stock_view as
select  1  as STOCK_TYPE,  -- Указатель, что это ОФ
       BS.*,
       I.INVNUM as STOCK_NO,
  from INVNUMBERS I,
       (select E.INVNUM_CODE as STOCK_CODE,
               N.TEXT as NAME,
               M.TEXT as MODEL,
               ...
          from EQUIPMENTS         E,
               EQUIPMENTDIRECTORY N,
               EQUIPMENTDIRECTORY M
         where E.NAME_CODE = N.CODE
           and E.MODEL_CODE = M.CODE
        union all
        select A.INVNUM_CODE as STOCK_CODE,
               A.NAME,
               M.TEXT as MODEL,
               ...
          from AUTOMATICLINES     A,
               EQUIPMENTDIRECTORY M
         where A.MODEL_CODE = M.CODE) BS
 where BS.STOCK_CODE = I.CODE
То есть есть базовая таблица INVNUMBERS (инвентарные номера) и несколько частных таблиц (оборудование, автоматические линии...). «Первичный ключ» для этой вьюшки (не знаю как это по другому обозвать) - INVNUMBERS.CODE.
Теперь далее. Ремонтируются не только ОФ но и другие объекты (далее - неосновные фонды, НОФ). (ЗЫ: в прошлых ревизиях структуры у меня было много таблиц для НОФ - просто НОФ, узлы ОФ, и др., но прочитав форум объедил всё в одну таблицу, т.к. 80-90% полей - одинаковые).
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
-- Create table
create table REPAIR_EXTRA_STOCK
(
  CODE          NUMBER not null,
  NAME          VARCHAR2( 200 ) not null,
  MODEL         VARCHAR2( 50 ),
  ...
)
-- Create/Recreate primary, unique and foreign key constraints 
alter table REPAIR_EXTRA_STOCK
  add constraint PK_REPAIR_EXTRA_STOCK primary key (CODE)
  using index 
alter table REPAIR_EXTRA_STOCK
  add constraint FK_REPAIR_EXTRA_STOCK_BASIC foreign key (PARENT_CODE)  -- НОФ могут наследоваться от ОФ (практически - быть узлами ОФ, например состав автоматической линии)
  references INVNUMBERS (CODE) on delete cascade;
...
И вьюшка:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
create or replace view repair_extra_stock_view as
select  2  as STOCK_TYPE,
       ES.CODE as STOCK_CODE,
       ES.NAME,
       ES.MODEL,
       DECODE(ES.PARENT_CODE, null, ES.STOCK_NO, BS.STOCK_NO) as STOCK_NO,
       ...
  from REPAIR_EXTRA_STOCK      ES,
       REPAIR_BASIC_STOCK_VIEW BS
 where ES.PARENT_CODE = BS.STOCK_CODE(+)
Таким образом, имеется две сущности - ОФ (PK - INVNUMBERS.CODE) и НОФ (PK - REPAIR_EXTRA_STOCK.CODE). Эти сущности записывают в журнал ремонта, записывают ещё куда-то.
И вот основной вопрос: делать в каждой таблице два поля BASIC_STOCK_CODE и EXTRA_STOCK_CODE и связывать внешними ключами с INVNUMBERS и REPAIR_EXTRA_STOCK.
create or replace view repair_inventory_view as -- Вьюшка журнала ремонтов
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
select RI.*,
       ...
  from (
select RI.CODE,
       BS.STOCK_TYPE,
       BS.STOCK_CODE,
       BS.NAME,
       BS.MODEL,
       ...
  from REPAIR_INVENTORY        RI,
       REPAIR_BASIC_STOCK_VIEW BS
 where RI.BASIC_STOCK_CODE = BS.STOCK_CODE
union all
select RI.CODE,
       ES.STOCK_TYPE,
       ES.STOCK_CODE,
       ES.NAME,
       ES.MODEL,
       ...
  from REPAIR_INVENTORY        RI,
       REPAIR_EXTRA_STOCK_VIEW ES
 where RI.EXTRA_STOCK_CODE = ES.STOCK_CODE
) RI,
       ...
Второй вариант (погеморойнее) создать таблицу:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
-- Create table
create table REPAIR_INDEX
(
  CODE             NUMBER not null,
  BASIC_STOCK_CODE NUMBER,
  EXTRA_STOCK_CODE NUMBER
)
alter table REPAIR_INDEX
  add constraint PK_REPAIR_INDEX primary key (CODE)
  using index 
alter table REPAIR_INDEX
  add constraint PK_REPAIR_INDEX_BASIC foreign key (BASIC_STOCK_CODE)
  references INVNUMBERS (CODE) on delete cascade;
alter table REPAIR_INDEX
  add constraint PK_REPAIR_INDEX_EXTRA foreign key (EXTRA_STOCK_CODE)
  references REPAIR_EXTRA_STOCK (CODE) on delete cascade;
-- Create/Recreate indexes 
create index FK_REPAIR_INDEX_STOCK on REPAIR_INDEX (BASIC_STOCK_CODE, EXTRA_STOCK_CODE)
При необходимости записать сущность в журнал ремонта - записывать сначала в REPAIR_INDEX, а потом - в журнал с REPAIR_INDEX.CODE. При этом будут такие вьюшки:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
create or replace view repair_index_view as
select RI.CODE,
       BS.STOCK_TYPE,
       BS.STOCK_CODE,
       BS.NAME,
       BS.MODEL,
       ...
  from REPAIR_INDEX            RI,
       REPAIR_BASIC_STOCK_VIEW BS
 where RI.BASIC_STOCK_CODE = BS.STOCK_CODE
union all
select RI.CODE,
       ES.STOCK_TYPE,
       ES.STOCK_CODE,
       ES.NAME,
       ES.MODEL,
       ...
  from REPAIR_INDEX            RI,
       REPAIR_EXTRA_STOCK_VIEW ES
 where RI.EXTRA_STOCK_CODE = ES.STOCK_CODE;
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
create or replace view repair_inventory_view as -- Вьюшка журнала ремонтов
select RI.*,
       ...
  from (select RI.*,
               RX.*
          from REPAIR_INVENTORY  RI,
               REPAIR_INDEX_VIEW RX
         where RI.INDEX_CODE = RX.CODE) RI,
       ...
Посоветуйте, какой из вариантов будет предпочтительнее по скорости выборки. Всего в ОФ - около 30 тысяч записей. В НОФ - около 10. Около 50% ОФ и 100% НОФ будут записываться в журнал ремонтов или использоваться в задаче.
Пробовал оба варианта но не было возможности сравнить (но вроде бы - второй побыстрее будет). Посоветуйте что еще можно сделать для повышения производительности.
...
Рейтинг: 0 / 0
Структура БД и совместное использование двух сущностей
    #35558796
Jaffar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Знаете в чем косяк вашей темы?
Я вам скажу - слишком много написано.
Кто будет тратить 30 минут на прочтение всего этого?

Нужен вопрос по существу.

МОгу вам только посоветовать проверить скорость выполнения запроса самому так:

declare @T datetime
select @T = getdate()
/*
--- текст запроса
select .......
*/
select getdate() - @T 'время работы запроса'
- это если вы не особо спец в sql.

Если знаете - можно посмотреть план выполнения запроса, навешать индексов в узких местах.
...
Рейтинг: 0 / 0
2 сообщений из 2, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Структура БД и совместное использование двух сущностей
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]