macOS OS X Unix

[CarlJ]

Hmm - Great OS with a lousy editor vs. great text processing language with a lousy editor. What's option C?
...
You sayin' PostgreSQL is slow?

To the first point (and I'm going for elucidation, not arguing), I already have a great OS, called Unix, I don't really need an OS written inside an OS; I came here to edit text and do text processing. So Vim it is. It does have an initial speed bump to overcome, but it is scarily efficient at modifying and rearranging text, which is what a programmer does much more than the initial typing. Emacs optimizes the entry of individual characters to the detriment of every single other command - _everything_ else is some sort of chording. But I don't spend a lot of time typing single characters. I do spend a lot of time typing multiple lines of code, at which point an "i" beforehand and an Esc afterwards is pretty low overhead (compared to having to chord every single movement, change, anything). If I was still stuck on a 24x80 green screen, Emacs might have more appeal for tying everything together, but I have a Mac, with multiple terminal windows open on the desktop, so I've got the OS and the windowing environment already handled, thanks, and really just need the scarily efficient text editor.

It's like needing a bottle opener, and buying a dishwasher that's got a bottle opener mounted on the front - except the attached bottle opener isn't very good. Why not just get a good bottle opener? And Emacs fans respond with, "but look how cool the dishwasher is". Thanks, but I already had a dishwasher - a top-rated one too, I just needed a bottle opener.

(That said, I wouldn't mind seeing a version of Vim - not Emacs with vi key bindings, they're never 100%, but really actual Vim - with vimscript replaced by scheme or Python, or some such; a more rationally laid out language, rather than one organically grown over time.)

And as to PostGreSQL, I've no complaints about the speed - far from it. The big point to me is it was developed from the start by folks who were interested in safely and correctly storing (and retrieving) data, while MySQL was developed by a team who kept insisting that things like ACID compliance and explicit relationships were overrated and not really necessary. Who did things like just silently guessing what you wanted and converting data, instead of throwing errors when there were errors in the SQL queries (as well as bravely inventing their own syntax for lots of things, instead of actually implementing the SQL standard). And beloved of a generation of fanboys who would respond to the occasional rampant data corruption with "but it's really fast". Well, guess what, writing your data to /dev/null and reading it from /dev/random would be even faster (though with slightly more data corruption, but the fanboys weren't worried about that, were they). So, I have a very deep-seated distrust of MySQL, no matter how many fresh coats of paint they out on it. But I loves PostGreSQL.

So I think PostGresSQL runs just fine, speed wise, but I'd still be thrilled with it at half the speed, because I have this odd quirk of wanting to actually get back the same data that I put into the database - every time - instead of just a rough approximation.

 

[theluggage]

while MySQL was developed by a team who kept insisting that things like ACID compliance and explicit relationships were overrated and not really necessary.

Except that's a good model that hits the sweet spot for simple data-driven websites: fairly simple data structures, vastly more queries than updates, few complex updates, built-in full text search, very simple to manage. The legacy of that is that MySQL is ubiquitous on web hosting services and the DBMS of choice for off-the-shelf blogging/content management software. Sometimes the best tool for the job is the one that's actually available.

I never saw the point of the subsequent efforts to turn it into a poor copy of PostgreSQL by bolting on a completely different and not entirely compatible backend.

I'd go with PostgreSQL for everything these days, even web, but that's partly because of the availability of relatively cheap virtual private servers that let you install whatever DBMS you want.

One day I might work out the scenario where NoSQL hits the sweet spot, given how easy it is to set up a JSON or XML document store in PostgreSQL...

 

[CarlJ]

Except that's a good model that hits the sweet spot for simple data-driven websites: fairly simple data structures, vastly more queries than updates, few complex updates, built-in full text search, very simple to manage. The legacy of that is that MySQL is ubiquitous on web hosting services and the DBMS of choice for off-the-shelf blogging/content management software. Sometimes the best tool for the job is the one that's actually available.

Feature-wise, yes, a good model. Reliability-wise, losing data, weirdly converting data, or guessing what a broken query meant instead of returning an error is _never_ a good model. And they spent a long time bolting on features while it still had broken data handling. And I guess I can't really get over that. As I said before, if you don't actually care about data integrity, it's much faster and more efficient to just throw the data away and recreate from /dev/random. Databases _have_ to have reliability as goal number 1, and MySQL spent so much time ignoring that, that I will never completely trust them no matter how much they've since reformed.

 

[burne]

Databases _have_ to have reliability as goal number 1, and MySQL spent so much time ignoring that, that I will never completely trust them no matter how much they've since reformed.

That is silly nonsense. Not everybody is a banker that needs to balance the books. Many, many applications can tolerate missing or corrupt data just fine. Much of the data in the real world is wonky to start with. Ever got a correct answer from a GPS device? You are unique if you said 'yes'. All GPS data is always incorrect. Many Exabytes of incorrect data serve its users just fine. Or a customer logs web visitors in a database. Do you think he will fire his sysadmin or developers over missing entries in the database?

 

[antonis]

That is silly nonsense. Not everybody is a banker that needs to balance the books. Many, many applications can tolerate missing or corrupt data just fine. Much of the data in the real world is wonky to start with. Ever got a correct answer from a GPS device? You are unique if you said 'yes'. All GPS data is always incorrect. Many Exabytes of incorrect data serve its users just fine. Or a customer logs web visitors in a database. Do you think he will fire his sysadmin or developers over missing entries in the database?

Just to clear things a bit: data integrity within a database (and its ability to keep data like that) has nothing to do with the data being "correct". For the moment, the enterprise market needs both cases; relational databases where data integrity is critical (not only in banks, but in a huge number of applications that actually cover the majority of the cases) and the so-called nosql or big-data databases where query speed over huge amount of data is the key point (sometimes against data integrity).

 

[CarlJ]

That is silly nonsense. Not everybody is a banker that needs to balance the books. Many, many applications can tolerate missing or corrupt data just fine. Much of the data in the real world is wonky to start with. Ever got a correct answer from a GPS device? You are unique if you said 'yes'. All GPS data is always incorrect. Many Exabytes of incorrect data serve its users just fine. Or a customer logs web visitors in a database. Do you think he will fire his sysadmin or developers over missing entries in the database?

Not silly, not nonsense. I've spent my life writing software that had to give correct answers. Where coming up with the wrong answer was a problem that needed to be fixed. (Mostly financial, networking, and utility, FWIW.)

If your application has no problem with missing and corrupt data, why go to the work of storing the data in the first place - just make up answers, it will be much faster and use less space.

Your statements about GPS are missing the point, that data is known to be approximations, just like floating point numbers. You are conflating correctly storing approximations with doing a half-assed job of storing correct data. They are not the same.

Remember, if you decide that data corruption is acceptable from your database, you don't get to decide what kind it is, you don't get to say, "only corrupt things I don't care about", it could hit anywhere. MySQL started life not really caring about data correctness and data corruption on many levels.

And, fear of getting fired should not be one's only criteria for writing correct software. I hold myself to a rather higher standard.

 

[firewood]

Not silly, not nonsense. I've spent my life writing software that had to give correct answers.

And billions of dollars have been made by startup companies whose software produced questionably correct or even outright incorrect answers, as long as more answers were useful than not during the ramp up. Not every business is designing pacemakers or air traffic control software.

 

[burne]

And billions of dollars have been made by startup companies whose software produced questionably correct or even outright incorrect answers, as long as more answers were useful than not during the ramp up. Not every business is designing pacemakers or air traffic control software.

One of my customers sells advertising space on your browser by auction. If you hit a page they advertise on, they put up an auction between their customers. They include some basic info like your User Agent and general geographic region. Clients bid on the banner space, and whoever offers most can deliver an ad which is shown in your browser. The whole process of setting up the auction, gathering the bids, declaring a winner and receiving the ad takes less than 0.02 seconds. Holding up the auction because the database-server wants the last query confirmed completed on all nodes is not an option.

(They return a blank .GIF if the 20 milliseconds pass without a winner or an ad delivered..)