Что лучше 3 таблицы с большим количеством данных или много маленьких таблиц

Сейчас веду работу по созданию каталога товаров на базе MySQL.
ОСь CentOS, База MySQL 5.5, типы таблиц InnoDB

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

Данных планируется более 2 - 3 млн. товаров. Более 50 различных категорий товаров (это количество может расти).

И вот не знаю, что лучше - много маленьких таблиц или несколько но больших???

Простая математика:
если поле проиндексировано что для поиска в таблице где 1024 записи надо всего 10 обращений к ней. Если у тебя чуть больше миллиона - то всего 20 обращений к ней (потому что миллион - это два в 20-ой степени). Тоесть если у тебя 4 миллиона записей - нам надо 22 обращения.
Допустим ты рещил разбить свою большую таблицу на 4 таблицы в каждой из которых по 1 миллиону записей. Итого чтобы осуществить поиск в 4-рёх таблицах по 1 миллиону - тебе надо 80 обращений...
Сам считай что медленней 22 обращения или 80 :)

Хотя тут наверно всё же от категорий зависит. Если это Телефоны и Стиралки, то я бы делал:
Общая таблица с товаром (ID,НомерКатегория,название,цена,ДатаПоставки)
Таблица с названиями категорий (IDкатегории,НазваниеКатегории)
таблица с характеристиками (IDтовара,НомерХарактеристики,СамоЗначениеХарактеристики)
таблица с названиями харктеристик (IDхарактеристики,НазваниеХарактеристики)

итого: надо найти все холожильники высотой больше метра: ищем в таблице характеристик где СамоЗначениеХарактеристики больше метра и при этом НомерХарактеристики соответсует значению "Высота холодильника".
А если надо найти все характеристики холодильника Atlan ZU-1212 - то ищешь его в таблице с товаром, и потом из таблицы с характеристиками выводишь все характеристики с его ID.

автор
если поле проиндексировано что для поиска в таблице где 1024 записи надо всего 10 обращений к ней

слава богу разработчики СУБД про это не знают.

автор
много маленьких таблиц или несколько но больших?

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

ScareCrow
слава богу разработчики СУБД про это не знают.

что ты имел в виду?

GHostly_FOX,

возьмите magento и не парьтесь. Там всё уже сделано до Вас.

InterSky
ScareCrow слава богу разработчики СУБД про это не знают. что ты имел в виду?

для поиска одной записи по индексу нужно два, для ОЧЕНЬ больших диапазонов три сравнения.

ScareCrow
автор если поле проиндексировано что для поиска в таблице где 1024 записи надо всего 10 обращений к ней слава богу разработчики СУБД про это не знают. автор много маленьких таблиц или несколько но больших? больший таблицы однозначно лучше, тем более что у тебя они не большие. можно сказать даже маленькие. то что ты хочешь делать называется EAV. почитай.

Спасибо! Буду читать.

Arhat109
GHostly_FOX, возьмите magento и не парьтесь. Там всё уже сделано до Вас.

Спасибо! Но задача у меня другая - разработка на Yii.

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

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

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

ScareCrow, не чтения, а сравнения. Хотя ТС имел в виду, похоже, именно чтения.