Таблица с большим количеством столбцов
5 ответов
80 столбцов на самом деле не так много ...
Я бы не стал беспокоиться об этом с точки зрения производительности. Наличие одной таблицы (если вы обычно используете все данные в своих стандартных операциях), вероятно, превзойдет несколько таблиц с отношениями 1–1, особенно если вы правильно индексируете.
Я бы побеспокоился об этом (потенциально) хотя с точки зрения обслуживания. Чем больше столбцов данных в одной таблице, тем менее понятной становится роль этой таблицы в вашей общей схеме. Кроме того, если вы обычно используете только небольшой набор данных,
По поводу производительности - это зависит. Чем больше строка, тем меньше строк может быть прочитано с диска за одно чтение. Если у вас много строк, и вы хотите иметь возможность очень быстро читать основную информацию из таблицы, то, возможно, стоит разделить ее на две таблицы - одну с небольшими строками и только с основной информацией, которую можно быстро прочитать. и дополнительную таблицу, содержащую всю информацию, которую вы редко используете, которую вы можете найти при необходимости.
Taking another tack, from a maintenance & testing point of view, if as you say you have 3 distinct groups of data in the one table albeit all with the same unique id (e.g. member_id) it might make sense to split it out into separate tables.
If you need to add fields to say your profile details section of the members info table, do you really want to run the risk of having to re-test the preferences & account details elements of your app as well to ensure no knock on impacts.
Also for audit trail purposes if you want to track the last user ID/Timestamp to change a members data. If the admin app allows Preferences/Account Details/Profile Details to be updated separately then it makes sense to have them in separate tables to more easily track updates.
Not quite a SQL/Performance answer but maybe something to look at from a DB & App design pov
1-1 может быть проще, если вы скажете Member_Info; Member_Pref; Member_Profile. Слишком много столбцов может заставить его работать, если вам нужно много varchar (255), так как вы можете выйти за предел размера строки, и это просто сбивает с толку.
Просто убедитесь, что у вас есть правильные ограничения ключа forgein и тому подобное, поэтому в каждой таблице всегда есть 1 строка с одинаковым member_id
Зависит от того, что это за столбцы. Если у вас есть жестко закодированные дублированные поля, такие как Colour1, Colour2, Colour3, то они являются кандидатами в дочерние таблицы. Мое общее эмпирическое правило заключается в том, что если существует более одного поля одного типа (цвет), вы можете также кодировать для N из них, а не для фиксированного числа.
Роб.