The Kitchen Drawer...
Everybody's got one; it's that drawer in your kitchen that you just throw things into when you don't really have a good place for it. We have two in our kitchen, one for kitchen type stuff and one for everything else.
In software development, we have them too. Developers use words like "Utilities" and "Common" for them, but essentially they're the same. They're a place to put stuff that you need to keep but don't know where to put it. However in software development (in particular database development), we can split up these Utilities or Common objects into their own logically grouped objects (i.e. packages) without major architectural changes.
For example, I had a code review session for an application that came across my desk today and viola, there was a "Common" pl/sql package being created. I took a look at the package and sure enough it was doing lots of common things. Upon further inspection, it actually was working with three logical groups of functionality (file management, log management, and concurrent process management).
My recommendation for the team, create 4 packages.
Why four? Create a package for the file management, another for the log management, a third for the concurrent processes and a fourth interface package that you can use to call the objects in packages 1,2,3. You can call your interface package "Common" or "Utility" if you'd like, but you've pulled out the logic specific to each of the three clearly defined groups.
Unlike your kitchen where space is limited, creating Oracle PL/SQL packages that contain logically related activities doesn't cost you an arm and a leg (and weeks of eating out at restaurants).
In a nutshell, at home, use the kitchen drawer. At work, avoid it if at all possible.
Until next time...Rich
In software development, we have them too. Developers use words like "Utilities" and "Common" for them, but essentially they're the same. They're a place to put stuff that you need to keep but don't know where to put it. However in software development (in particular database development), we can split up these Utilities or Common objects into their own logically grouped objects (i.e. packages) without major architectural changes.
For example, I had a code review session for an application that came across my desk today and viola, there was a "Common" pl/sql package being created. I took a look at the package and sure enough it was doing lots of common things. Upon further inspection, it actually was working with three logical groups of functionality (file management, log management, and concurrent process management).
My recommendation for the team, create 4 packages.
Why four? Create a package for the file management, another for the log management, a third for the concurrent processes and a fourth interface package that you can use to call the objects in packages 1,2,3. You can call your interface package "Common" or "Utility" if you'd like, but you've pulled out the logic specific to each of the three clearly defined groups.
Unlike your kitchen where space is limited, creating Oracle PL/SQL packages that contain logically related activities doesn't cost you an arm and a leg (and weeks of eating out at restaurants).
In a nutshell, at home, use the kitchen drawer. At work, avoid it if at all possible.
Until next time...Rich
Comments