ScottPletcher (1/4/2013)

---

CELKO (1/4/2013)

---

Since SQL is a database language, we prefer to do look ups and not calculations. They can be optimized while temporal math messes up optimization. A useful idiom is a report period calendar that everyone uses so there is no way to get disagreements in the DML. The report period table gives a name to a range of dates that is common to the entire enterprise.

CREATE TABLE Something_Report_Periods

(something_report_name CHAR(10) NOT NULL PRIMARY KEY

CHECK (something_report_name LIKE <pattern>),

something_report_start_date DATE NOT NULL,

something_report_end_date DATE NOT NULL,

CONSTRAINT date_ordering

CHECK (something_report_start_date <= something_report_end_date),

etc);

These report periods can overlap or have gaps. I like the MySQL convention of using double zeroes for months and years, That is 'yyyy-mm-00' for a month within a year and 'yyyy-00-00' for the whole year. The advantage is that it will sort with the ISO-8601 data format required by Standard SQL. The pattern for validation is '[12][0-9][0-9][0-9]-00-00' and '[12][0-9][0-9][0-9]-[0-3][0-9]-00'

Starting to look like "bot" posts -- the same ridiculous nonsense repeated ad infinitum.

NOTHING in that post is really true.