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

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

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

Вопрос по проектированию БД [D6, IB6.x]

Страницы: 1 2 >
Jaxtor © (2003-05-06 14:00:00)
Собственно вопрос по проектированию БД. Я создал таблицу с характеристиками товара и для каждой характеристики свою таблицу. Если товар имеет характеристики типа ИЛИ-ИЛИ-ИЛИ... проблем нет. А если И-И-И... возникают проблемы. В первом случае ИЛИ-ИЛИ-ИЛИ... устанавливается реляционная связь между главной и подчиненной таблицами. А во втором реляционная связь не получается. Для связи И-И-И... я собираюсь использовать компоненты типа TDBCheckBox, а для ИЛИ-ИЛИ-ИЛИ... - TDbLookUpComboBox. Как быть?

NickBat (2003-05-06 18:51:00) [1]
Я не против нормализации! Я против бездумного ее применения. :)
Зачем городить огород из-за лишней строчки в справочнике?
А из вопросов автора ветки мне кажется дело обстоит именно так.

Соловьев (2003-05-06 18:13:00) [2]

> Есть справочник характеристик, характеристика ни с того
> ни с сего меняться не может, как и справочник

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

NickBat (2003-05-06 18:09:00) [3]
Есть справочник характеристик, характеристика ни с того ни с сего меняться не может, как и справочник.

Соловьев (2003-05-06 17:56:00) [4]

> NickBat © (06.05.03 17:50)

если надо будет перевести с 100 на 101, например, то прийдется много чего делать...

NickBat (2003-05-06 17:50:00) [5]
Если отталкиваться от характеристик, например хабов,
я бы сделал в справочнике характеристик три строки:

ID NAME
1 10
2 10/100
3 10/100/1000

Это проще и гораздо наглядней чем действовать в угоду нормализации.
Можете меня поругать. :))

vuk (2003-05-06 16:10:00) [6]
>Теперь понятно.
Ну дык. :o) Хотя, по большому счету суррогатный ключик там не помешает. Для обеспечения нормального редактирования каждой записи. То есть:

TechPar(Характеристики)
-----------------------
row_id int (PK)
g_id int (FK Goods.g_id)
tp_id int (FK TechParNames.tp_id)
tp_Value varchar

MsGuns (2003-05-06 15:59:00) [7]
>vuk © (06.05.03 15:40)
>Можно для одного товара иметь сколько угодно характеристик одного типа

Неужели ? Т.е. один товар может иметь ДВЕ ОДНОТИПНЫЕ характеристики, например, форма корпуса ? TechPar этого явно не "вытянет".

Аааааааа..... Табла-то без ключа ! Теперь понятно.

MsGuns (2003-05-06 15:54:00) [8]
>MOA © (06.05.03 15:39)
>Мой пример - просто иллюстрация таблиц связей как средства "разруливания" ситуации.

Согласен. Реплика MsGuns © (06.05.03 15:28)
, действительно, не по адресу.

vuk (2003-05-06 15:40:00) [9]
А как такой вариант:

Goods(Товары)
------------
g_id int (PK)
g_Name varchar

TechParNames(Наименования характеристик)
----------------------------------------
tp_id int (PK)
tp_Name varchar

TechPar(Характеристики)
-----------------------
g_id int (FK Goods.g_id)
tp_id int (FK TechParNames.tp_id)
tp_Value varchar

Можно для одного товара иметь сколько угодно характеристик одного типа. Заодно появляется возможность сравнивать разные товары по характеристикам.

MOA (2003-05-06 15:39:00) [10]
>И сколько же подобных справочников придется создать
В предельном случае - ровно один + триггер для бизнес - ограничений. Человек же сказал, что справочники у него уже готовы. Мой пример - просто иллюстрация таблиц связей как средства "разруливания" ситуации.
Удачи!

MsGuns (2003-05-06 15:28:00) [11]
>MOA © (06.05.03 15:04)

И сколько же подобных справочников придется создать, чтобы описать всевозможные характеристики - 10, 100, 1000 ? А если завтра поступят комплектующие с принципиально новой характеристикой - добавлять новую таблицу ?

ИМХО, нормализация ради нормализации.

Jaxtor (2003-05-06 15:19:00) [12]
>MOA Спасибо, но пока что трудновато мне в это вникнуть...

Соловьев (2003-05-06 15:17:00) [13]

> id-это PK, а у тебя он имеет 2 значения-"1".

нет не PK. Я же сказал - это таблица связи... И кто тебе сказал,что id - это число обязателько? его можно генерить из имени устройства+код:
hub100
hub101
lan156
...

Jaxtor (2003-05-06 15:13:00) [14]
Соловьев> id-это PK, а у тебя он имеет 2 значения-"1".

Соловьев (2003-05-06 15:11:00) [15]

> dsc - что это?

description - характеристика

Jaxtor (2003-05-06 15:10:00) [16]
Ладно буду думать... Через некоторое время дельта t сообщу, что
придумал.

Jaxtor (2003-05-06 15:07:00) [17]
id id_dsc 1 1 1 2
Да, вроде начинаю понимать...
>id_dsc
dsc - что это?

Соловьев (2003-05-06 15:04:00) [18]
что-то не догоню...
что 5? 5 раз в таблице связи повторится id? ну и что?

MOA (2003-05-06 15:04:00) [19]
1. Есть таблица
Tovar: ID_Tovar, Name_Tovar PK(ID_Tovar)
1 Хаб 1
2 Хаб 2
2. Есть справочники
Sprav1: ID_Prop, NameProp PK(ID_Prop)
1 Скорость 10
2 Скорость 100

Sprav2: ID_Prop, NameProp PK(ID_Prop)
1 Питание внешнее
2 Питание внутреннее
Sprav3: ID_Prop, NameProp PK(ID_Prop)
1 Вес
3. Есть таблицы связей
Link1: ID_Tovar, ID_Prop PK(ID_Tovar, ID_Prop), FK(ID_Tovar), FK(Prop)
1 1
1 2
2 2

Link2: ID_Tovar, ID_Prop PK(ID_Tovar, ID_Prop), FK(ID_Tovar), FK(Prop), UNIQUE INDEX CONSTRAINT ID_Tovar
1 1
2 1

Link3: ID_Tovar, ID_Prop, Kolvo PK(ID_Tovar, ID_Prop), FK(ID_Tovar), FK(Prop), UNIQUE INDEX CONSTRAINT ID_Tovar
1 1 10
2 1 0.5

Всё ограничения обеспечиваются. Конечно, возможны вариации (ну, напрмер, хранить все св-ва в одном или немногих справочниках). Важно тут именно наличе таблиц связи и для "исключительно или" - наличие уникального ограничения на ID_Tovar. Выгода архитектуры - Вам будет достаточно легко добавить свойство. Конечно, неотьемлимые атрибуты лучше хранить прямо в справочнике товара.
Удачи!

MsGuns (2003-05-06 15:03:00) [20]
Слушай, а может ты просто перемудрил ? Почему бы не решить твое "многообразие" характеристик просто группировкой ? Но группы сделать в виде дерева. Т.е.
Ур.1 Сетевое оборудование
Ур.2 Хабы
Ур.3 Хабы UTP,100
Хабы UTP,10
Хабы BNC,10
Хабы BNC+UTP,10
Концентраторы
...

Хотя, конечно, если надо выбрать все с UTP или с 10.. 8(
Но, в конце концов наиболее типичные характеристики можно вывести в отдельную сущность.
Кстати, для хабов и им подобных кол-во портов, например, я бы вообще не выносил, а влепил бы в довесок к наименованию

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

Наверх

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