Помогите определиться со структурой БД

[Анатолий]

Помогите определиться со структурой БД

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

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

Т.к. книги в основной массе будут повторяться, то я разделил свойства книги на "постоянные" - не зависяцие от типа (аудио, электронная,...) и "зависимые" - т.е. те свойства которые будут присутствовать только у определенного типа книг.

Так же одна и таже книга - одного и того же типа, у разных пользователей может иметь различные значения параметров, например,
книга: Мастер и Маргарита
Тип: аудио
У первого пользователя, значение свойства "битрейт" равно 196, у второго, например, 320. Аналогично другие свойства книг.

В итоге получилось 2 структыры БД:

1)
book
bookid int(11)
title varchar(255)
authorid int(11)
description text

userbook
userbookid int(11)
bookid int(11)
userid int(11)
booktype int(1)
xml text

user
userid int(11)
и др. свойства пользователя

И так первый вариант БД

2) Второй вариант БД

book
bookid int(11)
title varchar(255)
authorid int(11)
description text

userbook
userbookid int(11)
bookid int(11)
userid int(11)
booktype int(1)

bookvalue
bookvalueid int(11)
userbookid int(11)
propertyid int(11)
value varchar(255), возможно это будет varchar(50) или даже int(7)

property
propertyid int(11)
booktype int(1)
title varchar(255)
Данную таблицу можно заметь массивом, т.к. параметры меняться не будут, а если и будут то ОЧЕНЬ редко и мною. =)

user
userid int(11)
и др. свойства пользователя

Второй вариант БД:

В общем, спасибо тем кто дочитал до конца!!! =)

Я думаю, пользователей будет не более 5000-6000, а книг неизвестно. =) Ваше мнение, какая из двух реализаций лучше? А может я что-то упустил и есть еще одна реализация простая и надежная, которая будет работать быстрее при больших нагрузках?

Жду ваших комментариев и замечаний. Заранее спасибо всем!

-~{}~ 21.02.07 17:44:

Ребята, неужели не у кого нет мнения??? Второй день висит тема и 0 ответов. =(

 

[asm]

Я бы создал по таблице на каждый тип книги.

-~{}~ 21.02.07 17:44:

твой первый вариант не катит из-за поиска, который скорее всего ты захочешь организовать Как выбрать напримар аудиокниги в формате mp3? Сюда же сортировка и т.п.

 

[Анатолий]

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

А на счет сортировки ты прав. Спасибо!

Так, господа, первый пост есть. Может еще кто?

 

[Dovg]

Может еще кто?

+1
------
По существу:
согласен с asm
Только я бы сделал 4 таблицы: 3 вида и одну общую, с уникальным для каждой книги id.
при этом в трех таблицах (по видам) для разных юзеров создавались бы разные записи
----
в примере с Булгаковым:

Таблица main
id
456 | Мастер и Маргарита | Булгаков | Хорошая сказка

Таблица бумажных книг
id | book_id | user_id | property_one | property_two
1 | 456 | 25 | 456 | Питер
2 | 456 | 35 | 654 | Москва

Ну и соответственно таблица пользователей, можно таблицу жанров и т.д.
---
все ИМХО

 

[asm]

Анатолий
наоборот на мой взгляд намного удобнее.
В чем проблемма в поиске?
Dovg
Это именно то что я имел ввиду.

-~{}~ 21.02.07 20:06:

ВАЖНО!!! По поводу предложенной мной структурой. Она хороша для тех случаев если параметры для разных типов книг статичны и добавление новых параметров планируется с участием программиста!!!

 

[Dovg]

asm
...
Иначе добавляем еще несколько таблиц
1. Таблица свойств
id | name | rusname
2. таблица отношения между типом книги и свойствами
table_id | property_id
3. таблица параметров
table_id | property_id | value
---
только нормализовать надо по-нормальному

 

[asm]

Dovg
Второй вариант описывает другой вариант лучше.

 

[Dovg]

asm
Наверное
---
ИМХО если свойства книг - постоянные, то лучше таблицы
если часто меняются, то вариант-номер-два

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

-~{}~ 21.02.07 21:47:

Я бы еще авторов в отдельную таблицу вынес

 

[Анатолий]

наоборот на мой взгляд намного удобнее.
В чем проблемма в поиске?

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

ИМХО если свойства книг - постоянные, то лучше таблицы
если часто меняются, то вариант-номер-два

Все-таки что будет лучше по скорости
Большая таблица (или 3 таблицы) из первого варианта
или
таблицы по-меньше, но с большим числом объединений в запросе, из второго варианта.
На счет статичности полей - пока не решил. Сейчас над этим думаю - стоит ли давать пользователям возможность добавлять свои поля.

Я бы еще авторов в отдельную таблицу вынес

Авторы и так вынесены в отдельную таблицу, связь идет по полю authorid. Но ИМХО, будет лучше еще продублировать в таблице book - дабы исключить связь таблиц book и author при частых запросах.

 

[asm]

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

обьясните почему?

Автор оригинала: Анатолий
Все-таки что будет лучше по скорости
Большая таблица (или 3 таблицы) из первого варианта
или
таблицы по-меньше, но с большим числом объединений в запросе, из второго варианта.

Проведите тесты. То что скажет Вася Пупкин не всегда правда Будь он даже ДОМОХОЗЯЙКА

 

[Анатолий]

обьясните почему?

Приходится объединять в поисковом запросе по 3 таблиц и искать по ним. На мой взгляд это будет работать медленнее, нежели поиск по одной таблице.

Проведите тесты. То что скажет Вася Пупкин не всегда правда Будь он даже ДОМОХОЗЯЙКА

В том то и дело, что не очень хотелось проводить тесты =)
Время... как всегда все упирается во время. =)

 

[asm]

Анатолий
Вы боитесь обьединений? Обоснуйте свой взгляд по поводу скорости.

 

[Анатолий]

Вы боитесь обьединений? Обоснуйте свой взгляд по поводу скорости.

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

 

[asm]

Замечательно давай все засунем в одну таблицу все будет просто летать.

Ну если ты написал запросы, то все понял. А если нет, то значит не судьба.