Что лучше одна общая таблица или несколько маленьких

Максим2

Новичок
Собираюсь сделать для сайта категории товаров ( 4 - 5 уровней) по типу http://tiu.ru/ или http://spravka.ua/
Вопрос что лучше в данном случае одна таблица для всех категорий и их подуровней или 4-5 таблиц в зависимости от количества уровней, т.е. 1-ая таблица для категорий, 2-ая таблица для подкатегорий и т.д.

Мне, с точки зрения разработчика, гораздо удобнее работать с одной таблицей. А вот с точки зрения нагрузки на базу как правильнее поступить?
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
С точки зрения здравого смысла разработчика, таблица должна быть одна.
 

Максим2

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

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

Так что лучше использовать в данном случае? На сколько измениться нагрузка на базу?

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

Фанат

oncle terrible
Команда форума
Зачем?
Если они знают не больше тебя (а этот вопрос уровня "сколько будет дважды два" в базах данных), то какое значение будет иметь их мнение, чтобы на него влиять?
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
Зачем тебе в чем-то убеждать других? И вообще какая такая нагрузка на базу при 2000 записях, окстись)
 

Redjik

Джедай-мастер
Максим2
это по теме,т.к. разнесение таблицы на несколько - как раз нарушение одной из нормальных форм
 

fixxxer

К.О.
Партнер клуба
Само по себе партиционирование не нарушает никакие нормальные формы, никто не запрещает union партиционированных таблиц рассматривать как одну. :)

Если использовать встроенное в СУБД партиционирование, это становится очевидным.

Нарушение может возникнуть по факту в случае нарушения целостности базы (а в случае, если СУБД не поддерживает foreign keys на партиционированные таблицы, и ручной контроль целостности делается не в транзакции - это рано или поздно случится хотя бы на долю секунды :))
 

Максим2

Новичок
Зачем?
Если они знают не больше тебя (а этот вопрос уровня "сколько будет дважды два" в базах данных), то какое значение будет иметь их мнение, чтобы на него влиять?
В том то и дело, что больше меня: я примерно базы данных начал изучать и работать с ними примерно год назад (причем это не основная моя работа, а хобби), а люди которые советуют делать несколько таблиц, работают уже лет 10 минимум с базами данных.
Максим2
это по теме,т.к. разнесение таблицы на несколько - как раз нарушение одной из нормальных форм
В статье, что вы привели в качестве примера как раз речь идет о том, чтобы разбивать ненормальные таблицы на несколько для приведениях их к нормальному виду. Где Вы там усмотрели прямо противоположное мнение я не знаю. Может между строк нужно читать?
Но опять повторюсь в предлагаемые мной к рассмотрению варианты построения таблиц являются нормальными.
Просто работать с одной базой удобнее, чем с несколькими вопрос в том, есть ли смысл разделения для снижения нагрузки на базу данных?
Вот, c0dex пишет, что нагрузка при 2000 записях будет незаметной, но нельзя же вот так утрировать поставленную задачу - я 2000 привел в качестве примера, например если брать категории с tiu.ru, то там, как мне говорили, порядка 9000 записей. Да и в базе данных будет находится не одна(и) таблицы с категориями, но и еще десяток других таблиц, для других задач. Так что рассматривать нагрузку нужно в целом. Я к сожалению не разбираюсь в том как подсчитать нагрузку на базу данных, я знаю что н нужно делать лишних запросов к базе если это можно избежать, я знаю, что нужно стараться правильно составлять запросы к базе данных. Но вот что не знаю насколько будет зависеть нагрузка от запроса к большой или маленькой базе данных, если разница действительно небольшая, то это повод для убеждения. Можно ли дать ссылки на подобный материал? Как можно проверить опытным путем?
А на данный момент кроме общих фраз типа "Да это же очевидно!" я ничего не прочитал.
Само по себе партиционирование не нарушает никакие нормальные формы, никто не запрещает union партиционированных таблиц рассматривать как одну. :)
А вот про партицирование мне понравилось - я вообще не знал о такой возможности - Спасибо!, нужно будет попробовать.
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
люди которые советуют делать несколько таблиц, работают уже лет 10 минимум с базами данных
Некоторые люди и после 20 лет остаются не совсем грамотными в своей области, это не показатель и ты, надеюсь, не такой.

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

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

В общем все вышесказанное мое имхо, а ты волен сделать как тебе удобно.
 

Максим2

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