A couple quick thoughts: 1) In well written SQL queries your aliases are in one place for easy checking. It's a lot easier even in a 100 line query to review the from clause than it is when you are writing the query to be looking up acceptable alias names in a spreadsheet or a long text file (we are approaching 200 relations and some queries use short inline views).
2) The SQL queries in the old code are not well written. They typically are created by concatenation of text strings, and it isn't always as obvious what all is in the query as we'd like. I think the issue of acceptable aliases is beside the point. The old code has database structure changes retrofitted onto it which raises problems and it is hard enough to read that trying to retrofit a system of acceptable list of aliases there is likely to be a bug factory. If we are to look at a coding convention in this area, I would suggest we focus on new code and simply adopt a rule which states that inline views should be discouraged for inline views of any complexity, since that's the worst SQL debugging I have ever had to do has involved that. I would note that the new code generally requires that most queries are well written as a structural matter. For the old code, I think the way to think about it is "it's on life support until a replacement arrives." Best Wishes, Chris Travers ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
