MySQL вопрос по организации таблиц (теория)

[Boron]

Всем доброго времени суток!

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

В общем представим, что я захотел сделать БД на книжки. Книжки могут быть как текстовые, так и аудиокнижки. Причём у меня может встречаться книжка в обоих форматах.

Сразу дам пояснения полям:

format - 1 = text, 2 = audio

audio_bitrate = необязательное поле, указывается в случаях, если format = 2

reader = имя чтеца, если format = 2

В теории я могу сделать несколько вариантов оформления таблиц:

Вариант 1 (сделать большую таблицу, в которую будут входить следующие поля):

table_books

id|title|author|genre|format|audio_bitrate|reader

Вариант 2 (сделать несколько таблиц, и связать их между собой):

table_formats

id|format

table_books

id|title|author|genre

table_reader

id|reader

Внимание:

Таблица придумана на ходу, на самом деле, в БД будет НАМНОГО больше полей.

Вопрос:

Как будет сделать правильнее: создать несколько таблиц с маленьким количеством полей, или одну, но с большим количеством полей?

[D.S.Denton]

я бы вначале сделал отдельно таблицы на текст и аудио. в текстовых ввел поле "audioID", которое если не null указывает на айди соответствующей (или нескольких через разделитель) аудиокнижки

автор и чтец - опять же отдельные таблицы, для простоты и скорости выборки из базы

т.е.

authors: aID, surname, name, parent, nickname, email, other, birthdate, city, regdate, rating

readers: rID, surname, name, parent, rating

tbooks: tbID, aID, name, genre, madedate, adddate, rating

abooks: abID, tbID, rID, madedate, producer, adddate, rating

[D.S.Denton]

поясню логику связей.

есть автор. он может быть сам по себе, аналогично чтец. атрибуты у автора ФИО и прочее, у чтеца аналогично, но как правило людей не интересует ничего, кроме имени и фамилии, поэтому атрибутов у него меньше, значит как отдельного автора его неудобно держать (в т.ч. и потому что тогда у аудиокнижки он будет привязан не как чтец, а как соавтор)

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

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

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

также нетрудно найти все книги одного автора (в т.ч. с возможностью включить в поиск аудио или нет или только аудио) select from 'tbooks' * where 'aID'... аналогично аудиокнижки по исполнителю или названию издательства

[Boron]

D.S.Denton, спасибо тебе огромное, что не поленился так подробно расписать идею оформления БД и даже с примерами. В ближайшие дни, как появиться свободное время, попробую подумать о "правильной" организации своей БД по твоему примеру и по твоим комментариям. Идея сама мне понятна, но смогу ли всё так "грамотно" реализовать... Тут уже вопрос интересный. Помоему всё не так сложно, но... Пока не попробуешь, не стоит зарекаться.

В любом случае спасибо за ответ! Если честно, не ожидал, что так подробно кто-то ответит.

[mirrustam]

D.S.Denton, спасибо тебе огромное, что не поленился так подробно расписать идею оформления БД и даже с примерами. В ближайшие дни, как появиться свободное время, попробую подумать о "правильной" организации своей БД по твоему примеру и по твоим комментариям. Идея сама мне понятна, но смогу ли всё так "грамотно" реализовать... Тут уже вопрос интересный. Помоему всё не так сложно, но... Пока не попробуешь, не стоит зарекаться.

В любом случае спасибо за ответ! Если честно, не ожидал, что так подробно кто-то ответит.

Давайте я тоже попробую .

1. Сначала подумайте и определите какие вопросы (запросы) будут к базе данных и сделайте список. Например так:

Найди все книги этого автора

Найди все книги именно этого автора

И т.д.

Тогда вам самому будет понятнее как всё построить

На счёт в одну таблицу аудиокниги и просто книги – лучше сделать в одной таблице и разделять их по полю «тип книги»- так как и то то книги.

Кроме того, есть ещё одни вариант: можно использовать поле формат как признак наличия форматов например:

1- есть книга в обычном формате

2- есть книга в обоих форматах

3- есть книга только в аудиоформате

т.е. вне зависимости от того есть у вас аудиокнига, просто книга или оба варианта всё равно будет только одна строка на одну книгу.

Советую поискать в Интернете и понять – что такое «нормальные формы таблиц» -их всего пять – но если вы все свои данные приведёте хотя бы к третьей, то база сама по себе будет правильная.

[newенький]

Разрешите мне тоже задать вопрос. Он у меня на ту же тему.

Итак, существуют организации: развлекательный комплекс, фитнес центр, кафе-бар...

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

Эти организации необходимо сгруппировать по разделам: кафе, спорт, доставка....

НО эти организации многофункциональны, т.е. в фитнес клубе есть кафе, в развлекательном комплексе есть кафе, доставка суши, а в кафе есть кафе)))) и доставка пиццы.

Кроме того необходимо составить страницы сайта для каждого раздела с указанием всех входящих в него организаций, статьей (контент) и метаданными (title, description,keywords)

Короче все вышеописанное нужно рассовать по таблицам в БД и так чтобы было просто находить и доставать.

Мои варианты (их 2):

Вариант 1: 5 таблиц:

1. Таблица "Раздел": id_part и name

2. Таблица "Организации": id_org, time, phone, cite, adress

3. Таблица "Мета": id_meta, title, meta_key, meta_deskr

4. Таблица "Контент": id_cont, text, url, img, type, pos

5. Таблица связи: id_part, id_org, id_meta, id_cont

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

Вариант 2:

......................................................... ........................1. Таблица "Раздел": id_part и name

............................................. .................. ................... ......................... .........Таблица связи: id_part, id_org

1.1. Таблица "Мета": id_meta, title, meta_key, meta_deskr, id_part................ ......1.2. Таблица "Организации": id_org, time, phone, cite, adress

1.1.1. Таблица "Контент": id_cont, text, url, img, type, pos, id_part(id_meta).... .....1.2.1. Таблица "Мета": id_meta, title, meta_key, meta_deskr, id_org

....................... .................. ...................... ..................................... ......... ......1.2.2. Таблица "Контент": id_cont, text, url, img, type, pos, id_org

Второй вариант содержит больше таблиц, но зато проще осуществлять запросы, особенно если дело касается контента.

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

[mirrustam]

1. таблицы мета и контент – можно объединить в одну.

2. зачем вообще нужна таблица «контент»?

Если под «статьями» имеется ввиду описания разделов

Вот так будет правильно:

—section--

Id

Name

Description

meta_desc

meta_keys

meta_titles

--Org --

id

name

description

meta_desc

meta_keys

meta_titles

--section org --

id_section

id_org

description

meta_desc

meta_keys

meta_titles

поля description и мета… есть в каждой таблице . т.е есть описание для разделов, общее описание каждой организаии , а так же описание каждой функции для каждой организации.

Not null

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

Если так, то добавляется ещё одна таблица:

--content—

id

id_section

id_org (это поле может быть пустым)

text

meta_desc

meta_keys

meta_titles

Edited July 31, 2009 by mirrustam

[newенький]

Спасибо, я так понимаю вы описали мой "Вариант 2" своими словами, при этом добавили в таблицы Org и section(part) таблицы meta и content. Таблица контент необходима затем, чтобы пользователь мог добавлять не только текст на страницу но и заголовки, ссылки, картинки. В вашем случае ему придется писать html теги, чтобы добавить ссылку например или самостоятельно добавлять картинку и указывать src.

Я сам склоняюсь к варианту №2, но все-таки думал, что есть третье более оптимально решения без повторения одних и тех же полей в разных таблицах

[mirrustam]

Спасибо, я так понимаю вы описали мой "Вариант 2" своими словами, при этом добавили в таблицы Org и section(part) таблицы meta и content. Таблица контент необходима затем, чтобы пользователь мог добавлять не только текст на страницу но и заголовки, ссылки, картинки. В вашем случае ему придется писать html теги, чтобы добавить ссылку например или самостоятельно добавлять картинку и указывать src.

Я сам склоняюсь к варианту №2, но все-таки думал, что есть третье более оптимально решения без повторения одних и тех же полей в разных таблицах

на ваш второй вариант , по моему совсем не похоже

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

на счёт, того, что надо писать теги - нет не надо - просто к текстовому полю прикрепите html редактор, он вам сам всё переведёт в хтмл

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

1 .облегчения дальнейшей разработки.

2. достижения оптимальных скоростей работы(меньше соединений при формировании запросов)

да и по логике видно, что надо вам именно так

[newенький]

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

[mirrustam]

таких много

Я использую КМС Joomla, в ней есть неплохой встроенный редактор в виде модуля . Думаю, отдельно именно его тоже можно найти. Можно и другие.

вот так он называется WYSIWYG - редактор tinyMCE

Edited July 31, 2009 by mirrustam