Задачка не для слабых ....

[Меняздесьдавнонет]

listopad
Имей в виду, что  fidget - модератор этого форума, и кое-что в базах данных понимает.
А Alexandr - новичок. Достаточно почитать его ответы в соседних ветках.

Это тебе так, для информации.

[Меняздесьдавнонет]

Пример.
Только дикарь, который вообще не представляет себе, как обращаться с базой данных, способен на ТАКОЕ:

ALTER TABLE DROP id
...
INSERT .....
ALTER TABLE ADD id mediumint NOT NULL auto_increment UNSIGNED

[fidget]

Не верно. Вернее не всегда.

Допустим для его подсчетов по знакам зодиака он будет использоваться

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

Кстати пока писала мне тут в голову пришла еще одна идея
я так понимаю, что ты используешь таблицы MyISAM и все твои 9 таблиц идентичны, тогда тебе есть смысл использовать MERGE таблицы
Это даст тебе возможность использовать таблицы по отдельности и вместе как одну большую таблицу
Читать тут:
http://www.mysql.com/doc/en/MERGE.html

тогда ты вполне сможешь обойтитсь одним запросом и без временных таблиц

[fidget]

RomikChef
Ромик, за "кое-что понимает" конечно спасибо

но плз, если переходишь на личности, то во флэйм пожалуста или в приват

[Меняздесьдавнонет]

fidget
Ок, кое-что исправил.
И все же, хоть merge и решение, но основное правило никто не отменял. Подобные данные должны лежать в одной таблице.
А все эти высосанные из пальца идеи о том, что скорость упадет, надо пресекать в корне.

К тому же, наверняка с merge будут еще проблемы, хотя бы из-за того, что id в ней неуникальный.
Зачем самому себе жизнь портить?

Вся проблема от того, что человек идет не от проектирования базы данных, а от каких-то своих соображений.
проектирование базы данных - это половина дела.
Если ее сделать нормально, то потом проблем возникать не будет.
Мало ли какие выборки ему поднадобятся в будущем? Уже сейчас ему приходится ставить заплаты в виде временных таблиц, на криво спроектированную базу данных.
помещение всез данных в одну таблицу, снимет и текущие, и БУДУЩИЕ проблемы.

[fidget]

Подобные данные должны лежать в одной таблице.

угу, в 99% так всегда и делается
хотя было пару случаев, когда мы насильно разделяли на таблицы по 2м причинам:
1. запросов по всем категориям почти не было, основная часть по отдельной категории.
2. Данные очень часто обновлялись и т.к. MyISAM таблицы поддерживают только table locking - это доставляло определенного рода неудобства
Хотя после того как перевели базу на InnoDB все данные объединили в одну таблицу и насколько я знаю так оно и работает.

но это был частный случай

[fidget]

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

и есть еще очень хорошая штука - нормализация


[OFF]к сожалению значительная часть людей, которые базами знанимаются теории реляционных баз данных не знают совершенно [/OFF]

[Alexandr]

Только дикарь, который вообще не представляет себе, как обращаться с базой данных, способен на ТАКОЕ:

Цитата:
ALTER TABLE DROP id
...
INSERT .....
ALTER TABLE ADD id mediumint NOT NULL auto_increment UNSIGNED

Нууу.... Эт ты погорячился. Базу буду наполнять почти вручную, следовательно путь вполне приемлемый.
[off]

А Alexandr - новичок. Достаточно почитать его ответы в соседних ветках.

Вот уж кто бы говорил. Согласен, что знаю не все, но достаточно сообразителен и обучаем. :-)
[/off]

Подобные данные должны лежать в одной таблице.
угу, в 99% так всегда и делается

Я просто реально столкнулся с этой проблемой:
http://www.autodealer.ru/db_part.php
Раньше была 1 таблица и в ней type_id.
Когда данных увеличилось с 20000 до 250000.
То наступила ошибка max_connections, т.к.
Напр. запрос
SELECT count(*) FROM part WHERE type_id=1;(~249000)
SELECT count(*) FROM part WHERE type_id=2;(~1000)
SELECT count(*) FROM part WHERE type_id=3;(~50)
выполнялся около 1мин.
а про поиск лучше не вспоминать вообще.
Однако после разнесения по 3-м таблицам скорость возросла в десятки раз.
Поэтому и говорю.
Всем пасибо.

[Alexandr]

И ещё. В базах данных нет одного верного, идеального решения на ВСЕ проблемы, всегда бывают отступления от общих правил.

[Меняздесьдавнонет]

Гы!
индекс по полю type_id строить не пробовали?
считать не count(*),а count(id) не пробовали?
Еще раз повторю - проблемы скорости и проблемы разделения таблиц - РАЗНЫЕ.

[listopad]

Все понял , всем спасибо......

иду изучать реляционные базы данных
и проектировать свою заново....

[Alexandr]

Гы!

Не ... а так и есть.

индекс по полю type_id строить не пробовали?

Ес-но. Первое что сделал.

считать не count(*),а count(id) не пробовали?

Юзай EXPLAIN:
Напр.
EXPLAIN SELECT count(*) FROM top WHERE ctg=1;
EXPLAIN SELECT count(id) FROM top WHERE ctg=1;

Код: [Выделить]


table type possible_keys key key_len ref rows Extra
top ref ctg ctg 1 const 28 where used; Using index

table type possible_keys key key_len ref rows Extra
top ref ctg ctg 1 const 28 where used

Вишь что в Extra написано.

Еще раз повторю - проблемы скорости и проблемы разделения таблиц - РАЗНЫЕ.

Ес-но, но если 2-е исключает первое, то это зае#@сь.

[Chs]

Уважаемые господа, принимавшие участие в данной дискуссии, будьте корректны в выражениях! И старайтесь держаться сути вопроса.
Alexandr, Вам персональное предупреждение.

[Alexandr]

[OFF]Chs

Alexandr, Вам персональное предупреждение.

Не понял.

будьте корректны в выражениях!

Вродь всегда был и всех призывал.

И старайтесь держаться сути вопроса.

Согласен, отшёл малость от сути. Однако сделал это только по одной причине - дабы дать аргументированный ответ некоторому человеку, который как раз
!=

будьте корректны в выражениях

[/OFF]

[dymka]

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