T-SQL Context Switching

Question

T-SQL Context Switching

Steve Jones - SSC Editor

SSC Guru

Points: 736173
More actions
October 7, 2019 at 12:00 am

#3682647

Comments posted to this topic are about the item T-SQL Context Switching

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply

Aaron N. Cutshall SSCrazy Eights Points: 9011 More actions · Answer 1

I totally agree that what the standards are defined as are not nearly as important as following them. Consistency is King!! We'll, that and good documentation.

LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com

Rod at work SSC-Dedicated Points: 34007 More actions · Answer 2

I don't know what to think of this editorial. I do agree that reading others code can be taxing and hard to do. But heck, when I go back to code I wrote a few years ago, I tend to have similar difficulties.

Coding standards are useful, but in all my years of coding I've only worked on one team that actually sat down to decide on what our coding standards would be. In my experience, it isn't at all easy to get people to agree upon coding standards. What we try to do here is not edit other's code, unless it's absolutely necessary such as when they're on vacation or are sick. I've read my colleagues code, and with only one exception, I haven't any issues with it. The single exception I definitely try not to bother with because his coding patterns bug me. There's nothing objectively wrong with them. I just don't like how he codes.

Kindest Regards, Rod Connect with me on LinkedIn.

Eric M Russell SSC Guru Points: 125561 More actions · Answer 3

I'm willing to tolerate inconsistent naming conventions - so long as the same column is named and typed consistently across tables. Also, I expect the column to be unambiguous in regard to it's purpose. For example, I don't like to see columns with names like 'Delivered', 'Status', or 'DID'. Any of the following as OK - just tell me that the column is related to delivery status and that it's an ID.

DeliveryStatusID

Delivery_Status_ID

deliverystatusid

delivery_status_id

DELIVERY_STATUS_ID

This reply was modified 5 years, 1 month ago by Eric M Russell.

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Rod at work SSC-Dedicated Points: 34007 More actions · Answer 4

Eric, your comment made me realize I hadn't even thought of column naming conventions! WOW, how could I have forgotten that!! I'm fairly flexible, although I prefer to use Pascal notation for naming conventions. e.g.: ClientNumber. But I'm OK with client_number or Client_Number. I worked with this one developer who insisted upon only using initials for all column names, then insisting that we maintain a Word document with all of the initials listed, specifying what the initials stood for. I had to argue with her about that, but finally prevailed saying that there was no guarantee that the Word document would always be available.

Kindest Regards, Rod Connect with me on LinkedIn.

Eric M Russell SSC Guru Points: 125561 More actions · Answer 5

Using initials for column names and then having a document at your desk for reference - that is so retro '80s RPG/COBOL.

I too would recommend implementing the database using a proper PascalCase naming convention. However, just to accommodate this one developer you mention, create a view on each table that renames columns as a 3 or 4 character abbreviations. As for a document mapping abbreviations to column names, they can print out the views and tape them up on their cubicle wall. Of course, they'll eventually give in and just use the tables like everyone else.

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

JustMarie SSCertifiable Points: 7771 More actions · Answer 6

The "organic" nature of database development has caused us to have this in our projects.

Phase 1 - Inexperienced developers. Poor coding practice. Column names and data types from source data regardless of usage.

Phase 2 - Additional developers added. New coding practices, previous code not updated. Column names and data types more in line with usage so mismatching between tables.

Phase 3 - New management added. New coding practices based on manager's preference, previous code not updated. Mismatch of column names and data types continue.

Phase 4 - Developer turnover. Previous code copied and pasted into new code with developer preferred changes, previous code not updated.

This is how you end up with a mess. And it's why coding standards are nice but not really going to help unless you start with a good design that's enforced and developers who will adhere to the design and standards.

Rod at work SSC-Dedicated Points: 34007 More actions · Answer 7

Eric M Russell wrote:

Using initials for column names and then having a document at your desk for reference - that is so retro '80s RPG/COBOL.
I too would recommend implementing the database using a proper PascalCase naming convention. However, just to accommodate this one developer you mention, create a view on each table that renames columns as a 3 or 4 character abbreviations. As for a document mapping abbreviations to column names, they can print out the views and tape them up on their cubicle wall. Of course, they'll eventually give in and just use the tables like everyone else.

I like that approach.

Kindest Regards, Rod Connect with me on LinkedIn.