Избыточность

← →
_Ламер_ (2006-09-23 01:38) [0]

Чем плох сабж?
К примеру, есть такое дерево

Table1 -> group -> Table2 -> group -> Table3

Фактически, мне нужна информация только из таблиц, группы мне не о чём говорят, кроме как о группировке элементов. Соответственно, у меня есть таблица Tree (ID, parent_ID). Но так как мне надо найти обратный путь + не всегда есть необходимость отображать группировку (group) + для обеспечения целостности, я завёл таблицу соответствия Table3 (Table1_ID, Table2_ID). Получается, что одна и таже информация о связях между элементами у меня хранится сразу в двух таблицах. Кроме, как объёма БД, на что это может повлиять?

← →
Sergey Masloff (2006-09-23 01:59) [1]

А к примеру в одну таблицу это никак не запихнуть?
Потому что хрен знает какая может быть целостность если она не в одном месте

← →
DrPass © (2006-09-23 02:46) [2]

> Кроме, как объёма БД, на что это может повлиять?

В некоторых случаях могут возникнуть трудности с обновлением данных - надо будет менять в нескольких местах... само собой, добавляется лишнее правило для поддержания целостности и т.д. А вообще, речь о том, что "избыточность - это плохо" не идет. Это, скажем так, не недостаток, а особенность проектирования БД. В некоторых случаях она вредит, в некоторых может быть полезной. Например, может упростить некоторые ресурсоемкие запросы. Поэтому при проектировании БД нужно трезво обдумать, где и до какой степени ее нормализовать, и не ставить самоцель "сделать все максимально нормализованным"

← →
PEAKTOP © (2006-09-23 11:17) [3]

Избыточность не всегда является плохой ситуацией.
При проектировке СУБД необходимо просто выбирать баланс между избыточностью и производительностью.
Тривиальный тому пример
Справочник TOVAR (ID INTEGER, NAME VARCHAR(50)) и детальная часть расходной накладной (DOC_ID INTEGER, TOVAR_ID INTEGER, QUANT NUMERIC(15,3)). Ключ введенный в справочник TOVAR(ID) является избыточным, т.к. в принципе достаточно поля NAME, чтобы идентифицировать товар. Только вот производительность индекса по полю VARCHAR будет куда ниже, чем по полю INTEGER, да и в добавок, если мы построим внешний ключ в детальной части накладной по полю TOVAR(NAME), то размер файла базы данных у нас будет расти очень быстро, и на нормальной оптовой базе достичь 1-2 ГБ за месяц вполне реально.

← →
_Ламер_ (2006-09-23 17:13) [4]

> Sergey Masloff (23.09.06 01:59) [1]
> А к примеру в одну таблицу это никак не запихнуть?

Неа. Table1...Table3 это ссылки на разные таблицы (разные поля). Как это запихнуть в одну таблицу - не знаю. Только group не куда не ссылается - всего лишь признак группировки.

> Потому что хрен знает какая может быть целостность если
> она не в одном месте

Целостность обеспечивается таблицей Table3 (Table1_ID, Table2_ID).

> Ключ введенный в справочник TOVAR(ID) является избыточным

А можно по-подробней? На что тогда будет ссылаться Tovar_ID из расходной накладной?

← →
PEAKTOP © (2006-09-23 18:18) [5]

В приведенном примере есть два способа организации структуры базы данных
1) С избыточными полями для построения по ним ключей
CREATE TABLE TOVARY( ID INTEGER NOT NULL PRIMARY KEY, --ИЗБЫТОЧНОЕ ПОЛЕ ДЛЯ КЛЮЧА NAME VARCHAR(50) ); CREATE TABLE DOC_DETAIL( TOVAR_ID INTEGER NOT NULL FOREIGN KEY TOVAR(ID) ON UPDATE CASCADE, QUANT NUMERIC(15,3) )

2) Без избыточных полей
CREATE TABLE TOVARY( NAME VARCHAR(50) NOT NULL PRIMARY KEY ); CREATE TABLE DOC_DETAIL( TOVAR_NAME VARCHAR(50) NOT NULL FOREIGN KEY TOVAR(NAME) ON UPDATE CASCADE, QUANT NUMERIC(15,3) )

Как видно из примера, в первом случае база данных не полностью нормализована, поле ID в таблице TOVAR является избыточным, т.к. для характеристики объекта ТОВАР вполне достаточно поля NAME. Однако по производительности является более приемлимым, т.к.
1) Прирост базы данных будет гораздо меньше с каждым добавлением позиции в накладную.
2) Меньший размер файла баз данных требует меньшего кол-ва операций чтения для того, чтобы например построить статистику реализации скажем за 2-3 года.
2) Индекс по полю Integer гораздо производительнее, чем по полю VARCHAR(50).

← →
Petr V.Abramov (2006-09-23 21:57) [6]

нормализированность имеет место быть в пределах таблицы, а уж какие у нее атрибуты - согласно теории нормализации определяется "свыше".
но смысл в Ваших словах есть, хоть они и не всегда "туда" ссылаются

← →
_Ламер_ (2006-09-23 22:44) [7]

> FOREIGN KEY TOVAR(ID) ON UPDATE CASCADE,

Имеется ввиду TOVARY? ON UPDATE CASCADE обязателен в данном контексте?

> Имеется ввиду TOVARY?
Да, извини, очепятка получилась.
>ON UPDATE CASCADE обязателен в данном контексте?
Это каждый решает сам в зависимости от задачи.
Например,я это делаю на случай если взбрендиться в справочнике поменять код (ID) элемента, то чтобы автоматом "перебились" все накладные. А на ON DELETE CASCADE, заметь, не вешаю, а то грохнут из справочника элемент и накладные весело года так за 2 "перебъются", а так - VIOLATION FOREIGN KEY все получат.

← →
_Ламер_ (2006-09-25 18:49) [9]

> в справочнике поменять код (ID) элемента,

Он же обычно автоинкрементный?

Избыточность Найти похожие ветки