Возникли вопросы по структуре БД

Статус
В этой теме нельзя размещать новые ответы.

Spear

почемучка
Возникли вопросы по структуре БД

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

Делаю сайт, это будет портал развлекательной тематики. Только не что-то вроде "картинки-анекдоты-полифонические мелодии".

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

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

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

Теперь перехожу к вопросу, собственно:
нужно для начала мне (не без помощи форумчан :)) продумать то, как хранить "объекты" которыми будут выступать:
фильмы
актеры
песни
альбомы
компании (издатели, продюссерские объединения и так далее).

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

Понятно, что основные поля, такие как, ID объекта (будь то фильм или музыкальный исполнитель) и, собственно, ТИП объекта (фильм, альбом, компания, трек, издание) - это вещи очевидные.

А далее идет небольшая проблемка,
т.к. вспомогательная информация для каждого типа объекта может (и будет) отличаться.

Например, просматривая информацию об альбоме нужно вывести дату его релиза на территории США, Европы, России. Просматривая, скажем, страницу фильма нужно вывести имя режиссера, название компании, котоаря выпустила, и вообще несколько навзваний самого фильма - "рабочее (если есть)", "американское" и "русское" (также может быть альтернативное название) и, соответственно, даты выхода фильма в прокат в кажждом из основных регионов - США, европа, Россия.

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

с названиями, прцинипе, по-моему решено:
будет отделньая таблица, такой структуры:
ID обхекта (index) / тип названия / само название.
Но тут тоже есть маааленький вопросик: в такойм случае будет неудобно выводить список, например, всех фильмов, т.к. будет идти запрос вида (примерно)
select a.id, b.title from objects a, names b where a.id=b.id AND b.type='1'

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

Меня беспокоит только одна вещь - насколько это тяжелый запрос для бд? Просто я никогда ещё не сталкивался с базами такого размера и незнаю, как будет работать сайт. Если все ок, и запрос 50 фильмов с их названиями не вызовет трудностей (при нагрузке хотя бы в 30-40к посетителей в сутки и размерами обоих таблиц по 400 и 800к записей соответственно) то я буду очень рад. Если же нет - буду опять же благодарен за любые советы.

Я очень расчитываю на вашу помощь!
И выношу благодарность заранее всем, кто прочитал это немаленькое сообщение.
 

440hz

php.ru
как идея пойдет? реализация немного сложновата, зато руки потом развязываются почти полностью.

http://www.440hz.spb.ru/news/?NID=gdmhpu6ny30spzra

все объекты ложаться в 4 таблицы + еще 3 на дерево и саму модель. удобство в том, что все строится на лету.

используется полнотекстовый поиск.
как пример: http://www.art-index.org/search/?PAGE=1&QSQ=%E8%EA%EE%ED%E0

как все работает и скорость можно посмотреть на самом проекте.

p.s. че-то там с кавычками намудрено. 8( вечерком пофиксю ...
 

Spear

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

Буду очень благодарен если поможете ответами на вопрос.
И ещё, по поводу нагрузки (выбрка 50ти фильмов из двух таблиц с огнромным кол-вом данных)
 

master_x

Pitavale XXI wieku
Spear
огромное количество данных- это сколько? Я проводил тесты, не по твоей теме, но по схожей, и у меня были очень очень очень хорошие результаты с таблицей, в которой было более 11 тысяч рядов с текстом.
 

Spear

почемучка
master_x
а под миллионзаписей?

-~{}~ 20.02.06 23:30:

вот откуда столько:
допустим, в базе 20 000 фильмов, у каждого по 2 названия - в таблице с названиями уже пишется 40 000 записей.
+ у каждого фильма есть компании, продюссеры. Это те же объекты. то есть ещё минмум 40 000 записей в базу с именами.
+ стоит указать, скажем, режиссера - ещё 10-15 000 записей.
Это только по фильмам, да и 20 000 это же не предел, правда?

А если занести в базу 20 000 альбомов это:
20 000 названий + 20 000 имен исполнителей + в каждом альбоме по 10 треков в среднем, итого ещё 20 000*10.
получается неа 20 000 альбомов будет записей: 20 000+20 000 + 200 000. И это ещё без компаний, выпустивших диск.

Вот так вот :(

-~{}~ 21.02.06 00:33:

Вот, например,
мне интересно, как думаете - как устроена БД на этом сайте - http://www.ign.com ?

-~{}~ 21.02.06 00:37:

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

-~{}~ 21.02.06 00:55:

пока идея такая, но идея сырая, не додуманная.

1. таблица самих объектов.
Структура такая
id | type (int)

2. Таблица типов объектов:
type_id | title
Например:
1 / Фильм
2 / Компания
3 / Муз. альбом

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

3. Таблица типов данных (параметров)
value_id | name
например:
1 / дата выхода
2 / официальный сайт
3 / начало продаж
4 / Жанр (относится к музыке)
5 / Жанр (для фильмов)
6 / Жанр (для комиксов, например)
7 / издатель
8 / автор идеи (для фильмов, комсков, например)

4. Таблица, которая собственно и связывает обхект и его информацию.
То есть
obj_id (номер объекта из таблицы объектов) | param_id (айди параметра из таблицы параметров) | Value

Например, объект под номером 1 имеет издателя под номеров 4 (то есть его издателем является объект номер 4, для того, чтобы узнать название издателя, делаем запрос в таблицу названий. Если захотим сделать название ссылкой на оф. сайт то придется делать опять же запрос в таблицу объектов, выбрать значение параметра для данного объекта, с типом параметра 2), официальный сайт http://www.some.com, дату выхода... и так далее аж до бесконечности.

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

я ОЧЕНЬ надеюсь что объяснил свою мысль понятно.
Пожалуйста, скажите - стоит ли так делать? я изучил несколько крупных зарубежных сайтов подобной тематики и похоже что они действуют по похожей схеме.

Тут в чем проблема, вприцнипе - сложные (относительно) запросы, с джойнами на 2, 3 таблицы. с кучей параметров WHERE. Таким образов таблица связей "объект - параметр" может вырасти в обхеме до нескольких миллионов записей, к которым, к тому же, будут постоянные запросы.

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

440hz

php.ru
Автор оригинала: Spear
Спасибо, я обязательно посмотрю ваш движок, но мне всегда было сложно разбираться в чужих кодах, и при этом я путаюсб - что я вообще хотел и что я сделаю в итоге.
будут нужны исходники - пиши. могу сделать инсталяшку. там и поэкспереминтируешь сам на реальных данных. заодно и скорость померяем.
на 1000000 не гонял, но на 20000 объектах с кучами свойств на П3 512 памяти летало.

на счет скорости, www.chance.ru имеет 4500000 записей порядка 30 таблиц (всего около 60). и ни чё ... летает ... правда на 2-х процессорной тачке.
 
Статус
В этой теме нельзя размещать новые ответы.
Сверху