powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Правильное vs Хорошее проектирование
2 сообщений из 2, страница 1 из 1
Правильное vs Хорошее проектирование
    #35620477
Skulll
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всем Респект Коллеги!!!

Есть таблица каналы channel. Она ссылкается на два справочника, в каждом из которых по две записи. И на таблицу parent которая находится на более высокой иерархии. Один ко многим.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
create table channel (
ID                   NUMBER  primary key,
dim1_id           number references dim1 (ID),
dim2_id           number references dim2 (ID),
parent_id      number references parent (ID)
)
/
create table dim1 (
id number pk,
name varchar2( 4000 )
)
/
create table dim2 (
id number pk,
name varchar2( 4000 )
)
/
insetr into dim1 (id, name) values ( 1 ,'Активная')
/
insetr into dim1 (id, name) values ( 2 ,'Реактивная')
/
insetr into dim2 (id, name) values ( 1 ,'Прямая')
/
insetr into dim2 (id, name) values ( 2 ,'обратная)
/

есть таблицы фактов fact которая ссылкается на channel.
Код: plaintext
1.
2.
3.
4.
create table fact (
ID                   NUMBER  primary key,
ID_channel           number references channel (ID),
)

Данные в эту таблицу приходят в виде xml Файла. В файле содержится поле code которые имеет только четыре значение 01, 02, 03, 04. Бизнес логика в том что 01 это Активная Прямая т.е. dim1.id = 1 и dim2.id = 1. 02 = Активная обратная dim1.id = 1 и dim2.id = 2 и так далее.

Спор с колелгами произошол из-за того добавлять ли в таблицу channel поле code!!!

Попытаюсь описать плюсы и минусы реализации с полем code:
- Де нормализация, поле code и форен кеи справочников должны быть в соответствовии
+ Большая легкость поиска по этому полю

Есть плюсы и минусы которые коллеги мне пытались обяснить, но я сомневаюсь в их однозначности, в том что они действительно плюсы и минусы:
- Хард код при загрузки/мэппинге xml файла в таблицу.
Но так или иначе будет, просто на дургом уровне. Например при вставке в таблицу parent для нее будет создаваться четыре записи в channel.
+ Нет привязки данных к Праймари кею
Вот это самой не понятный для меня аргумент. Что возможно или бизнес логика изменится (а это нельзя исключать) и добавится на новый code со значением разным 05.
И тогда придется переделывать бизнес логику мэпинга.

Но я чую в этом есть тоже подвох. Коллеги прошу рассудить кто прав кто виноват? Какие минусы плюсы я упустил? Приведите хорошие примеры этого так называемого плохово стиля привязывания данных к PK.
...
Рейтинг: 0 / 0
Правильное vs Хорошее проектирование
    #35620662
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Помоему, вам просто надо создать вместо двух - один справочник, в который ввести поле "Код" (1,2,3,4) и признаки "Активный" / "Реактивный", "Прямой" / "Обратный" и все ваши плюсы и минусы исчезнут и все будут довольны.
...
Рейтинг: 0 / 0
2 сообщений из 2, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Правильное vs Хорошее проектирование
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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