I always thought I have a well established opinion on separating application needs and reporting need. So whenever I was asked to add some attribute to the production system, which is “necessary for reporting”, I would always say: we will build this dada in the reporting system.
So first I could not believe what I just said, when I’ve said something to the effect “I will create this table, which application does not need, and I will use it to record data, which we need for reporting. Literally, after I’ve sadid this I thought – what in the world I am saying?! But then I was very positive that we indeed need this data to be recorded, and I’ve been keeping thinking about it…
And then I’ve realized, that the “reporting” I was referring to is not really a “reporting”. We just historically use the reporting system to go for this information, but in reality, those ones are not analytical reports, but operational reports, which raise alerts when some processing errors occur – mostly in the daily batch jobs. And then I started to think – probably we should treat those operational reports differently? They are not processing big data volumes, they are actually exception reports, and may be we even need to create an “exception processing service” in our production system?
Yes, just to prove, that I am right, of cause 🙂
and data, which is required for reporting. I think it makes lots of sense –
Fellow chicagoans, did you get a chance last year to attend a first 2QPGConf in Chicago?! If you did, I am sure you loved it, and I am sure you’ve promised to yourself to do it again next year.
Well, “next year” is now “this year”. And the conference is already officially announced – check out the conference website here. And note – this year the conference will last for 2 days – there will be a day of training, and a day of presentations. The call for submissions is opened, the registration is opened, you do not need to travel, it will be all here is Chicago, and managers like it :).
If you where there last year, you already know that that’s the event you do not want to miss, and if you were not there – it’s time to check it out 🙂
Last week we have a first meetup of Chicago PUG in our new office. From my previous experience moving meetup to a new address always incur some casualties, so I was really glad that people have come! Our new office is not only a better workplace that the previous one, but it is definitely a better place to host meetups.
I had a very busy time for the several weeks before the meetup, and a move itself is quite a stressful experience, so in the morning of the day of meetup I’ve realized I absolutely didn’t think through any of the details. Turned out – I didn’t have to! There was no need to move the furniture as in the previous office, our new kitchen provides a way better setup for people to talk before the start of the meetup, everything was ready for the presentation.
As for the presentation, Chad Slaughter presented a talk “Postgres development methods: pgtap & FT testing”. Which was really perfect for us, because I am trying really hard to popularize the pgTAP tests and a concept of unit tests for the database in general. I do not know why it is so hard, but although pgTAP is a very well established framework, people just like to create problems for themselves and not to maintain the tests for any database work. Either because they have no time, or because tests are boring, or most likely because they just do not understand their importance. So I was really happy that somebody except me was preaching the same thing.
Anyway, I just feel really good about how this meetup went, and hope to maintain the same quality of professional interaction and networking. For many years to come!