A few weeks ago, we were running into severe disk space and memory issues on our development servers at work. Our set-up is a bit odd, we have 3 servers - one for the transactions, one for the web interface, and the final one for reporting. Using transactional replication we have databases that can exist on all 3 servers. Yes, it’s can be a real nightmare to maintain, but anyone who works with replication already knows this.
A few weeks bit over a month ago, I took the plunge and attended my very first SQL Saturday, SQL Saturday #370 in Phoenix. I’ve never had a chance to go to any of the local user group events or another SQL Saturday due to scheduling issues, etc. but this year I reshuffled things so I could take part. I’m really glad that I did, I truly learned a lot of stuff and I also realized I know more than I probably give myself credit for.
I have answered a lot of MySQL pivot questions over on Stack Overflow and a few over on Database Administrators and have learned some things about how to transform data in MySQL. Unfortunately, MySQL does not have PIVOT function, so in order to rotate data from rows into columns you will have to use a CASE expression along with an aggregate function. Let’s set up some sample data. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 create table products ( prod_id int not null, prod_name varchar(50) not null, primary key (prod_id) ); insert into products (prod_id, prod\name) values (1, 'Shoes'), (2, 'Pants'), (3, 'Shirt'); create table reps ( rep_id int not null, rep_name varchar(50) not null, primary key (rep_id) ); insert into reps (rep_id, rep_name) values (1, 'John'), (2, 'Sally'), (3, 'Joe'), (4, 'Bob'); create table sales ( prod_id INT NOT NULL, rep_id INT NOT NULL, sale_date datetime not null, quantity int not null, PRIMARY KEY (prod_id, rep_id, sale_date), FOREIGN KEY (prod_id) REFERENCES products(prod_id), FOREIGN KEY (rep_id) REFERENCES reps(rep_id) ); insert into sales (prod_id, rep_id, sale_date, quantity) values (1, 1, '2013-05-16', 20), (1, 1, '2013-06-19', 2), (2, 1, '2013-07-03', 5), (3, 1, '2013-08-22', 27), (3, 2, '2013-06-27', 500), (3, 2, '2013-01-07', 150), (1, 2, '2013-05-01', 89), (2, 2, '2013-02-14', 23), (1, 3, '2013-01-29', 19), (3, 3, '2013-03-06', 13), (2, 3, '2013-04-18', 1), (2, 3, '2013-08-03', 78), (2, 3, '2013-07-22', 69); We can easily query the rep, sales, and product data by joining the tables:
Paging bluefeet, there is a PIVOT question to be answered. While that might seem like a joke, it has really happened, especially over on Stack Overflow. If you have seen any of my posts, then the chances are that I was answering a PIVOT question (or something similar). At this time of this post almost 20% of my total answers (over 3k) have been on pivot questions. You might ask yourself, why pivot?
Boy, I am sure behind the times with having a tech type of blog, but being late is better than never. I am going to try to use this platform to discuss some of my tech journeys while I delve into my new job as a DBA developer. I have worked on SQL Server in the past, but I will be venturing into Oracle development as well as more in depth SQL Server stuff.