Posts by Sr Mad Science

MongoDB's SQL-to-NoSQL converter uses AI to smash the language barrier

30 seconds to do the translation, 30 months clearing up the mess...

Did the people who invented this ever work with a real, live production SQL system?

I've spent my career working with SQL and I've never once seen a live system where everything in the schema could be taken at face value and was what the tables and columns claimed it to be. In the real world there will always be exceptions and kludges. Translating such a schema without the tribal knowledge of what it means will lead to deep, serious bugs.

So it'll run, and it'll produce code, but whether that code is even useful, never mind usable, is another question.

I can't wait to see the first complaint from someone who used the converter and then found that the numbers didn't tie when compared to the old system :)

National newspaper duped into running GPT-4-written rage-click opinion piece

I used to get get published in the Irish Times. This doesn't surprise me...

I used to be a regular contributor to the Irish Time's letters page.

At no point did they ever:

1. Verify that I existed and I was a real person.

2. Check that any content that appeared to be from me, was in fact from me.

I also have a friend who used to make a point of sending in provocative letters under false names. Even when the address he gave was that of a well known bakery within walking distance of the IT's office he was never challenged.

So the idea that they could be fooled like this doesn't surprise me. Another thing you have to bear in mind is that all media outlets have an agenda, even if it's an unconscious one, and content that aligns with that agenda will face less scrutiny than it should. In short, they are just as vulnerable to clickbait as humans are.

Db2, where are you? Big Blue is oddly reluctant to discuss recent enhancements to its flagship database

Re: Throwaway society mentality comes to IT

"Badly written SQL? Why bother tuning it, just crank up the number of CPUs on the config page for the instance, "

There are two kinds of databases in the world. The ones that don't get used much (around 90%), and those that are frantic hubs of activity keep people in business (10%). What you use for the 90% doesn't really matter. You can be breathtakingly incompetent and get away with it. But if your application is in the 10% and your idea of 'tuning' is to crank it up to 11 then sooner or later you will get your backside handed to you, or possibly even the contents of your desk in a bin liner.

There are a bunch of scenarios (especially in OLTP, where I work) where scale is a fundamentally nasty problem that can't be solved by throwing hardware at it. It turns out that adding multiple cores makes things worse, and multiple servers much worse, unless you re-design the DB and/or application to think in those terms...

As for support: I can understand people being reluctant to put themselves in the clutches of Oracle or IBM for support. Been there. Done that. But if you're going to *insist* on open source and wise enough to realise you need multiple vendors that will compete against each other, Postgres is pretty much the only open source DB that has more than 1 vendor providing credible, enterprise level support. The 90:10 rule also applies here. If you are in the 10%, and want to do it yourself, you need a professional support organisation with at least 3 technically competent people who understand database internals and can compile and patch the product at will, 24/7/365.25. That's >US$500K a year, which would pay for a lot of outside support...

Database consolidation is a server gain. Storage vendors should butt out

Consolidation? Here be Dragons!

I have to question whether the cost of disk storage should be the driving factor here. If the hardware is CAPEX and has already been paid for surely the only opportunity to save money will when it reaches the end of its life, unless a radically cheaper alternative appears? In the cloud this argument makes more sense, as we're talking OPEX and annoying monthly bills for storing stuff...

As for consolidating legacy databases:

Excluding gratuitous clones used for testing and development, IMHO the vast majority of 'overlapping' databases have some pretty good reasons for doing so, usually involving office politics or hard-to-do or obscure functionality that breaks database schemas when you try and merge them. The people who understood the problem in detail will probably have moved on, which means you run the risk of getting involved in a project which delivers no new functionality, might save some money at some point in the future when (and 'if'!) you purchase more enterprise storage, but also has a very high probability of breaking long-stable functionality in exciting ways.