Форум MySQL

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

К примеру взять сайт-каталог фильмов:
Есть таблица «Фильмы»: id, id категории, id актеров, описание, год, рейтинг, постер, хиты и еще штук 15 полей.
Есть таблица «Люди»: id, id фильма, описание, год, рейтинг, фото, хиты и так далее, тоже полей 10 – 15.
Таблица «Персонажи»: id, id фильма, описание, рейтинг, и тд.
Таблица категорий: id, id родителя, описание, и тд еще штук 10.

В таблице фильмов будет не меньше 200000 записей, но, скорей всего до миллиона. Людей будет где то 150000, а может и больше. Категорий штук 300. Персонажей несколько десятков тысяч.

На сайте будут выполняться «сложные» запросы, например: показать фильмы такого-то человека, за 2004 год, сортировать по рейтингу (названию, хитам), лимит 20.
Или показать все фильмы данного автора, сортировать по годам. Или показать 50 фильмов из данной категории, пропустив сначала 12750. Ну и так далее.

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

Поэтому у меня возникает вопрос как лучше создавать таблицы, стоит ли выносить в отдельные таблицы поля с айдишниками? И если выносить, то, как тогда делать сложные выборки с множеством переменных? Или нужно создавать отдельно таблицы с продублированной информацией, например:
Таблица «люди-фильмы»: id человека, id фильма, статус человека (опубликован ли), статус фильма, год фильма, рейтинг фильма ну и тд.
Таблица «категории-фильмы»: id категории, id фильма, статус категории, статус фильма, год фильма, рейтинг фильма и тд.
В общем создавать таблицы только из цифер и делать на все поля индекс.

Будет ли при данной разбивки одной таблицы на несколько поиск выполняться быстрее? Или я написал ересь?

Или лучше вынести только «прямые связи» по id в отдельную таблицу? Тогда получается что нам нужно сначала из такой таблицы выбрать все интересующие нас id в массив, а потом из полученного массива производить выборку с сортировкой.

В общем, помогите разобраться, как сделать лучше? Если у кого-то есть опыт работы с большими таблицами, то приведите, пожалуйста, цифры – как и что быстрее и почему?

1) не сочтите за грубость, но судя по описанию вы откусили слишком большой кусок и теперь не можете его прожевать. Вряд ли кто-то будет бесплатно помогать Вам в такой ситуации восполнять пробелы в знаниях, а раз возник вопрос - значит и пробелы на лицо.
2) любая база данных начинается с определения сущностей и на каждую сущность выделяется по таблице, далее устанавливаются связи между таблицами и проводиться нормализация. уже потом в зависимости от характера запросов (я так пронимаю преобладает выборка) проводиться денормализация. Еще нужно уделить внимание выбору типа таблицы, индексам и естественно кешированию.
3) для того чтобы ярче представлять картину возмите сумму всего проекта разделите пополам и получите сумму на построение БД.
4) все это теория... на практике все гораздо сложнее и мрачнее, да Вы и сами это прекрасно понимаете. Не факт, что какая-то упущенная мелочь не выйдет боком в будущем.
5) Всяких советчиков (включая меня), а особенно со всевозможными тестами гоните в шею... пусть идут мешки ворочать. Читайте правильные книги, анализируйте, думайте.
___
тут на форуме всегда готовы ответить, но не на такой обширный и расплывчатый вопрос
если речь о таблице - то дамп (и никаких id,pole,ogorod,sad )
если речь о запросе - то лучше 1 раз его увидеть оформленным в теги code ;)

Весь вопрос напоминает "sakila database" (с InnoDB , всякими VIEW и хранимыми процедурами ) (http://dev.mysql.com/doc/index-other.html)

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

судя по описанию база небольшая, думаю всего ~~ 200MB - 500MB , или меньще , если не со слишком большими описаниями к фильмам.