О программирование

[Jooz]

Закралась в голове мысля....

Сейчас проектирую базенку, в основной таблице набирается под 60 колонок. При этом объем хранимых в ней данных планируется в пределах 100.000 - 1.000.000 строк, индексы и прочее вроде продумано, вопрос в том, что может стои разбить таблицу на пару мелких?
Но смущает то что тогда возрастет число подзапросов и соответственно процессорное время. Как быть не пойму... В самой таблице данные мелкие, типа INT Enum есть 1 поле TEXT.
Может у кого был опыт шевелить базы (таблицы) с большим числом колонок? Что производительней: 2 таблицы с 30 колонками, но линкующимеся по ключу или 1 с 60.

[grey]

Используй индексы.

По идее 1 с 60. А вообще проверь сам - тогда будешь точно знать.

[Sasa]

оценочно
размер базы будет порядка 60Мб - ерунда - дай памяти СУБД достаточно и она вся в память ляжет вместе с индексом

я бы не разбивал, если это логически не оправдано
все равно будешь всю строку целиком дергать

[Wink]

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

[Sasa]

гммм
а если он не нужны все сразу то зачем их объединять в одну таблицу?

я как раз понял что нужны все 60 в одном месте

[Jooz]

Да по индексам все в порядке все довольно продумывал. С базами работы опыт уже 7 лет, вот только сейчас проект замутил где очень много данных который по логике лучше хранить в одной таблице из-за чего она разрослась столбцами. С памятью проблем не должно быть (colocation). Дело в производительности. Поизучал сильные базы которые держат хорошо нагрузку без кэширования.
Для примера рассмотрел базу vBulletin на как на SE форуме где дикое количество постов и активность. Там в основной таблице около 50 столбцов, да еще и подзапросы во всю юзаются. И не че летает.
Всем спасибо!

[Jooz]

Сообщение от Wink

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

В том то и дело, что одновременно считываться будет 40% запросов.
Записывать в 4 столбца 50% запросов. Активность таблицы очень большая. Есть еще идея часть задач переложить на php в виде
$value = "val1|val2|val3|val4";
и implode юзать, а $value хранить в одном поле.
Так можно уменьшить число колонок до 30, вот только опять вопрос в производительности. Не выйдет ли то на то...

[Sasa]

Сообщение от LIGHT

Есть еще идея часть задач переложить на php в виде
$value = "val1|val2|val3|val4";
и implode юзать, а $value хранить в одном поле.

1) вот этого бы я делать не стал, или точнее в посл очередь
я верю что СУБД лучше соптимизирует все внутри себя

2) а вообще мы пытаемся рассуждать про задачу о которой ничего не знаем

3) и обсуждаем оптимизацию неизвестной нам СУБД, есть мнение что они бывают разные ...

[Alex007]

Сообщение от Sasa

2) а вообще мы пытаемся рассуждать про задачу о которой ничего не знаем

3) и обсуждаем оптимизацию неизвестной нам СУБД, есть мнение что они бывают разные ...

Я поэтому и не стал советовать. Оптимизация непонятной БД - нетривиальная задача, а мои телепаты в отпуске.

[Jooz]

Сообщение от Alex007

Я поэтому и не стал советовать. Оптимизация непонятной БД - нетривиальная задача, а мои телепаты в отпуске.

Ну как же я сказал таблица будет дико большое 1Млн записей это минимум дальше в верх, база основная значит каждый вызов странички вызывает таблицу. Вызовов в час более 10.000 дальше вверх.
Какие еще параметры тут можно добавить.
Естественно нужно с запасом на будущее X100