Таблица с большим количеством столбцов

Question

Если в моей таблице огромное количество столбцов (более 80), следует ли разделить ее на несколько таблиц с отношением 1: 1 или оставить все как есть? Зачем? Моя главная забота - производительность.

PS - моя таблица уже в 3-й нормальной форме.

PS2 - я использую MS Sql Server 2008.

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

Answer 1

80 столбцов действительно не так много ...

Я бы не беспокоился об этом с точки зрения производительности. Наличие одной таблицы (если вы обычно используете все данные в ваших стандартных операциях), вероятно, превзойдет несколько таблиц с отношениями 1-1, особенно если вы правильно проиндексировали.

Я бы беспокоился об этом (потенциально) с точки зрения обслуживания. Чем больше столбцов данных в одной таблице, тем менее понятной становится роль этой таблицы в вашей общей схеме. Кроме того, если вы, как правило, используете только небольшое подмножество данных, а все 80 столбцов требуются не всегда, разбиение на таблицы 2+ может повысить производительность.

Answer 2

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

Answer 3

С другой точки зрения, с точки зрения обслуживания и тестирования, если, как вы говорите, у вас есть 3 различные группы данных в одной таблице, хотя все с одним и тем же уникальным идентификатором (например, member_id), возможно, имеет смысл разделить их в отдельные таблицы.

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

Также для целей аудита, если вы хотите отслеживать последний идентификатор пользователя / метку времени для изменения данных участников. Если приложение администратора позволяет обновлять «Предпочтения» / «Сведения об учетной записи» / «Сведения о профиле» по отдельности, имеет смысл хранить их в отдельных таблицах, чтобы упростить отслеживание обновлений.

Не совсем ответ по SQL / Performance, но, возможно, что-то, на что можно взглянуть из дизайна базы данных и приложений pov

Answer 4

1-1 может быть проще, если вы скажете Member_Info; Member_Pref; Member_Profile. Наличие слишком большого числа столбцов может привести к его запуску, если вам нужно много varchar (255), так как вы можете превысить предел размера строк, и это просто делает его слишком запутанным.

Просто убедитесь, что у вас есть правильные ограничения на подделку ключей и т. Д., Поэтому в каждой таблице всегда есть 1 строка с одинаковым member_id

Answer 5

Зависит от того, что это за столбцы. Если у вас есть жестко заданные дублированные поля, такие как Colour1, Colour2, Colour3, то это кандидаты в дочерние таблицы. Мое общее правило: если есть несколько полей одного и того же типа (цвета), то вы можете также кодировать N из них, а не фиксированное число.

Rob.