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

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

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

Ответ 1

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

Как администратор баз данных, пытаясь исправить разрешения с помощью SQL Server Enterprise Manager (SQL Server 2000 и 7.0), он был полностью запутан, пытаясь просмотреть разрешения. Если у вас были ufn или usp или vw, стало легче группировать вещи из-за того, как GUI представил данные.

Говоря, что если у вас есть SELECT * FROM Thing, что такое Thing? Вид или стол? Он может работать для вас как разработчика, но он будет разбит при развертывании, потому что вы не предоставляете разрешения для самой таблицы: только просмотры или procs. Наверняка a vwThing будет удерживать ваше кровяное давление...?

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

Edit:

Функция. У вас есть табличные и скалярные функции. Если вы придерживаетесь концепции "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 не структурирован, как С#, Java, f #, Ada (OK, PL/SQL может быть), VBA, независимо от того, нет иерархии пространства или пространства имен. Нет Object.DoStuff.

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

Ответ 9

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