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

вообще, при проектировании бд стандартных ситуаций не бывает.
но то, о чем говоришь ты, видимо, как раз стандартно решается, называется "отношение многие ко многим".


Пример стандартной ситуации.

Таблица 1.
Книжки

Таблица2
Авторы

Таблица3
Языки



Уверен что в практике бд-строительства не один десяток раз возникала необходимость связывания подобных таблиц, при условии что у одной "книжки" а) может быть как один автор, так и два и три; б) она может быть двуязычной и даже трехязычной.
Массивы - не канонично, но просто.

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

Наследование (таблицы: книжки с одним автором и одним языком; с одним автором и двумя языками; с двумя авторами и одним языком - и т.д. всем скопом дочки исходной таблицы - книжки) - не канонично и сложно.


главное - оно тут вообще ни при как.


Создание отношений книжка-язык (ПК книжка-язык) и книжка-автор (ПК книжка-автор) - вроде просто и канонично, но ведет к разрастанию бд (в плане количества таблиц с двумя столбцами - куча их)

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

Dimitry Sibiryakovabraham88Задался следующим вопросом - существуют ли какие-либо выработанные временем и практикой,
утвержденные, общепринятые, и главное - доступные для копирования - стандартные решения
стандартных ситуаций, возникающих в процессе проектирования БД?

Да. Погугли нормальные формы и "сущность-связь" (entity-relation).


"сущность-связь" (entity-relation). тут тоже ни при чем . искать надо отношение многие ко многим.

abraham88ChA,

Ссылка интересная, большое спасибо. Зачатки, значит, есть =)


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

в проектировании бд нет общих мест, потому что все исходит из постановки задачи. даже трактовка нарушения 1нф может диктоваться постановкой задачи.

хорошие примеры это атрибуты "телефон" и "адрес", в одних поставленных задачах они будут атомарными атрибутами, в других - составными, те будут являлся самостоятельным сущностями.

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