Общие > Базы данных

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

<< < (4/6) > >>

Меняздесьдавнонет:
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 в ней неуникальный.
Зачем самому себе жизнь портить?

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

Навигация

[0] Главная страница сообщений

[#] Следующая страница

[*] Предыдущая страница