Как лучше?

← →
ProgRAMmer Dimonych © (2008-05-25 17:54) [0]

Имеется сайт, который генерирует документы по шаблонам. У каждого документа два "параметра": тип документа (отличается содержимым) и стиль оформления (отличается соответственно стилем). Со временем список поддерживаемых типов и стилей документов может расширяться или, наоборот, сокращаться (т.е. некоторые типы//стили могут становиться ненужными).

Всё это можно представить в виде двумерной таблицы (тип и стиль по строке и столбцу), где в каждой ячейке записан шаблон документа. Другими словами, для всех типов документов могут создаваться стили оформления, применяемые ко всем документам с этим стилем (независимо от типа). Задача заключается в том, чтобы запихнуть такую таблицу в БД. В теме не силён, но есть два варианта, ни один из которых не привлекает :(

1. Создать таблицу, в которой полям будут соответствовать, скажем, типы документов, а каждая запись - стилю, или наоборот. IMHO-минус: при добавлении новой возможности (типа или стиля) придётся менять структуру таблицы (добавлять//удалять поля).

2. Использовать таблицу, в которой записи будут уникальны по двум параметрам (не знаю, как это в терминологии). Т.е. берём, скажем, идентификатор типа и идентификатор стиля, объединяем их и по этой объединённой паре значений будем однозначно определять интересующую нас запись в таблице. IMHO-минус: некрасиво будет происходить удаление типов или стилей.

Какой подход лучше всего выбрать в этом случае?

← →
Kerk © (2008-05-25 18:48) [1]

А почему б не сделать так, как еще наши деды делали?

Две таблицыс полями:
ID_Стиля, Имя_Стиля ID_Типа, Имя_Типа

И третья:
ID_Стиля, ID_Типа, Шаблон

← →
Zeqfreed © (2008-05-25 21:56) [2]

Ничего не понятно. Для чего хранить эту информацию в базе и как она будет использоваться? Не понятно какие связи интересуют.

← →
Real © (2008-05-25 22:01) [3]

> почему б не сделать так, как еще наши деды делали?

Наверное потому что:

> В теме не силён

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

← →
ProgRAMmer Dimonych © (2008-05-25 23:30) [4]

> Kerk © (25.05.08 18:48) [1]
> А почему б не сделать так, как еще наши деды делали?
>
> Две таблицыс полями:
> ID_Стиля, Имя_Стиля
> ID_Типа, Имя_Типа
>
> И третья:
> ID_Стиля, ID_Типа, Шаблон

Т.е. вариант 2?

> Zeqfreed © (25.05.08 21:56) [2]
> Ничего не понятно. Для чего хранить эту информацию в базе
> и как она будет использоваться? Не понятно какие связи интересуют.

Информация - шаблоны документов. Использоваться будут для того, чтобы, собственно, генерировать эти документы на лету. В БД - это условие такое.

> Real © (25.05.08 22:01) [3]
> Автор, прочитай про нормализацию БД - подобные задачи рассмотрены
> чуть ли не в первой главе любой книги по теории БД. Зачем
> же пытаться изобрести велосипед?

Может быть, что-то не так понял, но гугл слабо помог. Из найденных страниц получается, что нормализация позволяет устранить избыточность таблиц. Например, когда некоторое значение одного поля подразумевает строго определённое значение другого поля. Хотя нет, Вики в руки и по порядку...

1) 1NF - Случай, когда пытаемся в одну и ту же запись впихнуть несколько значений в одно и то же поле. Не наш случай.
2) 2NF - Как раз когда значение одного поля можно определить по значению другого поля. В нашем случае типы и стили оформления документов друг от друга не зависят.

Следующие уровни - чем дальше в лес, тем больше дров.

Возможно, непонятно сформулировал суть. Шаблоны, условно говоря, хранятся в двумерном массиве. Каждый шаблон однозначно определяется только парой "тип+стиль". Задача в том, чтобы запихнуть такую таблицу в рамки БД.

Пока, похоже, нужно склоняться ко второму варианту из [0].

← →
Kerk © (2008-05-25 23:31) [5]

> ProgRAMmer Dimonych © (25.05.08 23:30) [4]
> Каждый шаблон однозначно определяется только парой "тип+стиль".
> Задача в том, чтобы запихнуть такую таблицу в рамки БД.

К варианту №2 надо не склоняться, а уже бежать реализовывать :), первый вариант вообще ниалё.

> Kerk © (25.05.08 23:31) [5]
> > ProgRAMmer Dimonych © (25.05.08 23:30) [4]
> К варианту №2 надо не склоняться, а уже бежать реализовывать
> :), первый вариант вообще ниалё.

Так. И, я так понимаю, лучше всего это реализовать как составной ключ?

Спасибо.

Как лучше? Найти похожие ветки