On 12/08/2011 04:48 PM, isapper wrote:

> сомнение насчёт 1нф не было. Но сейчас появилась необходимость поднять более

На самом деле вопрос действительно очень сложный.

> серьёзную БД, где привод к 1нф количество полей возведётся в 3-4 степень.

Кол-во полей в таблице не является объектом оптимизации при проектировании
структуры БД. Ты можешь иметь в таблице столько полей, сколько тебе нужно.
Единственное ограничение -- это физический размер записи, как правило, он
в СУБД ограничен каким-то верхним порогом. Т.е. кол-во полей должно быть
разумно небольшим. Как правило, при грамотном проектировании БД кол-во
полей невелико, 10-20.

Увеличение кол-ва полей на 3-4 порядка -- это конечно же уже криминал,
надо смотреть на детали проблемы, скорее всего, опять таки что-то не
хорошо с дизайном БД.


> Хотелось бы почитать мнения к нескольким примерам:
>
> /Вики: Хорошим способом принятия решения о необходимости разбиения атрибута на
> части является вопрос: «будут ли части атрибута использоваться по отдельности?».
> Если да, то атрибут следует разделить (но так, чтобы сохранились осмысленные
> части атрибута)./

Это правильное замечание, только необходимо одно дополнение:
"на стороне СУБД". Т.е. "будут ли части атрибута использоваться по отдельности
внутри СУБД (на языке SQL)". Если да, то следует разделять.

> 1) На каком уровне имеется в виду "использоваться по отдельности"? К примеру у
> меня есть столбец ФИО, по которому нету выборки, и на экран ФИО всегда будет
> выводится вместе, но есть необходимость разделить на уровне интерфейса, к
> примеру фамилия красная, имя зелёное, отчество синее.

Только если эти части используются по отдельности внутри СУБД, в запросах,
индексах и т.п.

> 2)День рождения сотрудника YYYY.MM.DD. Мне нужны будут только 2 селекта: YYYY,
> что бы знать какого сотрудника направить на курсы, и MM.DD что бы знать кого
> поздравить с ДР, а целиком YYYY.MM.DD никогда не нужны, неужели надо кидать по
> разным столбцам YYYY И MM.DD?

По-нормальному, да. Однако, есть и у этого правила нюансы, оно не абсолютно
жёсткое. Именно поэтому с ним часто и случаются проблемы даже у опытных
разработчиков БД (слышал о таком совсем недавно).

Например, в этом конкретном случае твоя СУБД может поддерживать операции
выделения частей из даты, может поддерживать даже индексацию по таким частям
(индекс по выражению).
Тогда тебе для того, чтобы получить "сотрудников для направления на курсы"
нужно будет написать запрос типа




а для дней рождения




или же для первого случая написать запрос типа




где ?year_begin? и ?year_end? -- даты начала и конца года тех, которым
пора на курсы, вычисленные заранее.

Отдельный очень тонкий момент -- это производительность таких запросов.
Даже если у тебя будет потенциально плохая производительность, вам может
быть на это наплевать, либо в силу того, что таблица маленькая, либо в
силу того, что запрос редко выполняется и люди могут подождать.

> 3)Ещё пример: есть две таблицы: первая - справочник с продуктами и цены на них,

Цена на продукт в таблице продукта -- уже криминал. (правда, это не нарушение
1НФ, а 3-ей). Цена как правило зависит от времени, она меняется, продукты --
нет.

> вторая- таблица рецептов состоящая из кол-во определённых продуктов из
> справочника. Результат - цена блюда. На сколько понимаю, каждый компонент
> рецепта теоретически должен находится на отдельном ряду,

Это я не понял, что за ряды такие.

Вообще-то три таблицы должно быть.
Блюдо, его состав (1:M от блюда, со ссылкой на продукт),
продукт. Ну и цена продукта по датам (на самом деле это всё же стоимость
продукта, а не цена), это - четвёртая таблица.

но ведь рецепт един, и
> по частям не используется. А если каждый рецепт содержит от нескольких до сотен
> компонентов, рецептов - миллионы, рецепты поделены по тысячам тегов, то таблица
> будет огромная, и тормозная.

Наплевать, это всё равно копейки для современных реляционных СУБД.
Даже если состав блюда будет несколько миллионов, ничего страшного.


На сколько правильно в такой ситуации, в одну
> ячейку сувать несколько внешних ключей и рулить этим с помощью триггера?

Это настолько безобразно, что я даже слов не подберу. Все неприличные.
Это абсолютно неправильно и безграмотно.
Posted via ActualForum NNTP Server 1.5

On 12/08/2011 05:13 PM, LSV wrote:
> 1. делать разборку XML ?

Я бы не стал совать XML во все дыры, где оно не нужно.

Posted via ActualForum NNTP Server 1.5

On 12/08/2011 07:19 PM, isapper wrote:

> А процедуры являются внешней или внутренний частью сервера?

Хранимые процедуры -- внутренней.


А после того как я почитал про тип array в
> Postgres я подумал о том, что с помощью него можно объединить некоторые внешние
> ключи в один столбец.

Подумал неправильно.

Это я думаю сделать именно для ускорение инсёртов и
> апдейтов, так как из-за многомерности будет много индексов, что в свою очередь
> будет тормозить инсёрты.

Не парься про это. Просто вставляй.

> Не зря я интересовался первыми двумя примерами, исходя из них мне ничего не
> мешает сделать две БД одна для справочника, одна для рецептов, внешние ссылки
> хранить в одной ячейки, а объединение делать при помощи внешних скриптов, того
> же PHP. И это теоретически, не будет нарушать 1НФ, но правда будет ли подобное
> объединение удовлетворять 2нф непонятно. И если так можно, то можно и вместо
> внешнего PHP использовать внутренний скрипт, тот же PHP(pl/php).

Это всё ты ересь какую-то несёшь.

> И всё-таки где могут быть полезны массивы?

На клиенте. Вне реляционной СУБД.
Внутри СУБД для _Х_Р_А_Н_Е_Н_И_Я_ каких-то массивов данных, например,
научных типа значений функции какой-то в N точках.

Posted via ActualForum NNTP Server 1.5