November 7, 2025 at 12:00 am
Comments posted to this topic are about the item Poor Name Choice
November 7, 2025 at 9:51 am
Ah, the art of helpful file naming! In this field, it's a key part of being nice to oneself.
And not just file names. Remember SQL Server v.Next? It was a great name, until the next version came along.
And yes, avoid spaces. But even more, be consistent. I'm working on a DB at the moment where some field names use camel case, others spaces, and others underlines. Now, where was that field again -- I'm sure I sorted the list alphabetically...
MarkD
November 7, 2025 at 4:37 pm
I would love consistency. What I mostly aim for is to be consistent moving forward and refactor if possible. And where possible, tools to help enforce, or at least remind, people of what we've agreed do.
I like SQL v.Next. It's always the next version. Right now it would mean SQL Server 2028 as 2025 is coming soon
November 7, 2025 at 7:18 pm
I scoff at names ending in _final.pdf as they invariably never are.
November 7, 2025 at 8:27 pm
I scoff at names ending in _final.pdf as they invariably never are.
Yeah, so true. Not even _final_final.pdf cuts it.
It's actually really hard to get to a final version... When I was doing technical writing back along, I had a colleague who was a genius at spotting mistakes that everyone else had missed. He could just glance at the "final version" as it was coming off the glossy printer ready to hit the street, point at something on it and ask "What about this??". And we'd all get that ghastly sinking feeling and wonder how it could possibly have slipped through.
MarkD
November 7, 2025 at 9:46 pm
I am a fan of having things like "current" or "latest" with the expectation that I will rename it when a newer version comes out. Where possible, I like having an alias for current or latest. So when a new version comes out, I can just re-point the alias to the new current/latest and it'll always be the most recent that we maintain. And if the NEW latest ends up having a bug or an issue, we re-point the alias to the previous latest and we can fix things while users can keep using "latest".
Now not all systems allow this type of aliasing, in which case I like using tags to indicate the latest if the system supports it. Then I can filter by tag to see the latest and similar process as with the aliases.
Not fool proof as all it takes is one person updating things and forgets to update the alias/tag and people won't use the latest, but it works decently.
As for object naming, I spent a while updating our coding standards that included naming conventions with respect to SQL. The original ones said that all objects must be prefixed with what the object is. tb_ for table, vw_ for view, and so on. I imagine you see where this is going but if not - sp_ prefix for all stored procedures. I changed that so that object prefixes were not needed. SQL stores the objects type in the sys.objects table and the GUI stores them where they belong (tables in the tables folder for example) so the prefix doesn't add anything. PLUS, for those unaware, sp_ stored procedures tell SQL to look in master first which slows down the start time of those stored procedures.
Fixing things for the future is easy to do - the challenge comes in with fixing historical stuff. Renaming an object could break an application and if the application is ancient BUT essential, the source code may be hard or impossible to recompile.
And I 100% agree about avoiding spaces. never name anything with a space as you never know what problems it may cause. One nice thing about putting spaces in SQL objects is it ensures that people are properly escaping the objects with []'s, but tools like SQL Prompt help with that too and are less frustrating to work with.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
November 8, 2025 at 8:43 am
Of course, Windows NT didn't mean Windows New Technology.
I use Docker containers where only one version of a container can be tagged with latest. By convention, latest means exactly what it says.
However, I work with AWS ECR (Elastic Container Registry) and we configure it so that images are immutable. That means that if you tag something with latest, you are stuck with it; when a newer image comes along, you can't tag that with latest because your previous immutable image has it.
I've learned to appreciate semantic versioning.
Amazon take a slightly different approach with their version of Linux. Version at this time is AL2023 version 2023.9.20251105
When we write Word/PDF documents we use semantic versioning too.
November 10, 2025 at 1:21 pm
I frequently get asked for one-off extracts from our data warehouse which I save as spreadsheets with meaningful names like Reconciliation Failures. Then, inevitably, the "one-off" gets requested repeatedly (often with additional columns), so I end up saving them under the same name, but with a suffix of (yyyy-mm-dd). One habit I've got into which helps future me a lot is to paste the query I used into a separate tab in the workbook. That makes a world of difference when asked to re-run something months later when I've completely forgotten what it was all about - it would also help anyone else who had to pick up the request in my absence.
November 10, 2025 at 6:01 pm
I like using dates as well, though for me it's an easy way to decide what to delete later when it's been there too long.
Viewing 9 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply