Динамическое создание таблиц как средство разбиения: нормально или плохо? - PullRequest
2 голосов
/ 19 августа 2011

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

Например, скажем, у меня есть "виджеты" большой таблицы со столбцом "userID", определяющим владельца каждой строки,Если эта таблица имеет тенденцию становиться чрезвычайно большой, имеет ли смысл вместо этого, чтобы приложение создавало новую таблицу с именем "widgets_ {username}" для каждого нового пользователя?Предположим, что приложению когда-либо придется запрашивать только виджеты, принадлежащие одному пользователю за раз (т.е. не нужно пытаться объединить какие-либо из этих таблиц пользовательских виджетов вместе).

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

В качестве более общего вопроса, изменение схемы базы данных во время выполнения когда-либохорошо?

Редактировать: Этот вопрос в основном гипотетический;У меня было довольно хорошее чувство, что создание таблиц во время выполнения не имеет смысла.При этом в нашем приложении есть таблица с миллионами строк.SELECTs работают нормально, но такие вещи, как удаление всех строк, принадлежащих конкретному пользователю, могут занять некоторое время.По сути, мне нужны веские аргументы в пользу того, что просто динамическое создание таблицы для каждого пользователя не имеет смысла, когда меня спрашивают.

Ответы [ 4 ]

6 голосов
/ 19 августа 2011

НЕТ, НЕТ, НЕТ !! Теперь повторите за мной, I will not do this because it will create many headaches and problems in the future! Базы данных созданы для обработки большого количества информации. они используют индексы, чтобы быстро найти то, что вы ищете. думаете phone book насколько эффективен индекс? было бы лучше иметь разные книги для каждой фамилии?

Это не даст вам ничего хорошего в производительности. Сохраняйте одну таблицу, но обязательно внесите в нее идентификатор пользователя, и вы сможете быстро получить данные. однако, если вы разделите таблицу, становится невозможным / действительно очень трудно получить какую-либо информацию, охватывающую несколько пользователей, например, поиск всех пользователей по определенному виджету, подсчет всех виджетов определенного типа и т. д. вам нужно иметь каждый запрос быть построенным динамически.

Если удаление строк происходит медленно, посмотрите на это. Сколько строк одновременно мы говорим о 10, 1000, 100000? Какой у вас кластерный индекс в этой таблице? Не могли бы вы использовать «мягкое удаление», когда у вас есть столбец состояния, который вы ОБНОВЛЯЕТЕ до «D», чтобы пометить строку как удаленную. Можете ли вы удалить строки позже, с меньшей активностью базы данных. это медленное удаление, потому что оно блокируется другим действием. изучите их, прежде чем разбить стол.

3 голосов
/ 19 августа 2011

Нет, это была бы плохая идея.Однако некоторые СУБД (например, Oracle) позволяют разбивать одну таблицу на значения столбца, что позволит достичь цели без создания новых таблиц во время выполнения.Сказав это, разделение таблиц не является «нормой»: это обычно делается только в очень больших базах данных.

2 голосов
/ 19 августа 2011

Использование индекса на userID должно привести к почти одинаковой производительности.

На мой взгляд, изменение схемы базы данных во время выполнения - плохая практика.Рассмотрим, например, проблемы безопасности ...

1 голос
/ 19 августа 2011

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

Нет.(Улыбка)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...