Префикс таблиц: Префикс таблиц базы данных (database table prefix)

Как изменить префикс базы данных

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

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

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

Чтобы изменить префикс БД вручную, надо сделать изменения в приложении phpMyAdmin при помощи SQL запросов, и изменить запись о префиксе в файле wp-config.php.

В плагинах безопасности префикс базы данных меняется в несколько кликов.

Содержание:

Зачем менять префикс базы данных
Аргумент Против
Аргументы За
Сделайте бэкап

1. Изменение префикса в базе данных
   • Изменение в wp-config.php
   • Изменения в базе данных
   • Изменения внутри таблиц
     • Записи в таблице Options
     • Записи в таблице Usermeta
     • Решение проблем
2. Плагины

Сделайте бэкап
Заключение

Зачем менять префикс базы данных

Многие специалисты рекомендуют изменить префикс БД для того, чтобы не дать возможность хакеру получить контроль над базой данных при помощи SQL запросов.

Существует 2 типа SQL внедрений. Обычное SQL внедрение — когда хакер получает возможность посылать команды базе данных и получать ответы от базы данных. Слепое SQL внедрение — когда хакер может посылать команды базе данных, но не получает ответов от нее.

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

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

Аргумент Против

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

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

Например, второй запрос может запрашивать имена, содержащие usermeta или postmeta в названии. Эти имена являются именами двух стандартных таблиц Вордпресс. Поиск вернет полное имя таблицы вместе с новым префиксом таблицы.

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

Аргументы За

Изменение префикса рекомендовано в руководстве по увеличению безопасности в Кодексе Вордпресс.

Эта рекомендация попала туда после устранения разработчиками Вордпресс уязвимостей, связанных с SQL внедрениями.

Причина в том, что хакеры редко ищут уязвимости сайтов, посещая сайты в браузере вручную. Хакеры создают ботов, которые автоматически обходят сотни или тысячи сайтов и ищут в них известные уязвимости по имеющимся у них спискам уязвимостей, которые находятся в открытом доступе.

После того, как на сайте находится уязвимость, например такая, которая позволяет выполнять SQL запросы злоумышленника, боты взламывают такие сайты, отправляют сообщение хакеру и идут дальше.

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

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

• Руководство по безопасности Вордпресс

Сделайте бэкап

Так как вы будете работать с глубокими настройками базы данных и файлом wp-config.php, сделайте бэкап всего сайта и базы данных. Если что-то пойдет не так, вы сможете восстановить сохраненную версию.

• Бэкап Вордпресс

1. Изменение в wp-config.php

Этот файл находится в корневой папке сайта, скачайте его на компьютер с помощью ftp-клиента или менеджера файлов на хостинге.

Откройте файл, найдите эту строку:

Измените wp_ на что-нибудь уникальное, но рекомендуется оставить нижнее подчеркивание в конце. Префикс может содержать цифры, буквы и знак подчеркивания, например, db14_, fr23br17_, a01_b01_ и так далее.

Сохраните файл и закачайте обратно на сервер. Если теперь вы попробуете зайти на сайт, он будет недоступен. Так и должно быть, потому что теперь данные в базе данных не соответствуют данным в файле wp-config.php.

Чтобы изменить префиксы в базе данных переходим к следующему шагу:

2. Изменения в базе данных

Зайдите на хостинг и откройте базу данных.

В базе данных нужно поменять префиксы главных таблиц, это делается с помощью SQL запросов на вкладке SQL. Структура запроса для изменения всех таблиц такая:

RENAME table `wp_название-таблицы` TO `новый-префикс_название-таблицы`;

Замените название-таблицы на нужное название таблицы, и новый-префикс на ваш новый префикс, который вы сохранили в файле wp-config.php.

1. Для одиночной установки Вордпресс измените префиксы в стандартных таблицах Вордпресс:

Можете скопировать и выполнить сразу все запросы, не забудьте заменить новый-префикс на ваш новый префикс.

2. Для мультисайт установки добавьте эти префиксы:

Измените новый-префикс на новый префикс.

Также измените эти таблицы:

wp_#_commentmeta
wp_#_comments
wp_#_links
wp_#_options
wp_#_postmeta
wp_#_posts
wp_#_terms
wp_#_term_relationships
wp_#_term_taxonomy

Замените # на ID вашего подсайта. Например, запрос к таблице wp_commentmeta подсайта с ID 2 будет wp_2_commentmeta

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

3. Изменения внутри таблиц

После того, как вы изменили названия таблиц, нужно изменить некоторые записи в таблицах options и usermeta.

Записи в таблице Options

В этой таблице надо изменить несколько записей. Для облегчения поиска можно использовать поисковый запрос. Замените новый-префикс на ваш новый префикс:

Поиск должен показать все записи, которые соответствуют запросу. Для редактирования кликните два раза или нажмите Карандаш на каждой записи.

Записи в таблице Usermeta

Как в таблице Options, в таблице Usermeta надо заменить несколько записей. Чтобы не искать их вручную, можно использовать запрос:

Замените новый-префикс на новый префикс, который вы добавили в wp-config.php.

После этого сайт должен начать работать с новым префиксом базы данных.

Решение проблем

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

Некоторые плагины предполагают, что префикс базы данных стандартный, и если вы уверены, что переименовали все таблицы и плагины, попробуйте деактивировать все плагины, и включать их по одному, чтобы найти, какой из них делает сайт недоступным. Удалите плагин или найдите ему альтернативу.

Плагины

Если вы не хотите делать это вручную, можно сделать это с помощью одного из плагинов безопасности. Вы можете использовать маленький плагин, который делает только эту работу, например, Brozzme DB Prefix, или большой плагин, где эта функция находится среди многих других, например All in One WordPress Security.

Перед изменением префикса сделайте бэкап сайта и базы данных.

Поставьте галочку, чтобы плагин сгенерировал новый префикс, или придумайте свой вариант. Плагин сделает изменения в базе данных и в файле wp-config.

Префикс базы данных изменен на xvi0f_. Изменены префиксы 34 таблиц и сделаны изменения в таблицах options и usermeta. Процесс такой же, как в ручном режиме, но занимает меньше секунды.

В других плагинах изменение префикса базы данных делается аналогично.

Сделайте бэкап

После того, как вы изменили префикс базы данных вручную или автоматически, сделайте еще один бэкап.

Заключение

Изменение префикса базы данных помогает избежать только один вид автоматических атак. Чтобы защитить сайт от других атак, установите какой-нибудь плагин безопасности и читайте Руководство по безопасности Вордпресс.

Читайте также:

• Подробное описание плагина Sucuri Security
• Как настроить мощную защиту сайта на основе бесплатного плагина Sucuri Security
• Подробное описание Security Ninja Pro

Надеюсь, статья была полезна. Оставляйте комментарии.

Управление префиксами таблиц — Windows drivers

Twitter LinkedIn Facebook Адрес электронной почты

• Статья
• 09/24/2022

RDBSS определяет структуры данных, которые позволяют использовать таблицы префиксов для каталогов SRV_CALL, NET_ROOT и имен V_NET_ROOT.

Текущая реализация управления именами в RDBSS использует таблицу со следующими компонентами:

• Очередь вставленных имен

• Метка версии

• Ресурс блокировки таблицы, управляющий доступом к таблицам

• Значение, указывающее, совпадает ли имя с именем без учета регистра

• Контейнер записей хэш-значений для этой таблицы префиксов

Ресурс блокировки таблицы используется обычным образом: Shared для операций уточняющего запроса, монопольно для операций изменения.

Отметка версии изменяется при каждом изменении. Причиной очереди является то, что пакет таблицы префиксов позволяет перечислять несколько вызывающих объектов за раз. Очередь вставленных имен и отметок версий позволяет перечислять несколько вызывающих объектов одновременно. Очередь может использоваться для ускорения поиска имен файлов, но таблица префиксов определенно подходит для структур NET_ROOT.

Эти префиксные подпрограммы управления таблицами используются внутри RDBSS в ответ на вызов из MUP для утверждения имени или для формирования пути создания для структуры NET_ROOT.

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

• Получить общую блокировку путем вызова рксаккуирепрефикстаблелоккшаред.

• Найдите имя, вызвав ркспрефикстаблелукупнаме.

• Освободите общую блокировку, вызвав рксрелеасепрефикстаблелокк.

обратите внимание, что некоторые подпрограммы реализуются только в Windows XP и предыдущих версиях Windows. Ркспрефикстаблелукупнаме — это единственная подпрограммы управления таблицами префиксов, реализованная во всех версиях Windows

К подпрограммым управления таблицами с префиксом RDBSS относятся следующие.

ркспаккуирепрефикстаблелоккексклусиве	Эта подпрограммы получает монопольную блокировку на таблицу префиксов, используемую для каталога SRV_CALL и имен NET_ROOT. эта подпрограммы доступна только в Windows XP и Windows 2000. Эта подпрограммы используется для внутренних целей RDBSS и не должна использоваться сетевыми мини-перенаправителями.
ркспаккуирепрефикстаблелоккшаред	Эта подпрограммы получает общую блокировку для таблицы префиксов, используемой для каталога SRV_CALL и имен NET_ROOT. эта подпрограммы доступна только в Windows XP и Windows 2000. Эта подпрограммы используется для внутренних целей RDBSS и не должна использоваться сетевыми мини-перенаправителями.
ркспрефикстаблелукупнаме	Процедура ищет имя в таблице префиксов, используемой для каталогизации SRV_CALL и NET_ROOT имен и преобразовывает базовый указатель на содержащую его структуру.
ркспрелеасепрефикстаблелокк	Эта подпрограммы снимает блокировку на таблицу префиксов, используемую для каталога SRV_CALL и имен NET_ROOT. эта подпрограммы доступна только в Windows XP и Windows 2000. Эта подпрограммы используется для внутренних целей RDBSS и не должна использоваться сетевыми мини-перенаправителями.

начиная с Windows Server 2003, подпрограммы, упомянутые в предыдущей таблице, за исключением ркспрефикстаблелукупнаме, заменяются макросами. Определяются следующие макросы, которые вызывают подпрограммы таблицы префиксов с меньшим числом параметров.

Рксаккуирепрефикстаблелоккексклусиве (Таблица, Ожидание)	Этот макрос запрашивает блокировку таблицы префиксов в монопольном режиме для операций изменения.
Рксаккуирепрефикстаблелоккшаред ( Таблица, Ожидание)	Этот макрос запрашивает блокировку таблицы префиксов в общем режиме для операций уточняющего запроса.
Рксиспрефикстаблелоккаккуиред (Таблица)	Этот макрос указывает, была ли блокировка таблицы префикса получена в монопольном или общем режиме.
Рксиспрефикстаблелоккексклусиве (Таблица)	Этот макрос указывает, была ли блокировка таблицы префикса получена в монопольном режиме.
Рксрелеасепрефикстаблелокк (Таблица)	Этот макрос освобождает блокировку префиксной таблицы.

mysql — Что такое префикс таблицы?

спросил 12 лет, 5 месяцев назад

Изменено 1 год, 1 месяц назад

Просмотрено 102 тысячи раз

Что такое префикс таблицы, каковы их преимущества и недостатки? Это что касается MySQL.

• MySQL
• база данных
• дизайн базы данных
• префикс

2

Часто используется, чтобы отличить разные установки одного и того же скрипта друг от друга. Например, предположим, что у вас есть две установки Joomla с разным содержимым на вашем сервере, но только одна база данных MySQL.

Теперь, по очевидным причинам, обе установки Joomla не могут совместно использовать одни и те же таблицы базы данных, так как в результате обе установки будут отображать одно и то же содержимое. И здесь в дело вступает префикс.

Используя различные префиксы таблиц, вы можете сообщить установке Joomla #1, что предполагается использовать всю таблицу с префиксом JOS_, а установке Joomla #2 следует использовать все таблицы с префиксом JOS2_

Таблицы не требуют префиксов.

Это зависит только от вас.

Однако мы ставим перед таблицами префикс, соответствующий МОДУЛЯМ в приложении, которому они принадлежат, просто для того, чтобы упростить группировку таблиц.

Некоторые люди поддерживают tbl или tbl_ (например, tbl_MyTable или tblMyTable), в то время как другие используют суффикс, такой как MyTable_T.

Лично я избегаю префиксов/суффиксов. Я могу заменить представление на таблицу, если схема меняется с течением времени, поэтому я не различаю два типа объектов.

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

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

Напр. t_user или t_order теперь возможны.

0

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

Вы часто видите префиксы таблиц в ситуациях, когда:

• Несколько сценариев объединяются вместе в один веб-сайт, и готовый веб-сайт должен обмениваться данными, но имена таблиц будут конфликтовать без префикса, уникального для каждого сценария.

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

• У вас есть план хостинга, который предоставляет вам только одну базу данных, и вы хотите использовать эту базу данных для обслуживания нескольких сценариев. (Это не рекомендуется по ряду причин, но я видел, как это делают пользователи.)

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

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

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

Однако не забудьте рассматривать префиксы таблиц как очень второстепенный уровень безопасности. Это НЕ должно быть вашим основным методом безопасности. Вам по-прежнему следует принимать другие более важные меры безопасности для предотвращения SQL-инъекций и других подобных угроз. Например, в зависимости от того, как настроен ваш код, хакер все еще может запустить команду «показать таблицы» с помощью SQL-инъекции, чтобы получить имена таблиц вашей базы данных.

6

Это может помочь различать таблицы и представления в зависимости от вашего соглашения об именах.

Недостатком является то, что вы можете быть ограничены в том, что касается имени таблицы. Oracle имеет для этого ограничение в 30 символов. Если вы используете «Tbl_» в качестве префикса, вы автоматически теряете 4 символа. Это может быть проблемой.

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

sql server.

Является ли добавление префикса «tbl» к именам таблиц действительно проблемой?

Задавать вопрос

спросил 6 лет, 6 месяцев назад

Изменено 1 год, 2 месяца назад

Просмотрено 41к раз

Я смотрю несколько видео Брента Озара (например, вот это), и он предлагает не ставить перед таблицами префикс ‘tbl’ или ‘TBL’ .

В Интернете я нашел несколько блогов, в которых говорилось, что это ничего не добавляет к документации, а также что «чтобы прочитать ее, требуется больше времени».

Вопросы и соображения

• Это действительно проблема? Поскольку я ставлю перед таблицами префикс «tbl» с момента моей первой работы с базой данных (старший администратор базы данных сказал мне сделать это для организации).
• Это то, от чего мне нужно избавиться? Я провел несколько тестов, скопировав очень большую таблицу и присвоив ей префикс «tbl», а другую оставил без него, и не заметил никаких проблем с производительностью.

• sql-сервер
• таблица
• лучшие практики
• соглашение об именах

5

Когда-то у меня был стол, и он был блестящим и красивым. Он проводил все финансовые операции для организации. И тогда мы начали загружать в него данные.

В текущем месяце они могут указывать и пересчитывать значения столько раз, сколько захотят. В последние 10 дней месяца они пересчитывали цифры -> запускали обработку ETL -> просматривали отчеты несколько раз в день. По завершении месяца книги запечатываются, и они не могут изменять значения.

Удивительно, сколько финансовых данных генерирует фирма, предоставляющая финансовые услуги… Что-то, чего мы не поняли с нашим тестовым набором данных, было то, что объем данных сделает их процедуры на конец месяца несостоятельными. Потребовалось все больше времени, чтобы удалить «данные за текущий месяц» перед заменой их новым пробным запуском.

Мы должны были сделать что-то, чтобы ускорить обработку, не нарушая некаталогизированный список «кто что знает», который все зависит от таблицы MonthlyAllocation. Я решил поиграть в фокусника и выдернуть из-под них скатерть. Я пошел по старой школе и использовал Partitioned View. У данных уже был флаг IsComplete, поэтому я создал две таблицы, каждая с противоположными проверочными ограничениями: MonthlyAllocationComplete, MonthlyAllocationInComplete

Затем я создал секционированное представление с тем же именем, что и исходная таблица: MonthlyAllocation. Ни один процесс не был мудрее физического изменения, которое мы внесли в базу данных. Ни один отчет не сломался, ни один из аналитиков с прямым доступом не сообщил о каких-либо проблемах с этой «таблицей» ни до, ни после.

Классная история, братан, но куда ты идешь?

Что, если бы у них было соглашение об именах, tbl_MonthlyAllocation? Что теперь? Тратим ли мы лот человеко-часов на проверку каждого ETL, каждого отчета, каждой специальной электронной таблицы в организации и обновление их для использования vw_MonthlyAllocation? И затем, конечно, все эти изменения проходят через доску изменений, и это всегда быстрый и безболезненный процесс.

Ваш босс может спросить: Какова награда компании за всю эту работу?

Другим вариантом является то, что мы оставляем это представление с именем tbl_ и не тратим все это время на тестирование, обновление и развертывание кода. Это становится забавным анекдотом, который вы объясняете всем новым сотрудникам и тем, у кого мало внимания, которым приходится работать с базой данных, почему вы не согласуетесь с именованием объектов

Или вы не дублируете объекты с избыточным кодированием метаданные. База данных с удовольствием расскажет вам, что такое таблица, что такое представление, что такое табличная функция и т. д.

Соглашения об именах хороши, просто не загоняйте себя в угол.

0

Брент здесь (парень, которого вы имеете в виду в вопросе).

Причина, по которой я советую вам не добавлять tbl перед именами ваших таблиц, — это та же причина, по которой я бы посоветовал не добавлять дочерний элемент перед именем вашего ребенка. Вы не называете их ЧайлдДжон и ЧайлдДжейн. Мало того, что это не добавляет никакой ценности, они могут перестать быть дочерними в более позднем возрасте, а ваши объекты могут позже стать представлениями.

0

Это очень субъективный аргумент, но вот мое мнение: префикс tbl бесполезен.

Сколько сценариев вы просматриваете в коде и не можете сказать, является ли это таблицей или чем-то еще?

Какое значение добавляет tbl, за исключением того, что когда вы просматриваете список таблиц в обозревателе объектов, вам нужно проделать больше работы, чтобы найти те, которые вы ищете?

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

1

Это ужасная практика.

 табл.
таблица_
Стол_
т_
 

… видел их всех в производстве.

Один из продуктов, с которым я сейчас работаю, имеет половину таблиц с именем tbl_whatever , а другую половину с именем «нормально». Очевидно, у них есть разработчики, которые работают по другим стандартам. Еще одна их плохая привычка — ставить перед именами столбцов, которые являются внешними ключами, префикс 9.0115 fk , за которым следует имя таблицы, fk , затем имя столбца, что дает такие ужасные имена столбцов, как fktbl_AlarmsfkAlarmsID . Это соглашение об именах является просто логическим продолжением всей мантры tbl_% , и вы можете видеть, насколько это смешно!

Я почти забыл о другой базе данных, которая заставляет меня плакать каждый день. Типы данных с префиксом в именах столбцов… dtPaymentDate , потому что имя действительно нуждалось в префиксе dt ?`

1

comНе веритьПодготовка к прил. Те прил.Другие люди. proYou auxShould advAlways verUse nouPrefixes prep With proYour adjTable nouNames. proI auxHave advEven verStarted gerUse proThem prepIn adjNormal NouWriting.

comSee advКак adjЭффективная прибыль verIs? nouPeople auxCan verПонять про Ваш nouНаписание adjBetter!

1

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

Вообще говоря, этот стиль именования, скорее всего, будет использоваться в очень старом коде или разработчиками, которые либо только учатся (и случайно усвоили эту привычку), либо делали это столько, сколько себя помнят. По своему опыту я заметил, что относительно редко можно увидеть, как венгерская нотация спонтанно возникает у неопытных разработчиков, если они не знакомятся с ней на курсах программирования или в учебных пособиях; они, скорее всего, будут использовать имена переменных, такие как i или х или счет .

Помимо закрашивания самого себя в угол, это всего лишь наполнитель. Синтаксис SQL достаточно точен, поэтому разработчик всегда должен знать, если он говорит о поле, записи или наборе данных (который может быть таблицей, представлением и т. д.). Хотя это может быть отличным учебным пособием, этот синтаксис обычно не должен существовать в производственных базах данных. Это может повредить читаемости и затруднить поиск нужной таблицы, особенно если всплывает несколько альтернативных тем именования, например 9.0161 tbl vs. table vs. tab и т. д.

Базе данных на самом деле все равно как вы называете свои таблицы, поля и т. д. Это просто байты данных, которые расположены в определенном порядке. заказ их человеческими операторами или сценариями. Однако люди, которые должны поддерживать эти данные, оценят осмысленные имена, такие как «пользователь», «заказ» и «учетная запись». Это также более практично, если вы используете SQL-запросы, например «показать таблицу, например, ‘a%’». Использование префиксов и суффиксов может излишне усложнить тривиальную поддержку.

2

Я прочитал несколько сообщений в блоге, подобных этому или этому (их довольно много), после того, как я унаследовал свой первый экземпляр SQL Server и заметил, что многие объекты имеют префиксы, я хотел начать разработку новых с менее подробным подходом и единственным именем соглашение (мне намного проще [ и, возможно, другим разработчикам ] работать над объектно-реляционным сопоставлением).

Одним из наиболее широко используемых префиксов был Tbl или tbl , но тогда у меня были TBL и tbl_ и даже *TableName*_Tbl

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

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

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

Да, добавить префикс, обозначающий тип объекта, проблематично, да и не нужно . Потому что,

1. Иногда объекты начинают жизнь как нечто, но в конечном итоге становятся чем-то другим. (например, таблица tblXxx была разделена на tblXxxY и tblXxxZ почему-то заменены представлением, объединяющим две новые таблицы. Теперь у вас есть представление с именем tblXxx ).
2. Когда вы вводите tbl в редакторе, его функция автозаполнения зависает на 45 секунд, а затем показывает вам список из 4000 записей.

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

У нас есть ERP-система на основе сущностей, бизнес-логика которой написана на Oracle PL/SQL. Этой системе почти два десятилетия, но она очень стабильна (это не устаревшая система. Мы постоянно ее развиваем).

Система основана на сущности, и каждая сущность связана с таблицей, несколькими представлениями, несколькими пакетами PL/SQL и множеством других объектов базы данных.

Теперь мы хотим, чтобы объекты, принадлежащие одному и тому же объекту, имели одно и то же имя, но чтобы их можно было различить по назначению и типу. Итак, если у нас есть две сущности с именем CustomerOrder и CustomerInvoice у нас будут следующие объекты:

1. Таблицы для хранения данных [ TAB suffix]:
   • ВКЛАДКА ЗАКАЗА_ЗАКАЗА
   • ЗАКАЗЧИК_INVOICE_TAB .
2. Представления, используемые клиентами [без суффикса]:
   • ЗАКАЗ ЗАКАЗЧИКА
   • ЗАКАЗЧИК_СЧЕТ .
3. Интерфейс для основных операций; (пакеты PL/SQL) [ API суффикс]:
   • КЛИЕНТ_ЗАКАЗ_API
   • CUSTOMER_INVOICE_API .
4. Генераторы отчетов; (пакеты PL/SQL) [суффикс RPI ]:
   • ЗАКАЗ ЗАКАЗЧИКА
   • CUSTOMER_INVOICE_RPI .
5. Индексы для первичных ключей [ суффикс PK ]:
   • ЗАКАЗ_ЗАКАЗА_ПК
   • CUSTOMER_INVOICE_PK .
6. Вторичные индексы [суффикс IX ]:
   • ЗАКАЗ_ЗАКАЗА_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX (где XXX описывает использование индекса).
7. … и так далее.

Это действительно форма венгерского языка приложений (обратите внимание, что один и тот же тип объектов может иметь разные суффиксы в зависимости от цели). Но с суффиксом вместо префикса. Я не могу рассказать вам достаточно, как эта система так легко читается. IntelliSense на самом деле работает, потому что вместо ввода TBL и получив 4000 результатов, я могу ввести Customer и получить все объекты, принадлежащие сущностям с именем Customer* .

Итак, здесь я показал вам, как метаданные могут быть полезны. Цель состоит в том, чтобы иметь связанный набор объектов базы данных, идентифицируемых одним именем, но различать их в зависимости от их назначения .

Сказав это, если у вас нет такой системы, нет смысла ни префикса, ни суффикса тип объекта .

Обратите внимание, что мы не использовали такие суффиксы, как _table , _package или _view (т.е. тип объекта). Например, и (3), и (4) являются пакетами PL/SQL, но используют разные суффиксы. То же самое для (5) и (6), оба из которых являются индексами. Таким образом, суффикс основан на назначении , а не на типе .

1

tl;dr Он (весьма вероятно) добавляет избыточную информацию, приводя к когнитивным издержкам, и поэтому его следует удалить.

Контекст — замечательная штука, особенно в компьютерных системах. Вне контекста вы не могли бы сказать, является ли что-то под названием пользователей таблицей, представлением, хранимой процедурой или чем-то совершенно другим. Устаревшие (или просто плохо написанные) системы и языки часто затрудняют работу с контекстом при чтении кода. Например, в Bash вы не можете сказать, что пользователи функции делают без хотя бы чтения содержимого функции. На Яве Map users() довольно прозрачен, и вы можете легко докопаться до деталей.

Принимая этот аргумент к таблицам SQL, когда было бы полезно потребителям пользователей знать, таблица это или представление? Другими словами, — это префикс tbl , который расскажет любому потребителю то, чего он не знает, а и должны знать? Будем надеяться, что подавляющее большинство потребителей будут писать к нему DML- и DQL-запросы. Для них это должен быть просто еще один источник данных, и независимо от того, представление это или таблица, должно быть примерно так же важно, как то, разбито ли оно на разделы, хранится на жестком диске или твердотельном накопителе или любая другая техническая деталь. Конечно, администратор базы данных должен знать эти детали, чтобы запускать некоторые редкие запросы DDL/DCL, но представляется контрпродуктивным загрязнять пространство имен ради меньшинства, которое действительно знает, как перемещаться по схеме и получать все технические детали.

0

Одной из особенностей системы управления реляционной базой данных является то, что она отделяет логическое представление информации для клиентов от физического хранилища. Первый — это столбцы в наборе строк. Последний находится в виде файлов на томе хранилища. Задача СУБД — сопоставить одно с другим. Только администратора баз данных или системного администратора должно волновать, какое аппаратное обеспечение поддерживает потребность в информации. Потребитель не должен, действительно не должен знать об этих опасениях.

Клиент также не должен беспокоиться о том, как создается набор строк. Базовая таблица, представление или функция в этом отношении идентичны. Каждый просто создает набор строк и столбцов, которые использует клиент. Даже простой скаляр можно рассматривать как таблицу с одной строкой и одним столбцом. Модель строки/столбца — это контракт между клиентом и сервером.

При добавлении к именам артефактов префикса их типа реализации это разделение задач нарушается. Клиент теперь осведомлен о внутренних компонентах сервера и зависит от них. Изменение кодировки сервера может потребовать доработки клиента.

Этот вопрос обсуждался много раз, но, вероятно, наиболее известен Джо Селко, американским экспертом по SQL и реляционным базам данных. Я лично был на стороне получателя одной из его тирад в Интернете (чувствовал себя польщенным), и он говорит об этих префиксах как о «тиблинге», или, точнее, о «скевоморфизме».

Общая идея состоит в том, что эти префиксы являются давней практикой кодирования (вероятно, из-за ограничений именования, таких как ограничение в 8 байтов для имен объектов), которые передавались поколениями программистов без какой-либо явно полезной причины, кроме того, что это просто » как это делается».

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

Со временем вещи остаются, даже если причина, по которой они использовались изначально, теперь устарела. «Тибблинг» — один из самых известных примеров этого в управлении реляционными базами данных.

Чтобы округлить: он не добавляет никакого значения, он добавляет ровно 4 байта дискового пространства к каждому имени таблицы ни по какой причине, кроме как потому, что оно там. Он ничего не предлагает современным системам SQL Server, но если вам от этого станет легче, используйте его.

4

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

---

 ВЫБЕРИТЕ
  бар
  , шипение
  , гул
ИЗ dbo.foo
 

В приведенном выше выражении я выбираю три столбца из чего-то с именем dbo.foo . Одна из основных претензий к префиксам заключается в том, что они не знают, dbo.foo — это таблица или представление. Конечно, это одна из сильных сторон представления как абстракции, но я отвлекся. Они говорят, что мы должны префикс объекта, как это dbo.tblFoo . Теперь они могут видеть, что объект является таблицей (вероятно) в приведенном выше запросе. Однако если мы напишем функциональный эквивалент этой цели, он будет выглядеть так.

 ВЫБОР
  бар
  , шипение
  , гул
ИЗ dbo. Foo --table
 

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

 ВЫБОР
  qc.события
  , i.employeeId
  , q.questionText
FROM dbo.questionCount /*Индексированное представление*/ qc WITH (NOEXPAND)
  ВНУТРЕННЕЕ СОЕДИНЕНИЕ dbo.interviewer /*разделенное представление*/ i ON i.employeeId = qc.interviewerId
  ВНУТРЕННЕЕ СОЕДИНЕНИЕ dbo.question /*table*/ q ON q.id = qc.questionId
ГДЕ
  СУЩЕСТВУЕТ (
           ВЫБИРАТЬ
             1
           ОТ dbo.currentEmployees /*view*/ ce
             ВНУТРЕННЕЕ СОЕДИНЕНИЕ dbo.questionsAsked /*table*/ qa ON qa.candidateId = ce.candidateId
           ГДЕ
             ce.employeeId = i.employeeId
             И
             qa.questionId = q.id
         )
  И
  qc.вхождения > 5;
 

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

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

Я бы посоветовал вам немедленно прекратить это делать. Если вам неудобно двигаться дальше, добавьте «_tbl» к конец имен ваших таблиц. Конечно, по уже упомянутым причинам в этом тоже нет необходимости. Человек, который первоначально сказал вам сделать это, дал вам плохой совет. Возможно, это был плохой совет «это имеет смысл с точки зрения плохо настроенной системы нашей организации», но в этом случае его работа заключалась в том, чтобы исправить это. Еще плохой совет.

1

Действительно ли проблема в том, что «Не добавляйте к таблицам префикс tbl»?

Что касается системы? Нет. Относительно других людей? Может быть. Вы можете породить много ненависти.

Лично я не добавляю префикс к таблицам, но делаю это для других объектов, таких как представления, хранимые процедуры, функции и т. д.

Я должен сказать, пожалуйста, прекратите это делать. Это случалось в прошлом, но, продолжая делать это, вы поощряете новых людей, которые приходят в ваше окружение, думать, что это местная условность, и продолжать. Но они не просто продолжат, они сделают это немного по-другому

При просмотре базы данных в поисках определенного элемента, а я не единственный, кто открывает проводник объектов и просто думает, что прокрутит до него, вы знаете, что он в алфавитном порядке. То есть до тех пор, пока префиксы не начнут мутить воду, и у меня есть tblname, tbl_name, tbname, t_name и тысяча других вариаций, становится очень трудно найти ту таблицу, которая, как вы знаете, уже является таблицей

Аналогичным образом префикс всего vw_ или sp_, кто-то войдет, и вы получите SPname, spname, s_p_name. Удалите все префиксы, программное обеспечение знает, что это за элемент, если вам действительно нужно знать, используйте вместо этого суффикс. NameOfMyView_v, NameOfMyProc_sp. намного проще искать визуально

Но что, если вы просматриваете долго хранящийся процесс и не можете легко определить, что такое представление: процесс или таблица? Скорее всего, они все равно будут иметь псевдонимы, и даже если суффикс не придет вам на помощь

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

У каждой стороны есть свои преимущества и недостатки. Только руководство вашей команды или компании может принять решение о том, какие соглашения следует соблюдать.

Мы, например, используем соглашение tbl . Основная причина в том, что мы знаем в сценариях, что мы можем и не должны делать. У нас есть разные проекты и люди, которые прыгают, не зная схемы наизусть. Наши таблицы имеют логические имена, поэтому при написании скриптов легко ориентироваться. При этом, когда мы находим таблицу, мы сразу знаем (через IntelliSense), что это таблица. Можно возразить, что добавление префикса не добавляет особого контекста. Однако его удаление означает отсутствие контекста.

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

В конце концов, все сводится к тому, что предпочитает ваша команда и как она пишет код/скрипты.

1

Рассмотрим dbo.User против dbo.tUser . Теперь представьте, что вы хотите найти все места в коде, где используется эта таблица. Какая версия делает это проще (или даже возможно?) Слово «пользователь», вероятно, будет иметь много ложных срабатываний, таких как имена переменных, комментарии и т. Д.

Это то, чего я не видел ни в одном из других ответов. , но я разработчик и администратор баз данных, поэтому, возможно, другим не приходилось работать с устаревшим кодом, где запросы могут быть встроены в приложение, и не все запросы полностью определяют ссылки со схемой и тому подобное. (Даже если все полноценные, нужно найти dbo.User и [dbo].[User] и dbo.[User] и так далее). Или версии базы данных, где «информация о зависимостях» устарела и является неточной (например, более старые версии MS-SQL)

Итак, в некоторых проектах, над которыми я работал, которые смешаны таким образом, я указал t или v Префикс (tbl_ становится глупым), просто чтобы сделать его более избирательным поисковым термином.

В более поздних проектах с такими вещами, как SQL Server Data Tools (привет, найти все ссылки) и доступом к базе данных исключительно через уровень ORM, нет никакой полезности, потому что поиск всех использований таблицы тривиален (как и ее переименование! )

1

Если мне нужно подумать о преимуществе наличия префикса «tbl», то в текущей SSMS с intellisense я могу просто ввести

 select * from tbl
 

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

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