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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tbl
tbl_
Table_
t_

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

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

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

не проверяйте готовность к тому, чтобы примыкать к другим людям. Профи Вы должны рекомендовать всегда новые префиксы, подготовленные с вашими дополнительными именами. ПРОДОВОЛЬСТВИЕ ПРОДВИЖЕНО ИСПОЛЬЗОВАЛСЯ ПРОЦЕССОМ ПОДГОТОВКИ В НОРМ.

ПОСМОТРЕТЬ, КАК ДОСТУПНО? Ну а люди еще могут понять, за что вы пишите!

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

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

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

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

Я читал несколько постов в блоге, подобных этому или этому (их довольно много), после того как я унаследовал свой первый экземпляр 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. ... и так далее.

Это действительно форма Apps Венгерский (обратите внимание, что объекты одного типа могут иметь разные суффиксы в зависимости от цели). Но с суффиксом вместо префикса. Я не могу сказать вам достаточно, как эта система так легко читается. 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, или любые другие технические детали. Конечно, администратор базы данных должен знать эти детали для выполнения некоторых редких запросов DDL / DCL, но кажется неэффективным загрязнять пространство имен ради меньшинства, которое действительно знает, как перемещаться по схеме и получать все технические детали.

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

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

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

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

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 байт для имен объектов), передаваемых поколениями программистов без видимой на то полезной причины, за исключением того, что это просто «путь». сделано".

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

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

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

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

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

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

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

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

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

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

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

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

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

select * from tbl

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

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

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

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

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

Это то, чего я не видел ни в одном из других ответов, но я разработчик и администратор базы данных, поэтому, возможно, другим не приходилось работать с устаревшим кодом, где запросы могут быть встроены в приложение, и не все запросы полностью определяют ссылки со схемой и тому подобное. (Даже если все полностью квалифицирован, вам нужно найти 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

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