|
Задавайте вопросы, мы ответим
Вы не зашли.
Есть таблица на скажем 25 столбцов, где собраны все данные по пользователю, но реально выборка по всем колонкам производиться крайне редко, напрашивается мысль, данные в принципе дёргаются чаще маленькими кусками по 3-4 столбца, почему бы не сделать скажем 7 таблиц разнеся данные туда. Но вот не задача, иногда всё-таки нужно выдать все столбцы, делать селект из нескольких таблиц, насколько я понимаю выглядит так, что движок mysql в памяти пытается соединит эти несколько таблиц, после чего делает по ним выборку, что занимает не мало времени. Мысль следующая: оставить параллельно большую таблицу, для таких вот нужд. Пускай данные будут дублированы, проблем с местом на дисках нету. Но тогда остаётся последняя проблема - как обновлять информацию одновременно в двух местах? Сделать двойной UPDATE с транзакцией или же может быть сделать триггер, который будет сам обновлять данные при изменение. Что скажите?
Неактивен
Мне кажется это неправильно мастерить такие конструкции. Оптимальный вариант, опять же на мой взгляд, две таблицы. Одна для авторизации, другая для хранения всяких пользовательских берюшек. При такой структуре вместо одного запроса получается два, НО и при этом они не всегда будут идти вместе. Обычно регистрационные данные (логин, пароль, и что-то там еще) не меняются. Меняется информация о пользователе (контакты, дата рождения), которые выносятся во вторую таблицу. Т.е. запрос в итоге получается остается один.
Далее, если нужно еще ускорение, прикидываем, сколько первая таблица с регистрационными данными будет занимать места. Так на вскидку, если информация о пользователе занимает 256 байт (128 байт ник и 128 байт пароль), при 5 000 000 аккаунтов (не знаю много это или мало) будет занимать 1220 мегабайт. Поэтому можно создать MEMORY таблицу. При регистрации заносим нового пользователя в неё и в обычную таблицу. Периодически (например когда авторизация какого-то пользователя не проходит + таймер) определяем размер той и другой таблицы, при несовпадении синхронизируем MEMORY таблицу с обычной. Все выборки производим из MEMORY таблицы.
С 7-ю таблицами вы сильно запутаетесь и впридачу только повысите нагрузку постоянным создаванием временных таблиц, имхо.
Насчет Multi UPDATE - с этим у MySQL очень плохо. Вообще MySQL предназначен для единичных вставок, остальные конструкции были добавлены позже и обычно не оптимизируются. Полагаю ситуацию должен спасти грядущий в 5.6 NoSQL, он вроде как рассчитан на любые конструкции.
Отредактированно kacergei (07.09.2012 00:51:32)
Неактивен
Эмм, я конечно понимаю, что тему я писала в 6 утра, но перечитав поняла, что писала, то что думала, и вроде как и надо, но ваш ответ настолько вышиб меня из колеи, что я берусь предположить, что вы перепутали темы, может такое быть?
Озвучу вопрос ещё раз, более просто
1. Все данные в одной таблице или разнести на 5-7 разных и указывать их в селекте через запятую?
2. Если взять вариант, чтоб иметь дублированные данные, в большой таблице, а так же в 5-7 маленьких. Данные при обновление, должны быть идентичными, что в большой, что в маленькой. Так, что вопрос. При изменение данных делать два вызова UPDATE или же написать триггер, который при UPDATE одной таблицы, будет сам бэкграунде обновлять вторую?
Неактивен
Не понимаю почему вы подумали что мой ответ не на ваш вопрос, может быть я как-то не правильно описал своё мнение.
При разбиении одной большой таблицы на несколько значительно усложняться запросы и в скорости вы точно потеряете. А вот насчет выигрыша я очень сомневаюсь. Ниразу не слышал чтобы выборка фиксированного количества полей из маленькой таблицы была быстрее чем из большой.
Я сталкивался с проекторами, которые построены в виде свалки из одной большой и множества дублирующих табоиц, с ужасными запросами и поэтому не советую вам этого делать. Понаделать ошибок при такой структуре очень легко, поскольку поля будут дублироваться, для добавления одного, вам придется править несколько таблиц. Если что-то произойдет - таблицы могут рассинхронизироваться. В некоторых запросах можете забыть указать все таблицы, в которых нужно произвести update. Select из нескольких таблиц порядочно тормознутее селекта из одной таблицы по понятным причиныам. Но если вы уверены что такого не произойдет, можете запариться, попробовать, может и правда получите какой-то выигрышь.
От использования MEMORY таблицы вы бы наверняка получили гораздо большую скорость, чем от такой структуры.
Поэтому касательно ваших двух вариантов - рекомендую оставить всё в одной, как это сделано во многих солидных движках.
Отредактированно kacergei (08.09.2012 20:17:02)
Неактивен
