Там какая-либо причина состоит в том, чтобы волноваться о порядке столбцов в таблице?
Ваша проблема в том, что цикл продолжает работать, даже если вы уже «решили». Вы должны добавить строку break после a=a+1
12 ответов
Порядок столбцов оказал большое влияние на производительность некоторых настроенных мной баз данных, включая 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. Это полностью сводит на нет указанный выше эффект. Таким образом, для недавних баз данных порядок столбцов больше не влияет.
Обновление:
В MySQL может быть причина для этого.
Поскольку типы данных переменных (например, VARCHAR ) являются хранится с переменной длиной в InnoDB , механизм базы данных должен пройти по всем предыдущим столбцам в каждой строке, чтобы узнать смещение данной.
Влияние может быть таким большим, как 17% для 20 столбцов.
Подробнее см. Эту запись в моем блоге:
В Oracle , завершающий NULL столбцы не занимают места, поэтому вы всегда должны помещать их в конец таблицы.
Также в Oracle и в SQL Server , в случае большой строки, ЦЕПОЧКА СТРОК может произойти.
ИЗМЕНЕНИЕ СТРОКИ разбивает строку, которая не 't вписывается в один блок и охватывает несколько блоков, связанных связанным списком.
Чтение конечных столбцов, которые не помещаются в первый блок, потребует обхода связанного списка, что приведет к лишнему Операция ввода-вывода .
См. эту страницу для иллюстрации ЦЕПИ СТРОК в Oracle :
Вот почему вы должны поместить столбцы часто используются в начале таблицы, и столбцы, которые вы не часто используете, или столбцы, которые имеют тенденцию быть NULL , до конца таблицы.
Важное примечание:
Если вы понравился этот ответ и вы хотите проголосовать за него, пожалуйста, также проголосуйте за ответ @Andomar .
Он ответил то же самое, но, похоже, его голосование было отклонено без всякой причины.
Чтение завершающих столбцов, которые не помещаются в первый блок, потребует обхода связанного списка, что приведет к дополнительной операции ввода-вывода .
См. на этой странице ] для иллюстрации СОЕДИНЕНИЕ СТРОК в Oracle :
Вот почему вы должны помещать столбцы, которые вы часто используете, в начало таблицы, а столбцы, которые вы не используете часто, или столбцы, которые обычно имеют вид NULL , до конца таблицы.
Важное примечание:
Если вам нравится этот ответ и вы хотите проголосовать за него, проголосуйте также за @Andomar ответ .
Он ответил то же самое, но, похоже, его голос отклонен без причины.
Чтение завершающих столбцов, которые не помещаются в первый блок, потребует обхода связанного списка, что приведет к дополнительной операции ввода-вывода .
См. на этой странице ] для иллюстрации СОЕДИНЕНИЕ СТРОК в Oracle :
Вот почему вы должны помещать столбцы, которые вы часто используете, в начало таблицы, а столбцы, которые вы не используете часто, или столбцы, которые обычно имеют вид NULL , до конца таблицы.
Важное примечание:
Если вам нравится этот ответ и вы хотите проголосовать за него, проголосуйте также за @Andomar ответ .
Он ответил то же самое, но, похоже, его голос отклонен без причины.
что приведет к дополнительной операции ввода-вывода .
См. эту страницу для иллюстрации ЦЕПИ СТРОК в Oracle :
Вот почему вы должны помещать столбцы, которые вы часто используете, в начало таблицы, и столбцы, которые вы не используете часто, или столбцы, которые обычно имеют NULL , в конец таблицы.
Важное примечание:
Если вам нравится этот ответ и вы хотите проголосовать за него, проголосуйте также за ответ @Andomar .
Он ответил то же самое, но, похоже, быть отвергнутым без причины.
что приведет к дополнительной операции ввода-вывода .
См. эту страницу для иллюстрации ЦЕПИ СТРОК в Oracle :
Вот почему вы должны помещать столбцы, которые вы часто используете, в начало таблицы, и столбцы, которые вы не используете часто, или столбцы, которые обычно имеют NULL , в конец таблицы.
Важное примечание:
Если вам нравится этот ответ и вы хотите проголосовать за него, проголосуйте также за ответ @Andomar .
Он ответил то же самое, но, похоже, быть отвергнутым без причины.
или столбцы, которые обычно имеют значение NULL , до конца таблицы.
Важное примечание:
Если вам нравится этот ответ и вы хотите проголосовать за него, проголосуйте также за @ Андомар ответ .
Он ответил то же самое, но, похоже, голосование было отклонено без всякой причины.
или столбцы, которые обычно имеют значение NULL , до конца таблицы.
Важное примечание:
Если вам нравится этот ответ и вы хотите проголосовать за него, проголосуйте также за @ Андомар ответ .
Он ответил то же самое, но, похоже, голосование было отклонено без всякой причины.
Во время обучения Oracle на предыдущем задании наш администратор баз данных предположил, что размещение всех столбцов, не допускающих значения NULL, перед столбцами, допускающими значение NULL, было выгодным ... хотя я не помню подробностей, почему. Или, может быть, в конце должны быть отправлены только те, которые, вероятно, будут обновлены? (Возможно, откладывает необходимость перемещать строку, если она расширяется)
В общем, это не должно иметь никакого значения. Как вы говорите, запросы всегда должны указывать сами столбцы, а не полагаться на порядок из "select *". Я не знаю ни одной БД, которая позволяет их изменять ... ну, я не знал, что MySQL позволяет это, пока вы не упомянули об этом.
Некоторые плохо написанные приложения может зависеть от порядка / индекса столбца, а не от имени столбца. Их не должно быть, но это случается. Изменение порядка столбцов приведет к поломке таких приложений.
Читабельность вывода, когда вам нужно ввести:
select * from <table>
в вашем программном обеспечении для управления базами данных?
Это очень надуманная причина, но на данный момент я не могу придумать ничего другого .
Нет, порядок столбцов в таблице базы данных SQL абсолютно не имеет значения - за исключением целей отображения / печати. Нет смысла переупорядочивать столбцы - большинство систем даже не предоставляют способ сделать это (кроме удаления старой таблицы и воссоздания ее с новым порядком столбцов).
Марк
РЕДАКТИРОВАТЬ: из статьи в Википедии о реляционных база данных, вот соответствующая часть, которая для меня ясно показывает, что порядок столбцов никогда не должен вызывать беспокойства:
Отношение определяется как набор из n кортежей. И в математике, и в модели реляционной базы данных набор представляет собой неупорядоченный набор элементов, хотя некоторые СУБД устанавливают порядок для своих данных. В математике кортеж имеет порядок и допускает дублирование. EF Кодд изначально определял кортежи, используя это математическое определение. Позднее Э. Ф. Кодд пришел к выводу, что использование имен атрибутов вместо упорядочивания было бы намного удобнее (в целом) в компьютерном языке, основанном на отношениях. Это понимание используется до сих пор.
Единственная причина, о которой я могу думать, это отладка и борьба с пожарами. У нас есть таблица, столбец «name» которой занимает 10-е место в списке. Больно, когда вы быстро выбираете * из таблицы, где id находится в (1,2,3), а затем вам нужно прокручивать страницу, чтобы посмотреть на имена.
Но это все.
Как это часто бывает, самым большим фактором является следующий человек, который должен работать с системой. Я стараюсь иметь сначала столбцы первичного ключа, затем столбцы внешнего ключа, а затем остальные столбцы в порядке убывания важности / значимости для системы.
Обычно при изменении порядка столбцов в среде Management Studio в SQL Server создается временная таблица с новой структурой, данные перемещаются в эту структуру из старой таблицы, удаляются старая таблица и переименовывает новую. Как вы могли догадаться, это очень плохой выбор с точки зрения производительности, если у вас большая таблица. Я не знаю, делает ли мой SQL то же самое, но это одна из причин, по которой многие из нас избегают переупорядочивания столбцов. Поскольку select * никогда не следует использовать в производственной системе, добавление столбцов в конце не является проблемой для хорошо спроектированной системы. Порядок столбцов в таблице не должен нарушаться.
Если вы собираетесь часто использовать UNION, сопоставление столбцов будет проще, если у вас есть соглашение об их упорядочивании.
Единственный раз, когда вам нужно беспокоиться о порядке столбцов, - это если ваше программное обеспечение специально полагается на этот порядок. Обычно это происходит из-за того, что разработчик поленился и сделал select * , а затем в своем результате ссылался на столбцы по индексу, а не по имени.
Как уже отмечалось, существует множество потенциальных проблем с производительностью. Однажды я работал с базой данных, где размещение очень больших столбцов в конце улучшало производительность, если вы не ссылались на эти столбцы в своем запросе. Очевидно, если запись занимала несколько дисковых блоков, ядро базы данных может прекратить чтение блоков, как только получит все необходимые столбцы.
Конечно, любые последствия для производительности сильно зависят не только от производителя, которого вы используете, но и, возможно, от версии. Несколько месяцев назад я заметил, что наш Postgres не может использовать индекс для сравнения «нравится». То есть, если вы написали «somecolumn like 'M%'», это было недостаточно умен, чтобы перейти к M и выйти, когда он нашел первую N. Я планировал изменить кучу запросов, чтобы использовать «между». Потом у нас появилась новая версия Postgres, и она грамотно справилась с подобными вещами. Рад, что мне так и не удалось изменить запросы. Очевидно, здесь это не имеет прямого отношения, но я хочу сказать, что все, что вы делаете из соображений эффективности, может устареть в следующей версии.
Порядок столбцов почти всегда очень важен для меня, потому что я обычно пишу общий код, который читает схему базы данных для создания экранов. Например, мои экраны «редактировать запись» почти всегда создаются путем чтения схемы для получения списка полей и последующего их отображения по порядку. Если бы я изменил порядок столбцов, моя программа по-прежнему работала бы, но отображение могло быть странным для пользователя. Например, вы ожидаете увидеть имя / адрес / город / штат / почтовый индекс, а не город / адрес / почтовый индекс / имя / штат. Конечно, я мог бы указать порядок отображения столбцов в коде, или контрольном файле, или чем-то еще, но тогда каждый раз, когда мы добавляли или удаляли столбец, нам приходилось не забывать обновлять контрольный файл. Я люблю что-то сказать один раз. Кроме того, когда экран редактирования построен исключительно на основе схемы, добавление новой таблицы может означать написание нулевых строк кода для создания экрана редактирования для нее, что неплохо. (Ну, ладно, на практике мне обычно приходится добавлять запись в меню, чтобы вызвать общую программу редактирования, и я вообще отказался от универсального «выбрать запись для обновления», потому что существует слишком много исключений, чтобы сделать это практичным .)