A new week, a new spate of warm summer days. I had almost thought the heat was behind us, but I suppose I should enjoy this possibly-last gasp of summer in the week before Labor Day weekend.
Today's warm weather inspiration is this interesting juxtaposition of girly pearls, professional pencil skirt and purple plaid shirt.
 |
| From sierraelizabethblog.com |
Plaid shirt, light grey pencil skirt, and pearls? Done and done. With a short-sleeved cardigan and fab leopard wedges for good measure.
Plaid purple button up shirt (thrifted, Fred David), $1.33/wear+
Light grey pencil skirt (JCP), $6.02/wear+
Short-sleeved grey cardigan (thrifted, Target), $1.88/wear
Single strand pearls (Macy's), $2.44/wear
Grey leopard wedges by Cole Haan, $16.50/wear
Outfit total: $28.17/wear
Given how much I like plaid, it surprises me that this is my only plaid button up shirt.
Today's other vision in grey is this hunkered down mini lop. I won't even bother asking who wore grey better: blogger or bunny? Rabbits always win.
In other news...Today I was able to put one of my data problems at work behind me!
I've probably mentioned that because of the way we join data tables in our new data visualization tool at work that our records kept multiplying out of control (the bane of the many-to-many relationship). There are some kludges to get around this in the tool but they are slow and clunky and don't always work with our fiddly data. It is not difficult to fix this in SQL but SQL runs extremely slowly within this tool, so the advice from everyone on the planet who knows jack about this topic says that you should run whatever SQL you need to run (e.g., to deduplicate one of the tables so you have a one-to-many relationship instead) before the data come in to the tool. Because I am not a SQL guru and because I do not own the stored procedures that produce the tables we feed into the viz tool, I've been waiting for MONTHS for my organization/our consultant to come up with a solution that does not turn my dashboards into frozen molasses. (Running SQL within the tool caused my visualization to take 45 minutes to load. Probably not going to pass muster at user acceptance testing.)
Finally last week, I sat in on a conference call with the consultant where I explained again what the issue was and what we needed to happen (and he kept confusing two terms--one that means "year" and one that means the combination of a site and a year--in a way that was very disturbing). He had a suggestion that our department head nixed because she doesn't want our stored procedures to create any more tables. Waaaah!
But then he emailed later saying, "Oh, you know, there is this field in your database called X that I could add to the stored procedures so it's available in your customer table and you could filter on it to get exactly the records you're looking for." This was very confusing because our customer table (created by the stored procedures) already had X in it. Like 6+ months ago we thought of using the database field X to filter but demonstrated empirically that it didn't work when we tried it in the tool. We figured, Oh, I guess field X doesn't have the properties we thought it did.
Turns out that unbeknownst to us, the consultant had created a calculated field, that is totally different from field X in our source database, and called it X! WTF???
So last Thursday, the consultant did the heavy lifting of adding the database field X (which is now called "[Name of our source database] X" to differentiate it from the X that is the consultant's calculated field) to the stored procedure that creates our customer table. (Note: this is so basic even I could have done it and it would be a major stretch to call my SQL skills "beginner level.") When the tables refreshed overnight, [Database] X became available to use.
I tested it out today and lo and behold, it worked. Just like we thought half a year ago it would. I'm trying not to let my annoyance over this idiotic "let's make something up and give it the same unusual name as this totally different thing in the source database!" thing that has delayed progress for so fucking long cloud the fact that the problem is now solved.
Note: you may be wondering why if field X is available in the source database, we don't just connect directly to the (mirrored) source database instead of futzing with this customer table. This is because our technology people have globally nixed the idea of end users calling for data on the database mirror server. Everything we want to access in this tool has to be moved over to a separate server.
You might also be wondering why we didn't refer to our database documentation or ask our technology people 6+ months ago for clarification about database field X when (consultant created) X didn't work the way we expected. No even halfway reliable or complete database documentation exists, and the technology people have told us that they "will not support" our use of the data viz tool by giving us any information about what our organization's source databases contain. Indeed, they seem under the impression that if we stopped using this particular tool, all problems with the fact that they do not understand the databases they maintain would magically go away and/or that no one in the organization would ever need to query the database so the issue would be moot. It is a mindboggler of the first order.
No comments:
Post a Comment