Closed ktaranov closed 2 years ago
Can you share the reasoning behind that change?
Hi, Adam, thanks for quick response. It is more clear and consistent naming files with production stored procedures with schema name (we use schemas for maintaining security roles ) and procedure name. First what I do with new version of your procedure - rename the file name. Also we use case sensitive instances and for us is very important to have correct notation: sp_whoisactive
and sp_WhoIsActive
critical difference in this case.
{SchemaName}.{ObjectName}.sql is also what Redgate source control uses, capitalised exactly as the object and schema are named.
Okay. This seems like a reasonable request. I'm going to pin it for a few weeks.
If you're reading this and interested, please reply and cast a vote:
My vote is #2.
This is entirely due to my personal preference of organizing objects by schema in subfolders. So I'd have a subfolder called "dbo" in my project, with all of my dbo. stuff in it.
Torn on this. I usually name my files just as files and they sit in a separate folder for schema so no schema prefix. I lean slightly towards #2, but wouldn't be bothered by #3. I do agree that the name of the file matching the name of the proc is a good thing.
2
2
2
2
2
I prefer 3, but 2 is also fine.
2
My preference is 3 first, 2 at a close second.
Some examples, for those that may not be familiar with Red Gate or the default Visual Studio database project folder structures.
├───Assemblies ├───Data ... ├───Security ... │ ├───Roles │ ├───Schemas │ ├───Symmetric Keys │ └───Users ... ├───Stored Procedures │ _dbo.spWhoIsActive.sql ├───Synonyms ├───Tables ├───Views
│ Database6.sqlproj ├───bin │ └───Debug ├───dbo │ ├───Stored Procedures │ │ _spWhoIsActive.sql │ └───Tables ├───obj │ └───Debug ├───Security ...
2 for me, because of Visual Studio defaults.
3
2 because of VS.
Similar to a lot of others: 3, followed by 2 as an acceptable alternative
3
2 looks cleaner, and I personally sort projects and archives similarly (Server > Database > Schema > File)
3
2, if nothing else it matches. Don't like putting the schema in file names.
2
3
3. reasoning: 2, if used in scenario 3 removes information which is expected to be there. 3, if used in scenario 2 shows a redundant schema, a mild cosmetic effect (summarised above by comments "don't like")
Also in terms of 'fixing' the name, it is easier to delete a spurious dbo. in the dbo folder than it is to guess which schema should be prefixed onto a schema-less object.
Therefore, a reluctant 3, because it is the only thing that 'works' in both scenarios. (if magic could occur, 2 for the people that would like it, and 3 that would like it that way, but i don't think that magic exists)
Either 2 or 3 is better than having a slightly different name for the file than the thing it deploys.
Would lean towards #3 as we have things arranged by object type, similar to what's in SQL Management Studio.
Could live with #2 as well.
You could also drop that "sp_" prefix :)
I think it is good to be as explicit as possible then if anyone wants less "explicifness" they can remove the first bit themselves.
2
@amachanic: may I submit two suggestions for future votings:
2 - sp_WhoIsActive.sql
2
2 sp_WhoIsActive.sql
Matches the First Responder Kit's naming (btw. maybe integrate it there @BrentOzarULTD)
I personally vote for option 2. I prefer using source control for db objects, and structuring the repo along the lines of: DatabaseName/SchemaName/ObjectName.sql
Option 3 would be preferable to option 1, but it would still not be ideal due to the flattened hierarchy it causes.
Vote for 2
3
3
@amachanic ~1.5 years passed, so when you're choosing the winning option since you've originally wrote about pinning it "for a few weeks"?
I like #2 as well for organization.
Hi, Adam. Great thanks to move in open source club your awesome stored procedure. Could you rename
who_is_active.sql
todbo.sp_WhoIsActive.sql
(prefered for me ) or justsp_WhoIsActive.sql
?