Я переглядаю деякі відео Brent Ozar ( наприклад, це, наприклад ), і він пропонує не встановлювати префіксацію таблиць з ‘tbl’або ‘TBL’.

В Інтернеті я знайшов кілька блогів, в яких говорилося, що це нічого не додає до документації, а також, що "для читання потрібно більше часу".

Питання та міркування

• Це справді проблема? Тому що я встановлюю таблиці "tbl" з моєї першої роботи на dba (старший DBA сказав мені зробити це для організації).
• Це щось, що мені потрібно позбутися? Я зробив декілька тестів, скопіювавши дійсно велику таблицю і дав їй префікс 'tbl', а інший залишив без нього, і я не помітив жодної проблеми з продуктивністю.

У мене колись був стіл, і він був блискучим і красивим. Він проводив усі фінансові операції для організації. І тоді ми почали завантажувати в нього дані.

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

Дивовижно, скільки фінансових даних генерує фірма з фінансових послуг ... Щось, що ми не усвідомлювали, використовуючи наш тестовий набір даних, - це обсяг даних, який зробить процедуру закінчення місяця невідмінною. Щоб видалити "дані поточного місяця", перш ніж замінити його новим пробним циклом, знадобилося дедалі довше.

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

Потім я створив перегляд з розділеними частинами з тим самим іменем, що і початкова таблиця: MonthlyAllocation. Жоден розумний процес щодо фізичних змін, які ми внесли до бази даних. Жоден звіт не зламався, жоден з аналітиків, що мають прямий доступ, не повідомляв про проблеми із цією «таблицею» до або після.

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

Що робити, якщо вони мали там угоду про іменування, tbl_MonthlyAllocation? А тепер що? Чи проводимо ми багато годин, переглядаючи кожен ETL, кожен звіт, кожну спеціальну електронну таблицю в організації та оновлюючи їх для використання vw_MonthlyAllocation? І тоді, звичайно, всі ці зміни проходять через Раду змін, і це завжди швидкий і безболісний процес.

У вас бос може запитати: яка винагорода компанії за все, що працює знову?

Іншим варіантом стає, що ми залишаємо цей погляд названий як tbl_ і не витрачаємо весь цей час на тестування, оновлення та розгортання коду. Що стає кумедним анекдотом, ви пояснюєте всім новим найманим працівникам та тим, хто має невеликі проміжки уваги, які повинні працювати з базою даних щодо того, чому ви суперечать іменуванню об'єктів

Або ви не подвоюєте кодування об'єктів із зайвими метаданими. База даних з радістю підкаже вам, що таке таблиця, що таке перегляд, що таке функція, яка оцінюється за таблицею тощо.

Конвенції про іменування добре, просто не малюйте себе в куточку з ними.

Brent тут (хлопець, про якого ви посилаєтесь у питанні).

Причина, по якій я кажу вам не додавати tbl до передньої частини імен вашої таблиці, - це та сама причина, яку я б сказав, щоб не додавати дитину до передньої частини імені вашої дитини. Ви їх не називаєте childJohn та childJane. Мало того, що це не додає ніякої цінності, вони можуть не бути дитиною в подальшому житті - і ваші предмети згодом можуть перетворитись у види.

Це дуже суб'єктивний аргумент, але ось моя думка: префікс tbl марний.

Скільки сценаріїв ви переглядаєте код, і ви не можете сказати, чи є щось столом чи чимось іншим?

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

Деякі люди кажуть, що хочуть, щоб це було чітко в коді, коли вони мають справу з таблицею або видом. Чому? І якщо це важливо, чому б не по-особливому назвати погляди ? У більшості випадків вони діють так само, як таблиці, тому я бачу невелику цінність у розрізненні.

Це жахлива практика.

tbl
tbl_
Table_
t_

... бачив їх усіх у виробництві.

Один з продуктів, з якими я зараз працюю, має половину названих таблиць tbl_whatever, а іншу половину назвав "нормально" - Вони, очевидно, мають розробників, які працюють за різними стандартами. Ще один з їх поганих звичок префіксів імен стовпців , які є зовнішніми ключами з fk, а потім по імені таблиці, fkто ім'я стовпця, даючи такі жахливі імена стовпців як fktbl_AlarmsfkAlarmsID. Ця умова іменування - це лише логічне продовження всієї tbl_%мантри, і ви можете бачити, наскільки смішним це стає!

Я майже забув про іншу базу даних, яка змушує мене плакати щодня. Префіксація назв стовпців даних dtPaymentDate, тому що ім'я справді потребувало dtпрефікса? `

com Не вершить prepTo adjTho adjOther nouPeople. proYou auxShould advAlways verUse nouPrefixes prepWith proYour adjTable nouNames. proI auxHave advEven verStarted gerUsing proThem prepIn adjNormal nouWriting.

comSee adv How adjEffective proIt veriss? nouPeople auxCan verUnderstand proYour nouWinging adjBetter!

Використання такого префікса відоме як Угорська нотація . Це передумова проста: ви можете визначити, що щось таке, як він названий. Це особливо часто зустрічається в мовах програмування, особливо коли розробники пишуть монолітні функції, що охоплюють десятки сторінок, або через недостатню майстерність або відсутність мовних особливостей. Це мнемонічна допомога, яка допомагає розробникам підтримувати прямі типи даних.

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

Крім фарбування себе в куточку, це справді просто наповнювач. Синтаксис SQL досить точний, що розробник повинен завжди знати, чи вони говорять про поле, запис чи набір даних (це може бути таблиця, подання тощо). Хоча це може стати чудовим навчальним посібником, цей синтаксис зазвичай не повинен існувати у виробничих базах даних. Це може зашкодити розбірливості та ускладнити пошук потрібної таблиці, особливо якщо з'явиться кілька альтернативних тем імен, наприклад, tbl проти таблиці проти вкладки тощо.

Базі даних не дуже важливо, як ви називаєте ваші таблиці, поля тощо. Вони є лише байтами даних, які впорядковані в певному порядку їх людськими операторами або сценаріями. Однак люди, яким потрібно підтримувати ці дані, оцінять такі значущі імена, як "користувач", "замовлення" та "рахунок". Це також більш практично, якщо ви використовуєте SQL-запити, наприклад "показати таблицю типу" a% "". Використання префіксів і суфіксів може зайвим чином ускладнити тривіальне дотримання.

Я прочитав кілька таких публікацій на блозі, як це чи це (їх досить багато) після того, як я успадкував свій перший екземпляр 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суфікс]:
   • 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. ... і так далі.

Це дійсно форма угорської програми (зауважте, що один і той же тип об'єктів може мати різні суфікси залежно від призначення). Але, із суфіксом замість префікса. Я не можу сказати тобі, як цю систему так легко читати. IntelliSense насправді працює, тому що замість того, щоб вводити TBLта отримувати 4000 результатів, я можу набрати Customerта отримати всі об’єкти, що належать названим особам Customer*.

Отже, тут я показав вам, як метадані можуть бути корисними. Мета полягає в тому, щоб мати пов'язаний набір об'єктів бази даних, ідентифікованих одним іменем, але при цьому диференціювати їх залежно від їх призначення .

Сказавши, що, якщо у вас немає такої системи, не застосовується ні префіксація, ні суфіксація типу об’єкта .

Зверніть увагу , що ми не використали суфікси , як _table, _packageабо _view(тобто тип об'єкта). Наприклад, обидва (3) і (4) є PL / SQL-пакетами, але використовують інший суфікс. Це те саме для (5) і (6), що обоє є індексами. Тож суфікс базується на призначенні, а не на типі .

tl; dr Це (дуже ймовірно) додає зайву інформацію, що призводить до когнітивних накладних витрат, і тому її слід видалити.

Контекст - це чудова річ, особливо в комп'ютерних системах. Поза межами контексту ви не можете сказати, чи є щось, що називається users- це таблиця, представлення даних, збережена процедура чи щось інше цілком. Спадкові (або просто погано написані) системи та мови часто ускладнюють опрацювання контексту під час читання коду. Наприклад, у Bash ви не можете сказати, що function usersробить, хоча б не прочитавши вміст функції. У Java Map<Uid,UserDetails> users()досить прозора, і ви можете легко перекопатись до деталей.

Взявши цей аргумент у таблиці SQL, коли споживачам було б корисно usersзнати, чи це таблиця, чи вид? Іншими словами, чи буде tblпрефікс сказати комусь із споживачів те, чого вони не знають і потрібно знати?Сподіваємось, переважна більшість споживачів буде писати проти нього запити DML та DQL. Для них це має бути лише інше джерело даних, і чи це перегляд, чи таблиця, має бути настільки ж релевантним, як і розділення, збереження на жорсткому диску або SSD або будь-які інші технічні деталі. DBA, звичайно, повинен знати ці деталі для запуску деяких рідкісних запитів DDL / DCL, але видається контрпродуктивним забруднення простору імен заради меншості, яка насправді знає, як орієнтуватися на схемі та отримати всі технічні деталі.

Однією з особливостей системи управління реляційними базами даних є те, що вона відокремлює логічне представлення інформації клієнтам від фізичного зберігання. Перший - це стовпці в наборі рядів. Останнє - це файли на об'ємі пам’яті. Завдання СУБД - зіставити одне до іншого. Це стосується лише DBA або sysadmin, яке обладнання підтримує необхідну інформацію. Справді споживач не повинен знати про ці проблеми.

Клієнт також не повинен перейматися тим, як побудований набір рядків. Базова таблиця, вид або функція в цьому відношенні однакові. Кожен просто створює набір рядків і стовпців, які споживає клієнт. Навіть простим скаляром можна вважати однорядну одноколонну таблицю. Модель рядка / стовпця - це договір між клієнтом і сервером.

За допомогою префіксації назв артефактів типу їх реалізації цей розрив проблем порушується. Клієнт тепер відомий і залежить від внутрішніх даних сервера. Зміна кодування сервера може вимагати повторної роботи клієнта.

Тут є багато відповідей, які я погоджуюсь із тим, що говорять вам, що це не дуже цінна конвенція щодо імен. Для тих людей, які не переконані в інших відповідях, я спробую продемонструвати, що говорять багато інших відповідей.

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;

Чи додаткові коментарі полегшують цей запит, або вони просто додають зайвий шум? На мою думку, вони просто додають зайвий шум і додають нульове значення. Саме це намагаються сказати антипрефіксатори. Крім того, використання префіксів насправді гірше цих коментарів, оскільки вартість оновлення коментаря набагато нижча, ніж оновлення імені префіксованої таблиці, якщо ваша модель даних потребує адаптації. Оскільки ці префікси мають вартість і вони не передають цінну інформацію, їх слід уникати.

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

Це висвітлювалося багато разів, але, мабуть, найвідоміше Джо Челко , американський експерт SQL та реляційних баз даних. Я особисто був в кінці прийому одного з його титулів в Інтернеті (відчував себе шанованим), і він розповідає про ці префікси як про "кайфу", або точніше, як про " скеуоморфізм ".

Загальна думка полягає в тому, що ці префікси - це давні практики кодування (ймовірно, через обмеження іменування, як 8-байтовий ліміт імен об'єктів), переданих поколінням програмістів без видимої корисної причини, крім того, що це просто "шлях це робиться".

Компанії, блогери та програмісти передають інформацію зі своїм власним стилем кодування, а деякі стилі можуть бути трохи більше "Франкенштейна", ніж інші. У компанії може бути "стиль будинку", і програміст змушений вивчити цю практику.

З часом речі пристають, навіть якщо причина, якою вони користувалися, тепер застаріла. "Тиблинг" - один з найбільш відомих прикладів цього в реляційному управлінні базами даних.

Для завершення: він не додає жодного значення, він додає рівно 4 байти місця для пам’яті на кожну назву таблиці без будь-якої причини, крім того, що вона там є. Сучасним системам SQL Server він нічого не пропонує, але якщо ви відчуваєте себе краще, маючи його там, продовжуйте користуватися ним.

Моя пропозиція полягала б у тому, щоб ти негайно припинив це робити. Якщо це робить вас незручно рухатися вперед, додайте "_tbl" до кінця імен таблиці. Звичайно, з причин, про які вже говорилося, цього робити також не потрібно. Людина, яка спочатку казала вам це зробити, дала вам погану пораду. Можливо, це було погано, "це має сенс з точки зору погано налаштованої системи нашої організації", але в цьому випадку це було вирішити. Ще погана порада.

Чи справді проблема "Не префіксуйте свої таблиці за допомогою tbl"?

Що стосується системи? Що стосується інших людей? Може бути. Ви можете породжувати ненависть лота.

Я особисто не префіксую таблиці, але роблю це на інших об'єктах, таких як перегляди, збережені процедури, функції тощо.

Я б сказав, будь ласка, припиніть це робити. Це було раніше, але продовжуючи це робити, ви заохочуєте нових людей, які потрапляють у ваше оточення, думати, що це місцева конвенція, і продовжувати. Але вони не просто продовжуватимуться, вони зроблять це трохи інакше

Коли тралюю db для певного елемента, і я не єдиний, хто відкриє провідник об’єктів і просто думаю, що я прокручую його, ви знаєте, що це за алфавітом. Тобто, поки префікси не почнуть каламутити води, і у мене є tblname, tbl_name, tbname, t_name та тисяча інших варіацій, стає важко знайти ту таблицю, яку ви знаєте, що вже є таблицею

Так само, префіксуючи все vw_ або sp_, хтось увійде, і ви отримаєте SPname, spname, s_p_name. Видаліть усі префікси, програмне забезпечення знає, що це за елемент, якщо вам дійсно потрібно знати, тоді замість цього використовуйте суфікс. NameOfMyView_v, NameOfMyProc_sp. набагато простіше шукати візуально

Але що робити, якщо ви копаєтеся через тривалий склад, що зберігається, і ви не можете легко сказати, що таке перегляд проклейка чи таблиця? Хороші шанси, що вони все одно будуть псевдоніми, і навіть якщо суфікс не допоможе вам

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

Якщо мені доведеться думати про перевагу наявності префіксу 'tbl', це те, що в поточних SSMS, з intellisense, я можу просто ввести

select * from tbl

а потім знайдіть потрібну мені таблицю (якщо я не маю поняття про точну назву таблиці). Це одноетапна робота. Звичайно, ми завжди можемо дізнатися ім'я таблиці з допомогою додаткових кроків, але я б сказав , що з приставкою «ТПС», це ОДИН кроку робота, і саме тому я завжди віддаю перевагу префікс (не обов'язково «TBL») в власний проект домашнього завдання.

Редагувати : (Після такої кількості голосів вниз, я все ще думаю, що варто вказати на деякі ніші переваги надання конкретного префіксу певній категорії об'єктів на сервері sql). Здається, ніхто не скаржиться на префікс для збережених процедур / функцій / поглядів, але завжди існує аргумент щодо цього з таблицями. (Мені в реальному світі не байдуже, подаємо ми префікс чи ні в таблиці).

Пам’ятаю, на сервері sql за 2005 рік виникла вимога знайти таблиці, в яких зберігаються процедури / перегляди, з іменами таблиць з префіксом, це була така проста робота з регулярним виразом / C #. (Так, я знаю, що тут були й інші способи, ніяких аргументів).

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

Розглянемо dbo.Userпроти dbo.tUser. Тепер уявіть, що ви хочете знайти всі місця в коді, якими користується ця таблиця. Яка версія робить це простіше (або навіть можливо?) Слово "користувач", ймовірно, має багато помилкових позитивних результатів, як імена змінних, у коментарях тощо.

Це те, що я не бачив в жодній з інших відповідей, але я є розробником cum-DBA, тому, можливо, іншим не доводилося працювати над застарілим кодом, де запити можуть бути вбудовані в додаток, і не всі запити повністю кваліфікують посилання на схему тощо. (Навіть якщо все повністю кваліфікований, вам потрібно знайти dbo.Userі [dbo].[User]і dbo.[User]і так далі). Або версії бази даних, де "інформація про залежність" стає застарілою і неточною (наприклад, старіші версії MS-SQL)

Отже, на деяких проектах, над якими я працював, я змішувався так, я мандатом мав tабо vпрефікс (tbl_ стає дурним), просто щоб зробити його більш вибірковим пошуковим терміном.

У пізніших проектах, з такими речами, як SQL Server Data Tools (привіт, Find All References) та доступ до бази даних виключно через рівень ORM, це не корисна програма, оскільки пошук усіх звичок таблиці є тривіальним (як це перейменувати!)

Кожна сторона має свої переваги та свої недоліки. Залежить лише від вашої команди чи компанії вирішити, які конвенції слід виконувати.

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

Єдиною реальною перевагою невикористання префікса є взаємозамінність. Однак я б запевнив, що це потенційно небезпечна ситуація. Звичайно, ваші сценарії та запити не порушаться, але, можливо, ви почнете занадто покладатися на цей факт, тоді як деякі речі просто не працюють із поглядами або недобросовісні.

Зрештою, це дійсно просто зводиться до того, що віддає перевагу вашій команді та як пише код / ​​сценарії.

У мене був привід префіксувати назви таблиць з "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

Я не можу придумати іншу причину для префіксації імен таблиць.