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

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

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

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

  • Это действительно проблема? . Поскольку Iâ € ™ m prefixing tables с â € ~tblâ € ™ с моей первой работы dba (старший администратор базы данных сказал мне сделать это для организации).
  • Это что-то, от чего мне нужно избавиться? Я провел несколько тестов, скопировав действительно большую таблицу и дав ей префикс â € ~tbl, оставив без нее другой, и я не заметили каких-либо проблем с производительностью.
84 голоса | спросил Racer SQL 4 52016vEurope/Moscow11bEurope/MoscowFri, 04 Nov 2016 15:13:14 +0300 2016, 15:13:14

19 ответов


204

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

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

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

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

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

Прохладный рассказ, но куда вы идете?

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

Вы, босс, можете спросить: какая награда для компании за все, что работает снова?

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

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

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

ответил billinkc 4 52016vEurope/Moscow11bEurope/MoscowFri, 04 Nov 2016 16:41:06 +0300 2016, 16:41:06
121

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

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

ответил Brent Ozar 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 17:42:40 +0300 2016, 17:42:40
114

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

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

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

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

ответил Aaron Bertrand 4 52016vEurope/Moscow11bEurope/MoscowFri, 04 Nov 2016 16:06:59 +0300 2016, 16:06:59
38

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

tbl
tbl_
Table_
t_

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

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

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

ответил Philᵀᴹ 4 52016vEurope/Moscow11bEurope/MoscowFri, 04 Nov 2016 16:35:33 +0300 2016, 16:35:33
16

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

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

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

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

ответил phyrfox 4 52016vEurope/Moscow11bEurope/MoscowFri, 04 Nov 2016 20:17:37 +0300 2016, 20:17:37
11

comDon't verListen prepTo adjThose adjOther nouPeople. proYou auxShould advAlways verUse nouPrefixes prepWith proYour adjTable nouNames. proI auxHave advEven verStarted gerUsing proThem prepIn adjNormal nouWriting.

comSee advHow adjEffective proIt verIs? nouPeople auxCan verUnderstand proYour nouWriting adjBetter!

ответил ErikE 10 42016vEurope/Moscow11bEurope/MoscowThu, 10 Nov 2016 03:29:02 +0300 2016, 03:29:02
8

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

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

 введите описание изображения здесь>> </a> </p>

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

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

<p> ... С другой стороны, я просто хотел сказать, что если вы примете другой подход и перейдете к таблице без имени, вы получите счастливого разработчика в будущем, и что более важно, чем счастье? </p></body></html>

ответил Nelson Casanova 4 52016vEurope/Moscow11bEurope/MoscowFri, 04 Nov 2016 15:34:10 +0300 2016, 15:34:10
8

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

Но ...

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

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

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

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

  1. Таблицы для хранения данных [TAB суффикс]:
    • CUSTOMER_ORDER_TAB
    • CUSTOMER_INVOICE_TAB.
  2. Виды, используемые клиентами [Нет суффикса]:
    • CUSTOMER_ORDER
    • CUSTOMER_INVOICE.
  3. Интерфейс для основных операций; (Пакеты PL /SQL) [API суффикс]:
    • CUSTOMER_ORDER_API
    • CUSTOMER_INVOICE_API.
  4. Генераторы отчетов; (Пакеты PL /SQL) [RPI суффикс]:
    • CUSTOMER_ORDER_RPI
    • CUSTOMER_INVOICE_RPI.
  5. Индексы для первичных ключей [PK суффикс]:
    • CUSTOMER_ORDER_PK
    • CUSTOMER_INVOICE_PK.
  6. Вторичные индексы [IX суффикс]:
    • CUSTOMER_ORDER_XXX_IX
    • CUSTOMER_INVOICE_XXX_IX (где XXX описывает использование индекса).
  7. ... и т. д.

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

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

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

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

ответил Krumia 8 22016vEurope/Moscow11bEurope/MoscowTue, 08 Nov 2016 08:20:51 +0300 2016, 08:20:51
6

Это было рассмотрено много раз, но, вероятно, наиболее знаменито Joe Celko , американский SQL и эксперт по реляционной базе данных. Я лично принимал участие в одном из своих онлайн-опросов (считался почетным), и он говорит об этих префиксах как «тиблинг» или более точно описывается как « skeuomorphism ".

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

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

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

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

ответил John Bell 4 52016vEurope/Moscow11bEurope/MoscowFri, 04 Nov 2016 19:39:30 +0300 2016, 19:39:30
6

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

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

Принимая этот аргумент в таблицах SQL, , когда было бы полезно для потребителей Map<Uid,UserDetails> users() знать, является ли это таблицей или представлением? Другими словами, является префиксом users, который будет сообщать любому из потребителей то, что они не знают и , чтобы знать? . Надеюсь, что обширный большинство потребителей будут писать DML и DQL-запросы против него. Для них это должен быть просто еще один источник данных, а также то, является ли это представлением или таблицей, примерно такой же актуальной, как и ее разделение, хранение на жестком диске или SSD или любая другая техническая информация. Разумеется, DBA должен знать эти детали, чтобы запускать некоторые редкие запросы DDL /DCL, но кажется контрпродуктивным загрязнять пространство имен ради меньшинства, которое действительно знает, как перемещаться по схеме и получать все технические детали.

ответил l0b0 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 11:48:22 +0300 2016, 11:48:22
6

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

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

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

ответил Michael Green 9 32016vEurope/Moscow11bEurope/MoscowWed, 09 Nov 2016 05:07:03 +0300 2016, 05:07:03
6

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


SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

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

SELECT
  bar
  , fizz
  , buzz
FROM dbo.Foo --table

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

SELECT
  qc.occurances
  , i.employeeId
  , q.questionText
FROM dbo.questionCount /*Indexed view*/ qc WITH (NOEXPAND)
  INNER JOIN dbo.interviewer /*partitioned view*/ i ON i.employeeId = qc.interviewerId
  INNER JOIN dbo.question /*table*/ q ON q.id = qc.questionId
WHERE
  EXISTS (
           SELECT 
             1 
           FROM dbo.currentEmployees /*view*/ ce 
             INNER JOIN dbo.questionsAsked /*table*/ qa ON qa.candidateId = ce.candidateId
           WHERE
             ce.employeeId = i.employeeId
             AND
             qa.questionId = q.id
         )
  AND
  qc.occurances > 5;

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

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

ответил Erik 9 32016vEurope/Moscow11bEurope/MoscowWed, 09 Nov 2016 04:22:30 +0300 2016, 04:22:30
3

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

ответил user3131341 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 18:51:17 +0300 2016, 18:51:17
1
  

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

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

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

ответил Joe 4 52016vEurope/Moscow11bEurope/MoscowFri, 04 Nov 2016 18:06:23 +0300 2016, 18:06:23
0

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

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

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

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

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

ответил cockbeard 10 42016vEurope/Moscow11bEurope/MoscowThu, 10 Nov 2016 17:08:32 +0300 2016, 17:08:32
-2

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

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

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

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

ответил Mark Sowul 13 72016vEurope/Moscow11bEurope/MoscowSun, 13 Nov 2016 20:53:03 +0300 2016, 20:53:03
-3

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

select * from tbl

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

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

Я помню, что в SQL Server 2005 дней было требование найти, какие таблицы используются, в каких хранимых процедурах /представлениях, с префиксом таблиц, это была такая легкая работа с Regular Expression /C #. (Да, я знаю, что есть другие способы, никаких аргументов здесь).

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

ответил jyao 8 22016vEurope/Moscow11bEurope/MoscowTue, 08 Nov 2016 20:45:33 +0300 2016, 20:45:33
-4

У каждой стороны есть свои преимущества и недостатки. Itâ € ™ s только до команды вашей компании или компании, чтобы принять решение о последующих соглашениях.

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

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

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

ответил Kevin V 5 62016vEurope/Moscow11bEurope/MoscowSat, 05 Nov 2016 11:41:28 +0300 2016, 11:41:28
-12

Раньше у меня была причина префиксных имен таблиц с «tbl». Если вы просматриваете список объектов базы данных, вы можете запустить этот запрос:

select * from sysobjects

Если вы хотите получить только таблицы, вы можете сделать это:

select * from sysobjects where type = 'U'

Кто это помнит? Если имена ваших таблиц начинаются с «tbl», вы можете использовать этот запрос, который не требует запоминания значений столбца типа:

select * from sysobjects where name like 'tbl%'

Поскольку вы отметили SQL Server 2014, это не относится к вам, поскольку с SQL Server 2005 вы можете сделать это:

select * from sys.tables

Я не могу придумать другую причину префикса имен таблиц.

ответил user2023861 4 52016vEurope/Moscow11bEurope/MoscowFri, 04 Nov 2016 17:42:18 +0300 2016, 17:42:18

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

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

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