Recently I wrote a change order for a client. Their requirement was to track revision with different vendors and revision include multiple fields. Also, the client provided a list of fields they want to track. The guy who gave requirements was a technical guy and he gave me list including primary key. When writing the change order, I decided to make the table as supplement table and put the list of all field as he gave me in that list. Later, one senior developer also checked the change order before submitting it to the client and he suggested me golden advice.
This is a revision of what I used to do and should do when designing a table. This makes code standard and we also follow the design pattern with best practice. Most importantly it make code understandable along with the purpose of the table for an experienced developer.
Always take one thing in mind, don't trust completely on your client. The technical guy who gives you requirement is very good at SQL, he has good experience of the designing table but always considers he is not a NAV guy and he doesn't know how tables are structured in NAV, he doesn't know how the things flow and how the things should be designed for NAV. You are NAV guy and you are NAV consultant. So trust yourself and design tables as it should be. The primary key of the supplement table should always be "code".Then I remembered what I studied about best practices of table development during my inception days of NAV. Following was the thing I used to practice during those old days:
- Master Table:
For Master table like Customer, Vendor primary key is always "No" with Data Type "CODE" and field length 20. - Supplement Table:
For Supplement table like Currency, Payment Terms, Revision primary key is always "Code" with Data Type "CODE" and field length is 10 or sometimes 20.
Another thing that always follows during linking of supplement table with other table was a naming convention. Always named field as "Table name Code". For example, "Agreement Code", "Currency Code" etc.
This is a revision of what I used to do and should do when designing a table. This makes code standard and we also follow the design pattern with best practice. Most importantly it make code understandable along with the purpose of the table for an experienced developer.
Post a Comment
Post a Comment
Thank you for comment, I really appreciate your view.