Суть:
На сайте регистрируются пользователи и на каждого создаётся отдельная таблица для личных сообщений.
Логикой выбора такого решения было то, что сами таблицы между собой не взаимодействую и не нужно делать выборку (например, founder = $user_id) при отображении всех сообщений одного пользователя.
Вопрос:
Серверу нехватает памяти и виртуальная машина частенько зависает, может ли быть этому причина большое количество этих таблиц (около 2,5 тыс.)?
6 апреля 2009 в 7:05
Леонид maxleo Максимов 4 апр 2009 в 19:53 +1
5 апреля 2009 в 22:03
я заметил
5 апреля 2009 в 20:00
Если вы обо мне, то я типо мальчек
) Это у меня ник такой, даж не знаю зачем…
4 апреля 2009 в 20:02
кстати, а что такого написала Marina Jee (единственная девушка, отписавшаяся в этом обсуждении), что у нее вдруг лучше по теории?
4 апреля 2009 в 19:05
да что вы, в этом деле важна только практика. никакие занятия не дадут вам такого опыта.
4 апреля 2009 в 19:04
да здравствуют девушки программисты, я все занятия по бд прогуливал, а девушки учились, у них по теории лучше)
4 апреля 2009 в 19:03
Делаешь в большой таблице на юзерИД первичный ключ или кластеризованный индекс и нашел одну запись с юзерИД=>нашел сразу все.
Можно еще комбинировать, т.к. у некластеризованного индекса в конце дерева находится кластеризованный, но эт чуть посложнее. Я про мс скуэль.
А вобще прежде чем чего-то делать, надо книжки почитать, а то будешь народ смешить.
Как пример отдельного хранения: у меня в БД есть 2 таблицы, одна о текущих ремонтах, другая о выполненных(для их выборки используется достаточно сложный запрос), большинство запросов по текущим ремонтам, поэтому вынесение их в отдельную таблицу дает прирост производительности.
А кол-во таблиц может грузить сервер если СУБД тормозит при увеличении кол-ва метаданных,это зависит от конкретной СУБД.
4 апреля 2009 в 0:01
1. разделять на отдельные таблицы смысла нет, ибо запрос founder = $user_id при наличии индекса на колонке founder будет работать быстро (работал как-то с таблицей на 270 тысяч записей – простые запросы быстрые)
2. выносить в отдельную БД смысла не вижу, если сайт, это что-то типа форума, то нагрузка на эту таблицу маленькая и тащить её в отдельную БД на отдельном сервере ради быстродействия не нужно
2 Алексей Cheat Злобин
<Вообще так делать _никогда_ нельзя.>
Вообще создание нескольких однотипных таблиц иногда имеет смысл, но конечно не в этом случае.
3 апреля 2009 в 23:00
> Но всё же могут ли эти 2000 таблиц быть причиной зависания виртуальной машины?
Хз, смотря как построена работа БД с файловой системой и кэш. По идее не должна…
Вообще так делать _никогда_ нельзя.
3 апреля 2009 в 17:00
Читай учебники про нормализацию
3 апреля 2009 в 16:00
афтар, тебе сюда =)
//thedailywtf.com/
//ru.thedailywtf.com
3 апреля 2009 в 13:04
В отдельную базу данных не выносится не потому что она на том или другом сервере находится, а потому что предметная область то одна и база данных единая (хотя ничто не мешает быть ей распределённой).
3 апреля 2009 в 11:02
Но всё же могут ли эти 2000 таблиц быть причиной зависания виртуальной машины?
3 апреля 2009 в 11:01
> а в отдельную бд выносить смысла нет, если эта база находится на том же самом сервере, а не на отдельном
Спасибо.
3 апреля 2009 в 10:04
Эх, достала школота… *насвистывает похоронный марш*
3 апреля 2009 в 10:02
забавно))
а в отдельную бд выносить смысла нет, если эта база находится на том же самом сервере, а не на отдельном
кстати, 2000 пользователей это совсем немного
3 апреля 2009 в 10:00
То что создание множества однотипных таблиц глупо, я уже понял…
Ну всё таки имеет ли смысл большую тяжёлую таблицу выносить в отдельную БД?
3 апреля 2009 в 9:05
Нет слов… Это как же надо начать думать, чтоб до такого додуматься o_O
3 апреля 2009 в 9:03
O_o естественно одна — это же одна сущность!
3 апреля 2009 в 9:02
Мой препод по БД за 2000 однотипных таблиц просто бы расстрелял=)
Для больших данных используй cпециальный тип, например как тут: //my-oracle.it-blogs.com/post-30.aspx
Я точно не уверен, но думаю должно помочь по перформансу.
3 апреля 2009 в 9:00
Мне кажется, что не стоит изобретать велосипед в тех случаях, когда решение уже придумано задолго до вашего рождения. Кури мануалы, аффтар!
3 апреля 2009 в 8:05
имхо жестоко…
а сколько юзеров на сайте?
3 апреля 2009 в 8:04
И имеет ли смысл большую тяжёлую таблицу выносить в отдельную БД?
3 апреля 2009 в 8:03
Сам. Логикой выбора такого решения было то, что сами таблицы между собой не взаимодействую и не нужно делать выборку (например, founder = $user_id) при отображении всех сообщений одного пользователя.
3 апреля 2009 в 8:02
Интересно,
а вы сами до этого дошли (создать >2000 таблиц),
или где-то это практика уже применена?