定义数据库ID常量/变量的最佳实践是什么

I find that when I am working on a project it often simplifies things to define variables or constants that represent database ID fields. In golang I have a constants.go file with

const (
   //SELECT ID FROM dbo.MyTable
   MYTABLEID_NO    = 1 // MyTable ID for NO
   MYTABLEID_YES   = 2 // MyTable ID for YES
   MYTABLEID_MAYBE = 3 // MyTable ID for MAYBE
)

Is this considered bad practice? how might I get around doing this if it is? Is there a more dynamic way of doing this in golang? If for some reason an ID changes, new IDs are added or the table has many IDs this way of doing things starts to break down.

Your are likely to get wildly different answers on this as it merely boils down to preference. I would not consider this to be an example of a bad practice. If you are not using a orm mapper then constants or enums would be a good way to represent "typeification". There are two questions you should ask yourself.

1. Will the values change once established.
2. Will there need to be loose coupling between the code and the database.

If the answer to #1 is yes then I would look into pulling your values from a type table as it would be counter intuitive having constants or enumerations in the first place. (If the types are core to your application and no other client applications need to be modified when values are added then this would be easier to maintain and use in logic comparisons)

If the answer to #2 is yes then I would look into an orm mapper or other ways to express your constant range dynamically. If you can't respond to changes to the database then that puts you in a predicament.