Good practice in SAS generally is for everything to have a proper name. EG will name output tables from tasks with a generic ‘Query_for_query1’ style of name. This won’t do. All tasks and output datasets need proper names. I would suggest that tasks be named for what they are doing and outputs named for what they contain.
While you can do many things with one query task it’s a good idea to separate tasks out. This may not be needed and could potentially slow things down if you only have hundreds of rows of data but if your company information stretches to millions and billions of rows of data then you need to keep an eye on what you are doing. Separation of tasks by function can help improve performance of your project. I like to use input and output tasks.
Here is a nicely laid out process flow
Efficient code using a wizard?
Now we get onto the really important bit. This should be the subject of another blog (and I think it will be) but some basic rules here can be applied. The nodes will write your code for you, the same as a paper shredder shreds paper for you, if you feed it a phone book in one go it’s going to break. The same way if you create a query task and join 20 tables using a ‘select distinct’ and 200 case statements, the task will be built, but will run like Usain Bolt… in flippers and wearing a suit of armour.
Fundamentally what you are doing is pulling data from somewhere, doing something to it and then putting it somewhere else, even if just in a report. Apply the philosophy in your task usage, you may have a flow to extract your data in small quick steps, a flow to transform the data, change fields, derive values, and run case statements, and a flow to put the data where it needs to go.
None of the above is rocket science. None of it is particularly clever but it can be very helpful. A tool is only as useful as the use to which it is put. EG can be a very powerful weapon in the right hands but you need to learn how to hold it and which way to point it. If you are a coder or a drag and drop addict, EG can be the right place for you to work your magic even if you don’t use wizards. Think about how you use EG and how your colleagues use EG. Start thinking of how you could slowly bring all your users to work the same way, and think of the potential benefits of doing so. Only you can change the way people look at and use this tool. Start being the best practice ambassador in your organisation. Start small, pick a few ideas from above and try using them in your everyday work. Show your colleagues and see if you can start the pebbles rolling at the top of the hill. Good luck!
Enterprise guide for SAS coders.(Part 3b – Hotel Paradiso cont.)