Форум: "Базы";
Текущий архив: 2006.11.26;
Скачать: [xml.tar.bz2];
ВнизИзбыточность Найти похожие ветки
← →
_Ламер_ (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 обязателен в данном контексте?
← →
PEAKTOP © (2006-09-25 11:19) [8]> Имеется ввиду TOVARY?
Да, извини, очепятка получилась.
>ON UPDATE CASCADE обязателен в данном контексте?
Это каждый решает сам в зависимости от задачи.
Например,я это делаю на случай если взбрендиться в справочнике поменять код (ID) элемента, то чтобы автоматом "перебились" все накладные. А на ON DELETE CASCADE, заметь, не вешаю, а то грохнут из справочника элемент и накладные весело года так за 2 "перебъются", а так - VIOLATION FOREIGN KEY все получат.
← →
_Ламер_ (2006-09-25 18:49) [9]
> в справочнике поменять код (ID) элемента,
Он же обычно автоинкрементный?
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2006.11.26;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.04 c