MariaDB inhales $25m. 'People tried to get away with simpler' but now there's a 'relational renaissance,' says open-source biz chief MySQL cousin MariaDB has grabbed $25m in funding in what represents something of a mini fight-back for good ol' relational databases against the NoSQL family of systems, according to the CEO. Speaking to The Register, Michael Howard claimed a "renaissance" in relational databases was taking place. "It started a couple of …
Not really, MySQL was for a long time not at all ACID compliant and even when it did add support for it, it wasn't very good: slow with global locking. MySQL was optmised for fast writes from the get go, so basically the same space as the NoSQL toys of today.
I used it on some 300,000 products with 20 odd parameters and 30,000 customers with long sales histories. It worked pretty well for that. ISTR it did multiple of ten transactions a second against a vb web frontend, about 3 times what SQL Server could manage on the same data/indexing etc. I dont recall any bugs but it was left running over a weekend, as was the SQLserver which had about four times the ram and a supposedly faster processor. Anything alkaline would have been useless for the job in hand.
I'm not disputing that it could work but MySQL didn't approve of it. IIRC you could get a support contract with the guy who came up with InnoDB (and later Oracle who bought it before they bought Sun).
The first versions of SQL Server were shit but without precise dates it's difficult to say, but if you're talking about a VB website then I reckon you're not talking about the mid-1990s. But there mere existence of the tools for fixing corrupted databases hints at some of the problems.
Schema changes with InnoDB were (and probably still are) a particular nightmare.
The more that you learn about MySQL, and, by extension, the cruft that they haven't yet managed to chuck out of MariaDB, the more you discover that it's a bit nastily hacky in rather a few ways.
For example, I only very recently discovered that MariaDB's initial implementation of UTF8 is a bit insane, and they didn't exactly shout about eventually fixing/bodging it (a bit like all those rubbishy PHP tutorials and books that were still wittering about using the 'mysql' functions while the deprecation clock was already ticking):
https://medium.com/@adamhooper/in-mysql-never-use-utf8-use-utf8mb4-11761243e434
In a way, it's rather sad that MySQL gained so much "brand awareness" at the expense of everything else. There are so many FLOSS projects that seemed to choose it just because everyone else did, when they really would have been better picking PostgreSQL, or a sensible database abstraction layer, instead.
I've done both the 'simple text file' method AND SQL databases for decades. It's really all based on the need.
If you have a bunch of text data, you can often use simple command line tools and shell scripts. Sometimes that makes the most sense. I've done a lot of analysis on data like that.
Sometimes the SQL utility can be used to 'spit out' the columns of data that another tool can crunch to provide charts, etc. and now you have a 'hybrid' solution that is controlled with a shell script or PHP backend.
It's all based on what the needs are. Having to pick one or the other isn't very creative.
(My preference is PostgreSQL though, for the SQL side)
Main point, of course, is that one or the other solution isn't "superior", just different.
(the most fun solution I did, multiple times in fact, was to create a series of time-based 3D charts from x,y,z text data using gnuplot, then string them together into a video using mencoder's "bunch of jpegs" feature, and play the video to watch the changes in the chart output over time. Built with shell scripts. at the end I added background music to the video to make it more fun. However, watching the video led me to discover a software bug in how the IMU data was being interpreted. Who knew?)
I agree with you, Bob, and have upvoted accordingly.
However I suspect the non-SQL stuff they are talking about is not text files etc., but the document databases like MongoDB. Your underlying point about picking according to need and not your database religion is sound either way.
Databases like MongoDB take JSON data which in the end is just a text file.
Being unstructured it’s less complicated to partition and shard out at the database level. In practice the scaling out with hardware, redundancy and the nodes required to keep track of where your data is gets fiddly very quickly. Especially if you are in cloud and you need to make sure you are not having redundant nodes too close together.
Document databases do give you typing but they suffer from the same problems they had in the 1960s when Cood proposed the relational model.
In practice, the real focus for NoSQL is currently with time series stuff where realtime OLAP is valuable.
@werdsmith
Of course Axmark is worth mentioning and so is Larsson regarding MySQL.
Quoting the Wiki:
"After dropping out of Helsinki University of Technology, Widenius started working for Tapio Laakso Oy in 1981. In 1985 he founded TCX DataKonsult AB (a Swedish data warehousing company) with Allan Larsson.[1] In 1995 he began writing the first version of the MySQL database with David Axmark, released in 1996. He is the co-author of the MySQL Reference Manual, published by O'Reilly in June 2002; and in 2003 he was awarded the Finnish Software Entrepreneur of the Year prize"
When referring to peoples education it's quite normal to mention the University, if there was one.
One could also add that InnoDB started in Finland.
I love SQLite. When I had to maintain a website for thousands of square dances etc. I thought I would learn SQL for the fun of it. So I put all of the information in an SQLite database and generated web pages from the database.
Best decision I ever made. If something needs to change or page headers need to be replaced I just modify the appropriate place in the database and regenerate the website. When one of our round dance cuers got married I changed one entry and, presto, everywhere she showed up on the website was changed.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
