Какова цель соглашений о присвоении имен tbl_Product, tbl_Order?

Question

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

Если администратору БД необходимо посмотреть, какие объекты являются таблицами, они всегда могут присоединиться к DMV или таблицам схемы в главном, верно? Я не могу думать о том, насколько они были бы полезны для программиста, тем более, если в проекте используется инструмент ORM.

Тем не менее даже во время записи хранимых процедур они, кажется, мешают.

Кто-нибудь может объяснить, как они были бы полезны, не субъективно? Ex (наличие tbl_ помогает мне выполнить x задачу)

Answer 1

Я слышал одно и то же снова и снова, потому что это помогает им узнать тип объекта.

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

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

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

Собираетесь ли вы переименовывать всю базу кода или придерживаетесь представления с префиксом tbl _?

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

Answer 2

Это венгерская запись , или, скорее, ее неправильное использование. Первоначальное использование состояло в том, чтобы поместить некоторый важный аспект использования переменной в качестве префикса. Тот факт, что таблица является таблицей, вряд ли является полезным способом использования венгерской нотации.

В ASP венгерская нотация используется для указания типа данных, поскольку VBSCript имеет только варианты. Я видел, как программисты ASP применяют это и к таблицам и полям в базе данных, и это один из способов использования этого неправильного использования.

Answer 3

Я не могу придумать много преимуществ. Вы можете определенно увидеть более чистый SQL, как это:

select post.id, post.subject, post.body from tbl_post post where post.author="eric"

Упрощает ваши переменные. В противном случае, похоже, вы имели дело с людьми, которые изучали базы данных в MS Access.

Answer 4

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

Answer 5

Я думаю, что при использовании ORM, такого как Entiry Framework, может быть проще определить, с какой стороны сопоставление имеет дело с таблицами, а с другой - с объектами (сущностями). Например, tbl_Employee отображается на Employee. Нельзя путать слои абстракции.