[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Что лучше, несколько мелких таблиц или одна крупна
freelander

Здравствуйте уважаемые пользователи форума! Помогите советом. Проектирую базу данных на MySQL, задался простым, но очень важным вопросом - что лучше, одна большая таблица или много маленьких? (с точки зрения дальнейшей обработки и пр.). Допустим есть данные их можно поместить в 1 таблицу 100 000 записей или в 100 по 1000 или в 10 по 10000. Будет стандартная работа с базой: добавление, удаление, несложный поиск в ней.
И еще, скажите пожалуйста сколько записей в таблице в MySQL максимально допустимо?
Спасибо большое, жду ответов от знающих людей.



Спустя 4 минуты, 24 секунды (23.12.2009 - 15:20) FatCat написал(а):
С точки зрения поиска, однозначно лучше 1 таблица.
Но для многопользовательского режима имеет значение размер таблицы: оперативной памяти сервера для постоянной работы с таблицей потребуется примерно вдвое больше, чем сам размер таблицы.

Спустя 37 минут, 30 секунд (23.12.2009 - 15:58) freelander написал(а):
Смысл в том что есть однотипные записи их можно хранить в одной таблице или в нескольких, потому что логически записи будут большими группами. есть ли смысл эти записи делить на таблицы по этим группам, простой пример есть записи допустим по городам, стоит ли делать для каждого города отдельную таблицу если для каждого такого города будет по 10 000 записей. То есть для 10 городов 100 000записай, но вобще городов может быть больше 10 например 40 или 50. Более всего важна именно выборка из таблиц, поиск второстепенная задача и не особо важен Или все записи в том числе из разных городов слоить в одну кучу, или раскидать по отдельным таблицам.

Спустя 6 минут, 48 секунд (23.12.2009 - 16:05) freelander написал(а):
хотел еще добавить, что про нормализацию речи не идет, меня интересует вопрос именно с физической точки зрения - скорость выборки главное.

Спустя 35 минут, 15 секунд (23.12.2009 - 16:40) freelander написал(а):
Города я просто так привел, как бы логически если делить. но смысл не в том. Есть объем данных которому не нужна нормализация и так далее. Добавление новых данных и прочее мы сейчас не рассматриваем. Есть объем данных, положим он не меняется. мне нужно выбирать массивы данных из этого набора. где это бустрее будет происходить из таблицы размерностью 100 000 записаей, или из 10 таблиц размерностью 10 000 записаей.

Важное замечание: выборка всегда только из ОДНОЙ таблицы. Тоесть если я делю на 10 то выбирать мне нужно будет только из одной, мне известной таблицы. А не из нескольких. По сути вопрос сводитьс к тому откуда будет выборка быстрее из большой или из мальнекой таблицы. Ответ очевиден, из маленькой, но мне важна именно разница скоростей, на сколько она будет существенна, или наоборот принебрежительно мала. Интересует именно если таблица будет довольно таки большой в 300 000 тыщ записей.

Спустя 10 минут, 53 секунды (23.12.2009 - 16:51) VolCh написал(а):
По-моему, для выборки разницы практически нет, если выборка идёт по индексируемому условию. Разница между 100 000 и 10 000 - максимум 17 итераций против максимум 14 в двоичном дереве

Спустя 2 часа, 37 минут, 58 секунд (23.12.2009 - 19:29) FatCat написал(а):
Цитата (freelander @ 23.12.2009 - 17:40)
мне важна именно разница скоростей, на сколько она будет существенна, или наоборот принебрежительно мала

Я с этим вопросом специально экспериментировал.
Обычный селект уникального значения из таблицы:
$query = "SELECT * FROM table WHERE id = ".$id;

Поле id индексированное, автоинкремент.
Средний размер строки около 1 Кб: таблица на 1000 000 строк весит гигабайт.

Время удваивается примерно на каждые 50 000 строк таблицы и если на 50 000 строк время операции меньше 0.001 секунды, то для таблицы 1000 000 строк время операции не укладывается в 30-секундный таймлимит.

Спустя 2 часа, 26 минут, 35 секунд (23.12.2009 - 21:55) VolCh написал(а):
FatCat это на каком железе? и какая БД и движок?
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.