Почему префикс имен SQL-функций?

Question

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

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

Answer 1

Вы правы в отношении более старых IDE

Как администратор БД, пытаясь исправить разрешения с помощью SQL Server Enterprise Manager (SQL Server 2000 и 7.0), он полностью завершил попытку просмотра разрешений.Если у вас был ufn, usp или vw, стало легче группировать вещи из-за того, как GUI представил данные.Вид или стол?Он может работать для вас как для разработчика, но при развертывании он будет зависать, потому что вы не предоставляете разрешения для самой таблицы: только для представлений или процедур.Конечно, vwThing снизит ваше кровяное давление ...?

Если вы используете схемы, это становится неактуальным.Вы можете «пространство имен» ваших объектов.Например, таблицы в «Данные» и другие объекты для каждого клиента в других схемах, например, WebGUI

Редактировать:

Функция.У вас есть табличные и скалярные функции.Если вы придерживаетесь концепции кода «VerbNoun», как вы узнаете, что есть, что без какой-либо другой подсказки.(конечно, это не может произойти, потому что имена объектов уникальны)

SELECT dbo.GetName() FROM MyTable
SELECT * FROM dbo.GetName()

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

SELECT dbo.GetName() FROM MyTable
SELECT * FROM dbo.GetNames()

Принимая во внимание, чтоэто менее двусмысленно, хотя и оскорбительно для некоторых людей; -)

SELECT dbo.sfnGetName() FROM MyTable
SELECT * FROM dbo.tfnGetName()

Со схемами.И никакой двусмысленности имени.

SELECT ScalarFN.GetName() FROM MyTable
SELECT * FROM TableFN.GetName()

Ваш комментарий «на любом другом языке» не применим.SQL не структурирован как c #, Java, f #, Ada (хорошо, PL / SQL может быть), VBA, как угодно: нет иерархии объектов или пространств имен.Нет Object.DoStuff метод материала.

Префикс может быть именно тем, чтобы держать вас в здравом уме ...

Answer 2

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

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

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

Answer 3

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

Answer 4

Что такое сценарий, который иллюстрирует веская причина использовать префиксы

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

Answer 5

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

Answer 6

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

В любом случае, нет требования SQL для использования префиксов, и, честно говоря, IMO, они не имеют реального значения.

Answer 7

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

Answer 8

Поскольку я недавно наткнулся на этот вопрос, я хотел бы добавить следующий момент в пользу префиксов: представьте, у вас есть некоторый идентификатор объекта из некоторой системной таблицы, и вы хотите определить, является ли это функцией, процедурой, представлением и т. Д. Конечно, вы можете запустить тест для каждого типа, хотя гораздо проще извлечь префикс из имени объекта, а затем действовать в соответствии с этим. Это становится еще проще, когда вы используете подчеркивание для отделения префикса от имени, например usp_Foo вместо uspFoo. ИМХО, дело не только в глупых IDE.

Answer 9

Одно (и единственное) преимущество, которое я могу придумать, заключается в том, что применяемая им схема префикса может упростить использование intellisense / autocomplete, поскольку связанные функциональные возможности автоматически группируются вместе.