Posts tagged: SQL

Playing with PL/pgSQL

June 5, 2009, by No comments yet

Typically, end-users and webmasters will not deal with this kind of development. PL/pgSQL is the internal procedural language for creating things like functions. The most you will see a webmaster deal with is SQL for adding/editing an entry.

However, my day job requires me to learn several new skills and this week its PL/pgSQL. Our members receive statements twice a year based upon their inventory for a given season. Each season updates once a year. So, whatever you have for the Spring season for this year, will be updated the next, along with anything you added during said year. Got it? Good.

In order to automate this inventory listing, I am working on a dynamic SQL SELECT statement to account for time of year (really, the month) and current season.  So, why is this difficult?  Well, because I don’t know PL/pgSQL that well yet. I would have usually done this in PHP and simply edited the SQL statement variable with a new date. However, we have a large number of members and each of them can have one to hundreds of listings in their inventory. That means tens of thousands of possible items for a given season. In order to speed up the listing for any given member, we wrote functions to create a temporary table for that member’s listing. The end result is faster page loading on the member portal.

A better way to view your data and report?

March 11, 2008, by 2 comments

I just attended a session here that describes a product from Datatel that is designed to off-load data from your Unidata/SQL Server/Oracle backend for Colleague. This is an intriguing way of solving reporting problems.

It essentially works by making a copy of relevant data to a secondary (or reporting) server. The real trick is that no matter what database is used for the application back-end, you are reporting off a SQL compliant database with industry standard tools. Additionally, even if the application changes its data model over time (and what app doesn’t), it should not affect your existing reports. This is because when the data is copied (or extracted), only relevant fields are carried over. Those which are not typically used do not make the transition to the new database (let’s say with a name like person_extract).

For example, let’s say you have a table that describes a person. It will have typical information like name, address, city, state, zip, birthdate, social security number (a really helpful bit in tracking people. i know, a little creepy.), and perhaps maiden name for women. Now, the location for all this information may have names like first_name, last_name, etc. What you see on the reporting server is something like first_name_extract, last_name_extract, etc. However, if the data model is changed and the maiden name is then placed in another table and given a name like maiden_name or name (assuming a table name like alternate_names and a field denoting maiden name, it will not make a difference to you. You are still reporting off person_extract. Where the data comes from to populate first_name_extract or last_name_extract, you do not care. The ODS takes care of that.

Really nice for keeping old reports relevant.

In addition, you can also use several database servers to report from. Datatel’s Data Orchestrator ODS (Operational Data Store) can use Microsoft SQL Server and Oracle. They are looking at MySQL as well. Moving forward, any additional SQL compliant servers they add just gives the IT department flexibility and smaller organizations a chance to save money.