Есть ли основания беспокоиться о порядке столбцов в таблице?

Я знаю, что вы можете изменять порядок столбцов в MySQL с помощью FIRST и AFTER, но зачем вам это беспокоить? Так как при вставке данных в хороших запросах явно указываются столбцы, есть ли причина заботиться о том, в каком порядке расположены ваши столбцы в таблице?

73 голоса | спросил lynn 21 Maypm09 2009, 22:59:36

12 ответов


0

Порядок столбцов оказал большое влияние на производительность некоторых из настроенных мной баз данных, включая Sql Server, Oracle и MySQL. Этот пост содержит хорошие правила :

  • Сначала столбцы первичного ключа
  • Столбцы внешнего ключа следующие.
  • Следующие часто просматриваемые столбцы
  • Часто обновляемые столбцы позже
  • Обнуляемые столбцы последние.
  • Наименее используемые столбцы, допускающие значение NULL, после более часто используемых столбцов, которые могут иметь значение NULL.

Примером различий в производительности является поиск по индексу. Механизм базы данных находит строку, основанную на некоторых условиях в индексе, и возвращает адрес строки. Теперь скажите, что вы ищете SomeValue, и он находится в этой таблице:

 SomeId int,
 SomeString varchar(100),
 SomeValue int

Движок должен угадать, где начинается SomeValue, потому что SomeString имеет неизвестную длину. Однако, если вы измените порядок на:

 SomeId int,
 SomeValue int,
 SomeString varchar(100)

Теперь движок знает, что SomeValue может быть найдено через 4 байта после начала строки. Таким образом, порядок столбцов может оказать значительное влияние на производительность.

РЕДАКТИРОВАТЬ: Sql Server 2005 хранит поля фиксированной длины в начале строки. И в каждой строке есть ссылка на начало varchar. Это полностью сводит на нет эффект, который я перечислил выше. Так что для последних баз данных порядок столбцов больше не оказывает никакого влияния.

ответил Andomar 21 Maypm09 2009, 23:04:34
0

Во время обучения Oracle на предыдущей работе наш администратор БД предположил, что ставить все необнуляемые столбцы перед обнуляемыми столбцами было выгодно ... хотя я не помню подробностей, почему. Или, может быть, только те, которые будут обновлены, должны пойти в конце? (Возможно, откладывает необходимость перемещения строки, если она расширяется)

В общем, это не должно иметь никакого значения. Как вы говорите, запросы должны всегда указывать сами столбцы, а не полагаться на порядок из "select *". Я не знаю ни одной БД, которая позволяла бы их изменять ... ну, я не знал, что MySQL разрешил это, пока вы не упомянули об этом.

ответил araqnid 21 Maypm09 2009, 23:04:36
0

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

ответил Craig Walker 21 Maypm09 2009, 23:03:29
0

Читабельность вывода, когда вам нужно набрать:

select * from <table>

в вашем программном обеспечении для управления базами данных?

Это очень ложная причина, но сейчас я не могу думать ни о чем другом.

ответил ChrisF 21 Maypm09 2009, 23:02:39
0

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

Марк

РЕДАКТИРОВАТЬ: из записи в Википедии по реляционной базе данных, вот соответствующая часть, которая мне ясно показывает, что порядок столбцов никогда не должен вызывать беспокойство:

Отношение определяется как набор n-кортежей. Как в математике, так и в модели реляционных баз данных набор представляет собой неупорядоченный набор элементов, хотя некоторые СУБД налагают порядок на свои данные. В математике кортеж имеет порядок и допускает дублирование. Э. Ф. Кодд первоначально определил кортежи, используя это математическое определение. Позже Э. Ф. Кодд понял, что использование имен атрибутов вместо упорядочивания будет намного удобнее (в общем) на компьютерном языке, основанном на отношениях. Это понимание по-прежнему используется сегодня.

ответил marc_s 21 Maypm09 2009, 23:01:42
0

Единственная причина, по которой я могу думать, это отладка и пожаротушение. У нас есть таблица, столбец которой «имя» появляется примерно 10-й в списке. Это неприятно, когда вы делаете быстрый выбор * из таблицы, где id в (1,2,3), а затем вам приходится прокручивать страницу, чтобы посмотреть на имена.

Но это все.

ответил Chris Simpson 21 Maypm09 2009, 23:05:06
0

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

ответил James L 21 Maypm09 2009, 23:05:00
0

Если вы будете часто использовать UNION, это облегчит сопоставление столбцов, если у вас есть соглашение об их упорядочении.

ответил Allain Lalonde 21 Maypm09 2009, 23:05:03
0

Помимо очевидной настройки производительности, я просто наткнулся на случай, когда переупорядочивание столбцов приводило к сбою (ранее работавшего) сценария sql.

Из документации «столбцы TIMESTAMP и DATETIME не имеют автоматических свойств, если они не указаны явно, за исключением следующего: по умолчанию первый столбец TIMESTAMP имеет как DEFAULT CURRENT_TIMESTAMP, так и ON UPDATE CURRENT_TIMESTAMP, если ни один не указан явно" https://dev.mysql.com/doc/refman/5.6/en/временная метка-initialization.html

Итак, команда ALTER TABLE table_name MODIFY field_name timestamp(6) NOT NULL; будет работать, если это поле является первой отметкой времени (или датой-временем) в таблице, но не иначе.

Очевидно, что эту команду alter можно исправить, добавив значение по умолчанию, но тот факт, что сработал запрос, переставший работать из-за переупорядочения столбцов, сделал мне больно.

ответил slacker525600 8 ThuEurope/Moscow2016-12-08T20:56:29+03:00Europe/Moscow12bEurope/MoscowThu, 08 Dec 2016 20:56:29 +0300 2016, 20:56:29
0

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

ответил Soviut 21 Maypm09 2009, 23:04:10
0

В общем, что происходит в SQL Server при изменении порядка столбцов через Management Studio, это то, что он создает временную таблицу с новой структурой, перемещает данные в эту структуру из старой таблицы, удаляет старую таблицу и переименовывает новую один. Как вы можете себе представить, это очень плохой выбор для производительности, если у вас большой стол. Я не знаю, делает ли My SQL то же самое, но это одна из причин, почему многие из нас избегают переупорядочения столбцов. Поскольку select * никогда не следует использовать в производственной системе, добавление столбцов в конце не является проблемой для хорошо спроектированной системы. Порядок столбцов в таблице не должен быть перепутан.

ответил HLGEM 21 Maypm09 2009, 23:08:35
0

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

Конечно, любое влияние на производительность сильно зависит не только от производителя, которого вы используете, но также и от версии. Несколько месяцев назад я заметил, что наши Postgres не могут использовать индекс для сравнения «как». То есть, если вы написали «somecolumn like« M% »», он не был достаточно умен, чтобы переходить к M и выходить, когда он нашел первый N. Я планировал изменить группу запросов, чтобы использовать «между». Затем мы получили новую версию Postgres, и она с умом справилась. Рад, что не удосужился изменить запросы. Очевидно, что здесь это не имеет прямого отношения, но я хочу сказать, что все, что вы делаете из соображений эффективности, может быть устаревшим со следующей версией.

Порядок столбцов почти всегда очень важен для меня, потому что я обычно пишу общий код, который читает схему базы данных для создания экранов. Например, мои экраны «редактировать запись» почти всегда создаются путем чтения схемы, чтобы получить список полей, а затем отображения их по порядку. Если бы я изменил порядок столбцов, моя программа все равно работала бы, но отображение могло быть странным для пользователя. Например, вы ожидаете увидеть имя /адрес /город /штат /почтовый индекс, а не город /адрес /почтовый индекс /имя /штат. Конечно, я мог бы поместить порядок отображения столбцов в код, контрольный файл или что-то еще, но затем каждый раз, когда мы добавляли или удаляли столбец, мы должны были помнить, чтобы обновлять контрольный файл. Мне нравится говорить вещи один раз. Кроме того, когда экран редактирования построен исключительно из схемы, добавление новой таблицы может означать написание нулевых строк кода для создания экрана редактирования для него, что очень круто. (Ну, ладно, на практике обычно мне нужно добавить запись в меню для вызова универсальной программы редактирования, и я, как правило, отказался от универсального «выберите запись для обновления», потому что существует слишком много исключений, чтобы сделать его практичным .)

ответил Jay 22 Mayam09 2009, 02:37:32

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132