Slashdot Mirror

Your example using LIKE kinda, sorta works, sometimes. It rather slow as well.

Full text search works better and faster.

https://dev.mysql.com/doc/refm...

https://docs.microsoft.com/en-...

meanwhile back in reality, real projects at real companies continue to successfully manage their code with perforce

TFTFY.

I moved to Europe 10 years ago to work for a startup. I'm still there, still in the same job (with much of the same team, even), but now I work for the American megacorp that bought out the American megacorp that bought out my European employer.

MySQL spawned several forks and somehow hasn't been destroyed by Oracle (don't ask me how).

I think because Oracle charges a lot of money for MySQL.

MySQL will not allow table names to be passed in as parameters to a stored procedure [1] [2] [3]. Without eval, there is no way to dynamically use a stored procedure to operate over multiple, different, tables without enumerating all the tables. The code needed for the "safe" approach is massively bigger, n * m, where m is the body of your stored procedure and n is the set of tables you want to operate over. It also requires such a massive degree of code duplication to make it significantly less safe.

We have a reporting system called MyDBR that requires everything to be done in MySQL or JavaScript. Likely, a stored procedure isn't the best answer for my problems, but it's better than JavaScript. Probably the "safest" answer is to throw away MyDBR and use an actual programming environment to accomplish what I'd like (sane reporting.)

The entire premise of this article seems odd to me. Who would forget these techniques, unless they never really learned them in the first place? And why would the author want to revisit them? I think because it was a slow news day.

Both of these vulnerabilities were fixed in MySQL two months ago. I assume MariaDB and Percona have long since applied the patches as well.

So the big takeaway here is, "If you've not upgraded to the latest release yet, why the hell not?"

Both of these vulnerabilities were fixed in MySQL two months ago. I assume MariaDB and Percona have long since applied the patches as well.

So the big takeaway here is, "If you've not upgraded to the latest release yet, why the hell not?"

Both of these vulnerabilities were fixed in MySQL two months ago. I assume MariaDB and Percona have long since applied the patches as well.

So the big takeaway here is, "If you've not upgraded to the latest release yet, why the hell not?"

> an SQL query processor that uses Hadoop as storage That does not really make sense.

Would it make more sense to say "an SQL query processor which uses ext3 as storage"? The SQL side needs to get and put bytes. Some ways to get and put bytes include:
ext3
NFS
SMB
S3
Hadoop
DB2
Some other relational database.

MySQL/Maria is a SQL client, a library, a SQL parser, a query optimizer, an a network server. MySQL is NOT a data-storage format. Rather, MySQL stores data in any of many available storage engines. One storage engine you are probably familiar with is DB2, one of the best known key-value stores (which also has it's own relational front-end). MySQL can also use CSV to store it's data, deferate to another relational database, or any number of other storage engines, documented here:

https://dev.mysql.com/doc/refm...

It may seem strange that MySQL would use key-value storage or anything other than some custom-made binary format, but if you think about it even if MySQL had it's own required file format, that format lives on ext3, or ext4, or ReiserFS, or ... MySQL doesn't know how it's actually stored. After the filesystem does whatever it does with the data, it's eventually stored in arbitrary flash cells, or phonograph^H^H^H^H^H^H disk tracks, or somewhere else, and MySQL doesn't know which chunk of data ends up where. MySQL chooses to abstract away storage one level higher than the filesystem - it has no required file format. It calls get() and put(), whatever is doing the storage handles things from there.

Presto (https://prestodb.io/) is similar. Presto handles SQL queries. Presto can get it's data bytes from Hadoop to be stored, and can send bytes to Hadoop, just as you might imagine it sending bytes to a disk file.

By using Hadoop as the underlying storage, Facebook can use multiple front ends. Just as a plain text file can be read and changed by Notepad.exe, vim, or MS Word, a Hadoop data store can be accessed from a SQL front end like Presto, as a file system, via MapReduce, or other methods. They can use the right tool for each specific job, with the same underlying data being accessed.

"The question is whether red hat, oracle, or microsoft will embrace or extend their own separate ways "

There is no Red Hat SQL Server product from Red Hat. They use Mariadb or MySQL, depending upon the distribution version. So we can readily state emphatically, and with glee, that Red Hat will not embrace and extend their SQL offering ;-)

According to the MySQL website, 5.6 is the latest available production release.

I don't know the answer to your question, it sounds like you should ask the makers for their release schedule.

Hey, don't be mean! MySQL supports it as well

But Master-Master replication (you know, like you would set up in making an HA cluster)? IIRC MySQL does it, but it's a separate product that I think you have to purchase.*

* there could be a community/OSS version out there, but I kinda doubt it.

Doubt no more. Here ya go.

But Master-Master replication (you know, like you would set up in making an HA cluster)? IIRC MySQL does it, but it's a separate product that I think you have to purchase.*

* there could be a community/OSS version out there, but I kinda doubt it.

Doubt no more. Here ya go.

But Mysql / MariaDB still beat PostgreSQL when it comes to replication.

...dafuq?

Dude, MySQL didn't even get two-way replication until 5.1 (and at the time you had to jimmy with Federation and SQL threads to get even that functionality). I'm sure it may have gotten easier/better since then, but compared to psql, it still ain't all that much to write home about.

Now master -> slave replication? Sure... MySQL is easier and even more fine-grained in some aspects. But Master-Master replication (you know, like you would set up in making an HA cluster)? IIRC MySQL does it, but it's a separate product that I think you have to purchase.*

* there could be a community/OSS version out there, but I kinda doubt it.

it seems to be a heck of a lot easier to do replication with MySQL and put together a highly-survivable system.

Have you seen the massive list of caveats for MySQL replication? If that doesn't make you run for the hills, I don't know what will. But then, the typical MySQL user never reads the documentation beyond the bare minimum to make something happen, then calls it a day.

They should replace it with a nice free, open source solution like MySQL Enterprise Edition to get paid support. Then they'll never have to pay Oracle another penny (Or pence or whatever they call it in the UK)

And who owns MySQL again? (look at the bottom of that page)

They should replace it with a nice free, open source solution like MySQL Enterprise Edition to get paid support. Then they'll never have to pay Oracle another penny (Or pence or whatever they call it in the UK)

The main difference that I see is that Postgres fans generally have the same zeal and lack of experience that Rails fanboys exhibit. I am not sure where you fall but you are doing a disservice to our community by spouting false claims when you do not understand what you are talking about. (That sounds like a rails fanboy to me.)

I'm pretty sure it means you're a moron. Or rather, you should have thought a little before spouting insults.

do you know you can't rollback a transaction that modifies a table?

That is incorrect. No wonder you must have had a hard time with the tools if you don't even know the difference between MyISAM and InnoDB. MyISAM is basically BerkeleyDB with a server process over it. It is blazing fast for small amounts of data with low concurrency. It uses full table locking for inserts or updates. InnoDB is the engine that makes the differences between Postgres Maria/MySQL largely inconsequential.

The main difference that I see is that Postgres fans generally have the same zeal and lack of experience that Rails fanboys exhibit. I am not sure where you fall but you are doing a disservice to our community by spouting false claims when you do not understand what you are talking about. (That sounds like a rails fanboy to me.)

SQLite3 is a fantastic product, but it's primarily intended as an embedded SQL database, not an RDBMS. They're not really intended to do the same things.

On the other hand, at least SQLite doesn't "feature" silent non-deterministic aggregates.

PHP has plenty of problems, but http://dev.mysql.com/doc/refma... isn't PHP's fault.

I know this is off topic but...

> When RH (which is, both in business model and revenue, a small player in the IT panorama)

I continue to hear this and see absolutely no evidence of it. I see evidence to the contrary, in the US, India and Europe, over the last 20 years.
Generally, it's RPM/RH that is first listed. It's not alphabetical. This isn't because they are lucky. The simple explanation is that RH is the most frequently used and therefore put at the top as a simple matter of UI layout (most common choices go to the top of a list, within reason).

Let's just pull some random packages out of the web -

RH nearest top:
http://www.aerospike.com/downl...
http://dev.nuodb.com/download-...
http://wiki.nginx.org/Install
http://cassandra.apache.org/do... (rpm mentioned before deb)

Debian nearest top:
http://dev.mysql.com/downloads...

This is a fun game, pick me a list that shows more Debian love!
I would like to keep a pulse on things but I just don't see this assertion (that RH is the marginal market) bearing out as anything but wishful thinking.

It's baby_jesus_real_butthole(first_half_of_needle, haystack, last_half_of_needle), duh. But don't blame php for that, that's the name of the function straight from libjesus.

They still have it.

https://www.mysql.com/why-mysq...

The first item from your link:

He tries to insert 99999999999999 into a 32 bit int field, what he gets is 2147483647 stored as the value.

What do you suppose would happen in C/C++ if you have a 32 bit int, and you add 99999999999999 to it? Are you going to curse C/C++ for allowing the int to overflow?

Other databases (tested: Firebird 1.5rc4, Oracle 8.1.7 and PostgreSQL 7.4) raised errors with the same data.

Allow me to introduce you to strict mode: http://dev.mysql.com/doc/refma...

Which has been available for almost a decade.

You're like a dog with a bone. Last time I worked with MySQL was 5.0.1, and it was letting people insert ASCII strings into integer fields, and every time people expressed concerns, all you saw was rhetoric about how that should have been dealt with at the application layer. Which is fine if you're setting up a web forum, but not when you're organizing an enterprise that spans the world and has numerous applications accessing it, where one junior programmers mistake can hose your whole fucking enterprise. No client has mandated that I MUST use it since, therefore, I haven't used it since, and asked a serious question.

The history of MySQL was very well summed up in an earlier post: "ACID is hard, therefore we don't do it."

Not just me... most professionals know this and accept it and know that not every tool fits every scenario. Don't know what YOUR fucking problem is.

The first item from your link:

He tries to insert 99999999999999 into a 32 bit int field, what he gets is 2147483647 stored as the value.

What do you suppose would happen in C/C++ if you have a 32 bit int, and you add 99999999999999 to it? Are you going to curse C/C++ for allowing the int to overflow?

Other databases (tested: Firebird 1.5rc4, Oracle 8.1.7 and PostgreSQL 7.4) raised errors with the same data.

Allow me to introduce you to strict mode: http://dev.mysql.com/doc/refma...

Which has been available for almost a decade.

mysql_real_escape_string is a wrapper of a C function. Does that make C the laughing stock for you as well?

Wrapping your house in toilet paper would make your house a laughing stock ... that doesn't mean your house is now though

mysql_real_escape_string is a wrapper of a C function. Does that make C the laughing stock for you as well?

I keep saying this on Slashdot: PHP has it's weaknesses, but inconsistent naming conventions isn't a major problem. What made PHP the laughing stock is looking at incompetent coders' code and thinking that's how you do things in PHP.

PHP is a good language for web development. It has an easy learning curve and gives you power to shoot yourself in the foot. Combine those two and you get a bunch of atrocious code floating around the web from the hands of incompetent. But you also get rapid development with very readable code where new programmers can easily jump in in the hands of competent.

P.S. mysql_real_escape_string is now deprecated. PHP has come a long way since its atrocious beginnings and TFA talks about that (clue is in the title).

I don't know what database technology they are using but if they are using SQL, they are probably using an ENUM: http://docs.oracle.com/cd/E179... https://dev.mysql.com/doc/refm... http://www.postgresql.org/docs...

The "problem" with Postgresql is the Postgresql developers/team are more likely to present a realistic picture of things.

Those who really know about clustering will know it's all a bunch of compromises.

Just because MySQL fans paint a rosier picture doesn't mean the MySQL situation is really that much better: http://bugs.mysql.com/bug.php?id=25543 https://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-replication-issues.html

MySQL has had replication as a built-in for a long time, and I encountered such a system at work when it was 3.x. BUT the clustering system seemed to cause more problems than it solved - stuff kept getting out of sync or the syncing completely stops. Was someone else's job to maintain it, but I had to help fix it from time to time...

Might be better now, but point is MySQL implied it was fine back in 3.x despite its crappiness.

I don't doubt what you say (I don't have the expertise to judge it) but I should have pointed out that the number of people who really need clustering (as opposed to hot or warm backup) is very small. We realised that beefier hardware with hot backup was a much easier solution. Our DB expert tells me that the number of people who need a scalable conventional SQL cluster is getting to be a really small niche, with single-node systems improving and eating into the bottom half and NOSQL systems eating into the top.

The "problem" with Postgresql is the Postgresql developers/team are more likely to present a realistic picture of things.

Those who really know about clustering will know it's all a bunch of compromises.

Just because MySQL fans paint a rosier picture doesn't mean the MySQL situation is really that much better: http://bugs.mysql.com/bug.php?id=25543 https://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-replication-issues.html

MySQL has had replication as a built-in for a long time, and I encountered such a system at work when it was 3.x. BUT the clustering system seemed to cause more problems than it solved - stuff kept getting out of sync or the syncing completely stops. Was someone else's job to maintain it, but I had to help fix it from time to time...

Might be better now, but point is MySQL implied it was fine back in 3.x despite its crappiness.

I don't doubt what you say (I don't have the expertise to judge it) but I should have pointed out that the number of people who really need clustering (as opposed to hot or warm backup) is very small. We realised that beefier hardware with hot backup was a much easier solution. Our DB expert tells me that the number of people who need a scalable conventional SQL cluster is getting to be a really small niche, with single-node systems improving and eating into the bottom half and NOSQL systems eating into the top.

The "problem" with Postgresql is the Postgresql developers/team are more likely to present a realistic picture of things.

Those who really know about clustering will know it's all a bunch of compromises.

Just because MySQL fans paint a rosier picture doesn't mean the MySQL situation is really that much better:
http://bugs.mysql.com/bug.php?id=25543
https://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-replication-issues.html

MySQL has had replication as a built-in for a long time, and I encountered such a system at work when it was 3.x. BUT the clustering system seemed to cause more problems than it solved - stuff kept getting out of sync or the syncing completely stops. Was someone else's job to maintain it, but I had to help fix it from time to time...

Might be better now, but point is MySQL implied it was fine back in 3.x despite its crappiness.

The "problem" with Postgresql is the Postgresql developers/team are more likely to present a realistic picture of things.

Those who really know about clustering will know it's all a bunch of compromises.

Just because MySQL fans paint a rosier picture doesn't mean the MySQL situation is really that much better:
http://bugs.mysql.com/bug.php?id=25543
https://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-replication-issues.html

MySQL has had replication as a built-in for a long time, and I encountered such a system at work when it was 3.x. BUT the clustering system seemed to cause more problems than it solved - stuff kept getting out of sync or the syncing completely stops. Was someone else's job to maintain it, but I had to help fix it from time to time...

Might be better now, but point is MySQL implied it was fine back in 3.x despite its crappiness.

Well, fuck you, MySQL can't do that.

Yes you can - since version 5.6.6 (2012-08-07)

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-6.html

I don't think it's possible for MySQL to get the "C" part in ACID right without a total rewrite, which seems unlikely under Oracle's watch. There used to be all sorts of trivial ways you could insert garbage data into MySQL, things like February 31 being a valid date or numbers going into boolean fields. They added this strict mode as a way to add validation for most of that. But strict is a client setting. All it takes is one client that ignores this, and the engine will still let you put garbage into there--values that are not going to be valid if you later work on them using a strict setting client. If you can put data in one end of that's not correct when read by another client, that's the exact opposite of a "consistent" database. It boggles my mind that anyone finds this acceptable. I guess people who do all their validation on the client are fine with it maybe? I can't explain how people who don't understand databases at all make their decisions.

I don't follow MySQL closely enough to know if they're still silently truncating data sometimes too, but that's been a nagging problem over the years too. Strong validation of data is like security: you don't just bolt it on later. It's something that needs to be enforced in as many places as possible in the code, if you want any hope of getting it right and bug free. If you actually want data to be validated in all situations, you need to use something like PostgreSQL instead. There even new types you add to the database can execute any check constraint function you want before that data is allowed in, period. That overhead contributes to why MySQL is faster on trivial things, but sometimes you get what you pay for.

And for the most part, everything Just Works.

"For the most part" meaning "Apart from all the things that don't", I presume? Then there's insanity like how excluding certain databases from replication goes by which database is set as the default, rather than on which database you're actually modifying, large deletes or updates on a large unindexed table send it into la-la land (OK, not generally a great idea in the first place, but easy to do by accident if you're experimenting), having to lock out writes on the master for as long as it takes to complete a mysqldump in order to set up the slave....

I can only assume you're a typical MySQL idiot who has no idea what he's doing, never read the documentation, and is generally oblivious to everything that can go wrong. Whenever something does fail, you probably just hack up a fix and go on your merry way without ever considering that maybe if you chose a sensible database in the first place these things wouldn't keep happening.

And for the most part, everything Just Works.

"For the most part" meaning "Apart from all the things that don't", I presume? Then there's insanity like how excluding certain databases from replication goes by which database is set as the default, rather than on which database you're actually modifying, large deletes or updates on a large unindexed table send it into la-la land (OK, not generally a great idea in the first place, but easy to do by accident if you're experimenting), having to lock out writes on the master for as long as it takes to complete a mysqldump in order to set up the slave....

I can only assume you're a typical MySQL idiot who has no idea what he's doing, never read the documentation, and is generally oblivious to everything that can go wrong. Whenever something does fail, you probably just hack up a fix and go on your merry way without ever considering that maybe if you chose a sensible database in the first place these things wouldn't keep happening.

And for the most part, everything Just Works.

"For the most part" meaning "Apart from all the things that don't", I presume? Then there's insanity like how excluding certain databases from replication goes by which database is set as the default, rather than on which database you're actually modifying, large deletes or updates on a large unindexed table send it into la-la land (OK, not generally a great idea in the first place, but easy to do by accident if you're experimenting), having to lock out writes on the master for as long as it takes to complete a mysqldump in order to set up the slave....

I can only assume you're a typical MySQL idiot who has no idea what he's doing, never read the documentation, and is generally oblivious to everything that can go wrong. Whenever something does fail, you probably just hack up a fix and go on your merry way without ever considering that maybe if you chose a sensible database in the first place these things wouldn't keep happening.

And for the most part, everything Just Works.

"For the most part" meaning "Apart from all the things that don't", I presume? Then there's insanity like how excluding certain databases from replication goes by which database is set as the default, rather than on which database you're actually modifying, large deletes or updates on a large unindexed table send it into la-la land (OK, not generally a great idea in the first place, but easy to do by accident if you're experimenting), having to lock out writes on the master for as long as it takes to complete a mysqldump in order to set up the slave....

I can only assume you're a typical MySQL idiot who has no idea what he's doing, never read the documentation, and is generally oblivious to everything that can go wrong. Whenever something does fail, you probably just hack up a fix and go on your merry way without ever considering that maybe if you chose a sensible database in the first place these things wouldn't keep happening.

Berkeley DB is often used as a back end for MySQL.

[Citation needed]

[Citation given]

http://dev.mysql.com/doc/refman/5.0/en/bdb-storage-engine.html

Although it disappears from the manual after 5.0. The conspiracist in me would think the removal had something to do with an impending license change. Hmmmmm.

It already was GPL-compatible, so that part hasn't changed. They've gone from a more liberal license (the old license was compatible with, among other things, the GPL v2) to a less liberal one. That's always going to piss off some people. Just look at the controversy when a project goes from BSD or MIT to GPL.

Where was the outcry when MySQL AB switched their client library from LGPL to GPL?

http://lists.mysql.com/mysql/120620

There was some,

http://www.infoworld.com/d/developer-world/open-source-lock-in-134

but Monty needed $$$$. So now he has money, and look what happens,

http://openquery.com/blog/mariadb-client-libraries-end-duallicensing

client library is now LGPL again - perhaps just to piss into Oracle's pond.

But I get it, whatever Oracle does is bad. Whatever other people do that is similar, is good.

Nothing to see here, move along. People can always use SQLite or PostgreSQL. Oh wait, they were for last 10 years.

mysql_real_escape_string()

That one's MySQL's fault.

... because someone noticed it.

That's true of all bugs, in the abstract. If a tree falls in a forest, and all that. This seems like a legitimate answer -- remember that they maintain a separate repository for their commercial offering. It's entirely possible someone fat-fingered during compilation.

Never attribute to malice that which can be explained by stupidity.

You're right. This is an unintentional change that will be reversed. http://bugs.mysql.com/bug.php?id=69512

Agreed. Even the webpage still says that it is GPL.

Also, Mysql replication is very well established and easy to do

MySQL replication is horrifically fragile.

Yup. Triggers since 5.0.2:

https://dev.mysql.com/doc/refman/5.0/en/triggers.html

PHP is not getting a lot of love, especially here on Slashdot, and Drupal is one of the reasons to blame. Sure, PHP has its fair share of design flaws, but ever since version 5, it's a decent enough language to code in and can get a lot of done.

The problem is with Drupal, Wordpress, Joomla and other very popular CMSs and frameworks which are all a strange mix of procedural and oo code, and lack a proper distinction between model, views and controllers.

Its problems are certainly not the things that are often quoted, like mysql_real_escape_string (which just follows C api and is deprecated anyway), or inconsistent naming conventions. The problems are deeper - things like lack of threads comes to mind.

Still, the reason why I like PHP is that with a good framework (e.g. Zend Framework 2 is promising, but there is also CakePHP, FuelPHP, CodeIgniter, etc.) you can build a very solid application. Procedural PHP is actually a fantastic and very powerful template engine and otherwise you can write relatively clean and easy to read code in it if you structure the program correctly. It's very simple to deploy (especially compared to e.g. RoR) and has extensions for pretty much any database or graphics library or anything else a web developer may need.

If one does dump to XML, what's the best way to load that into a new slave or do a restore from it?

Using 5.5.28 here...

LOAD XML INFILE might be what you're looking for.