Among the many recommendations that Rajnikant Puranik offers in ‘Maximum Oracle with Oracle Best Practices’ (www.shroffpublishers.com) is his counsel about naming.
Document ‘naming convention’ and follow it, the author begins. The convention should cover not just the naming of tables and columns but also naming of other database objects such as views, constraints, and directories, he adds. “Use names and abbreviations consistently across the database. The same attribute should not have different names in different tables. For example, column for rate of interest should not be named as say ‘roi’ in one table, ‘intt_rate’ in another, and ‘irate’ or ‘rate_of_interest’ in some other tables. Decide one name, say ‘rate_of_interest’ and use it consistently.”
Puranik recommends the use of names that are readily comprehensible. He explains how names such as ‘asstcls,’ ‘astclsid,’ ‘astcd,’ or ‘assetclasscd’ for Asset Class Code – rather than a self-explanatory name like ‘asset_class_id’ – can make life difficult. It is better to use meaningful names, even if they appear to be long, he advises.
Though tempting for the short-term benefit of having to type less while coding, it is not advisable to use very short names whose meaning the coder is likely to forget after a lapse of time, what to speak of others who have to deal with the maintenance of the code, reasons Puranik.
One of the decisive factors for a suitable naming convention that he lays down, therefore, is whether a new person – say, a designer, maintenance person, coder, reviewer, or auditor – not involved in the project earlier is able to understand the database and the database code to a significant extent by merely reading it.
Another instructive section in the book is about designing for performance, where the author cautions that no amount of ‘great’ coding can alleviate the adverse effects of poor design on performance.
Maybe one could make a difference of up to 20 per cent or so in performance by using various strategies but to really make a dramatic difference in performance the poor design will ultimately have to be rectified, he notes. “A design may be good from the angle of implementing business logic, and there may be several such alternative designs; however, they may not be good enough from performance angle, given the volumes or number of simultaneous users.”
For the hands-on tech readers.