MySQL training courses ??

[Zoltag]

Originally Posted by ysu

hate mysql much?
I have not watched the whole thing, but the first point about nulls is a bit nit-picking IMHO. He's used to something (postgre) and now it's something else in mysql. Booo it's bad (in his opinion)

No it's not. It's different. The guy is a bit inflexible, methinks.

That's all.

Watch the whole video and then see what you think.

Oh and if you think that fields set to NOT NULL accepting NULL values, or NULL values being changed to not NULL values is fine, then I seriously hope you arent planning a long career in databasing.

[Elyzion]

Originally Posted by ysu

hate mysql much?
I have not watched the whole thing, but the first point about nulls is a bit nit-picking IMHO. He's used to something (postgre) and now it's something else in mysql. Booo it's bad (in his opinion)

No it's not. It's different. The guy is a bit inflexible, methinks.

That's all.

MySQL is a pile of shit, as the video points out. He's demonstrating common scenarios people fall into, issues raised on StackOverflow ALL the time to do with MySQL and it's stupid assumptions.

Watch the video, it's not nit-picking, it's showing MySQL vs a REAL database. That doesn't mean you can't build good systems with MySQL. You CAN. You just need to be aware of the issues when using MySQL, as shown in the video.

[ni9ht_5ta1k3r]

that's a shame though i am interested in how a user can call data from a MySQL database and enter it into an html and vice versa.

[ysu]

Originally Posted by Zoltag

Watch the whole video and then see what you think.

Oh and if you think that fields set to NOT NULL accepting NULL values, or NULL values being changed to not NULL values is fine, then I seriously hope you arent planning a long career in databasing.

I've a 15 year standing IT career - and not just databases. I'm good, don't you worry about me for a second

Oh, on your point: I do not see mysql accepting null val on a not null field, that operation threw an error.
When the guy tried to insert a row - without specifying a value to the not null string field, - it has defaulted to an empty string. That's how mysql works.

After such a weak starting argument I cannot be bothered watching the rest. Waste of time. Not to mention that would it be an article, properly written, it'd be much quicker to digest, and a much more serious-looking argument.

The fact is: it's more popular and working very well. Not flawless. Postre isn't either.

Anyway, I'm not going to waste my time with arguing haters, feel free to continue on without me. You guys either will learn that the world is not binary or not. Up to you.

[bugayev]

Originally Posted by ysu

I've a 15 year standing IT career - and not just databases. I'm good, don't you worry about me for a second

Oh, on your point: I do not see mysql accepting null val on a not null field, that operation threw an error.
When the guy tried to insert a row - without specifying a value to the not null string field, - it has defaulted to an empty string. That's how mysql works.

After such a weak starting argument I cannot be bothered watching the rest. Waste of time. Not to mention that would it be an article, properly written, it'd be much quicker to digest, and a much more serious-looking argument.

The fact is: it's more popular and working very well. Not flawless. Postre isn't either.

Anyway, I'm not going to waste my time with arguing haters, feel free to continue on without me. You guys either will learn that the world is not binary or not. Up to you.

The NULL thing is one thing, but arbitrarily changing inserted data without error is not good at all. If I have a column with precision 2,0 and try and insert 100, it should say "WHOOAH HANG ON THERE PARTNER!" not insert 99.

That kind of chicanery doesn't even happen in Access.

[elvis]

Originally Posted by Elyzion

MySQL is a pile of shit

MySQL has it's (well documented) quirks. Just like MS-SQL, PostgreSQL and Oracle all have their quirks. They're all also aimed at entirely different markets with entirely different support pricing models and complexity requirements.

And for what it's worth, I could make a 2 hour video on all the "stupid" things Windows and MacOSX do compared to Linux. (Holy crap, have I been fighting with MacOSX's forced dereferencing of symlinks which breaks so much stuff for my current industry over the last few weeks!). But the fact remains, each has a different audience, price point, and complexity requirement. Notice I put "stupid" in quotes, because in reality intuitiveness is always relative, and what I consider "stupid" may well be a well thought out design decision for someone else with a different viewpoint on the process.

If you know MySQL's limitations, and know how to work around MySQL's limitations, like most things it can be pretty powerful in the right hands (find and replace "MySQL" for the to products I mentioned in the last paragraph too). And like all things, choosing the right product for the job can save a lot of heartache in advance.

In short: Protip - MySQL is awesome for a backend to an Internet forum (guess what database is holding the text you're reading right now), but don't go building a banking platform off it.

The quirks in these videos are well known, well documented, and not hidden from anyone. From the official MySQL documentation:

http://dev.mysql.com/doc/refman/5.0/...with-null.html
http://dev.mysql.com/doc/refman/5.0/...with-null.html

A common error when working with NULL is to assume that it is not possible to insert a zero or an empty string into a column defined as NOT NULL, but this is not the case. These are in fact values, whereas NULL means “not having a value.” You can test this easily enough by using IS [NOT] NULL as shown:

mysql> SELECT 0 IS NULL, 0 IS NOT NULL, '' IS NULL, '' IS NOT NULL;
+-----------+---------------+------------+----------------+
| 0 IS NULL | 0 IS NOT NULL | '' IS NULL | '' IS NOT NULL |
+-----------+---------------+------------+----------------+
|         0 |             1 |          0 |              1 |
+-----------+---------------+------------+----------------+

Thus it is entirely possible to insert a zero or empty string into a NOT NULL column, as these are in fact NOT NULL.

I'm saddened when people don't take the time to read manuals before using products, especially considering how many man hours went into documentation. IMHO, documentation is just as important as code, and yet people seem to skip over it constantly and consistently.

Originally Posted by bugayev

That kind of chicanery doesn't even happen in Access.

And as we all know, there's plenty of other limitations with Access. Lord knows I've seen so many businesses bitten hard by limitations in that program after someone thought it would be a good idea to write a business-critical tool in Access, and then watch it fall over months later when requirements grew. But again, it wasn't the fault of the tool per se, as it was the idiot user/developer who didn't do their research and understand the limitations before they started the project.

And for what it's worth, I've seen first hand a large retail organisation (40 sites around the country containing 7+ years of point of sale data, customer data, credit card data, etc) build their entire system on Microsoft Access. Years later when it collapsed, they ported the whole thing to MySQL, which ran quite well under heavy production (not your average retailer, and during especially heavy retail seasons they moved a LOT of stock). Years later again, their management migrated the whole thing to MS-SQL at great expense. While I'm not sure the last move was entirely necessary, their CIO at the time was aiming for supplemental features (data warehouse and BI stuff) later on, and was personally familiar with Microsoft products, so I can understand the migration path from his point of view.

Point of the story: MySQL can work well under large loads - I've seen it work in places orders of magnitude larger than that again (an online gaming mob I worked for last year pushed it a lot harder across many production sites). In those particular instances, the developers understood the tool quite intimately (the retail company contracted Arjen from OpenQuery to do some tweaking and optimisation work for them at times). They understood what MySQL did well, what it did poorly, and worked to it's strengths. Could they have used PostgreSQL instead? Actually at that time, no, due to the poor replication support on offer. Today could be a different story. The online gaming mob I speak about is heavily investigating PostgreSQL instead, as it offers far superior control at a much lower level (things like how the database flushes to disk, etc) which give them better peace of mind now that they're growing much larger in customers and throughput (one of their sites pushes GBP£ 4 million per day through the system, which isn't huge by some standards, but isn't chump change either).

[bugayev]

Originally Posted by elvis

And as we all know, there's plenty of other limitations with Access. Lord knows I've seen so many businesses bitten hard by limitations in that program after someone thought it would be a good idea to write a business-critical tool in Access, and then watch it fall over months later when requirements grew. But again, it wasn't the fault of the tool per se, as it was the idiot user/developer who didn't do their research and understand the limitations before they started the project.

Oh, absolutely. My current employer has the key element of integrating three core systems for thousands of users and managing credentials held as an access database that needs to be run manually every day or users don't get their accounts provisioned correctly. Good for the time it was made, but not a permanent solution.

As with everything - the best solution, at the best time, with the best intentions.

[Zoltag]

Originally Posted by ysu

I've a 15 year standing IT career - and not just databases. I'm good, don't you worry about me for a second

Oh, on your point: I do not see mysql accepting null val on a not null field, that operation threw an error.

Only when the user tries to explicitly set the value to NULL. Implying NULL, MySQL didnt throw an error, it simply changed the data input, which may not have been the intention of the user.

MySQL does this for various other constraints as well, which makes it downright painful for anyone not intimately familiar with MySQL to debug why their database isnt storing the expected values (I would also say it trips up a fair few experts as well). In my opinion, this also encourages sloppy database design and pushes database integrity control and data validation back onto the application layer.

As others have pointed out, MySQL has its place, just not in my workplace.

[hyperstyle]

Originally Posted by Zoltag

In my opinion, this also encourages sloppy database design and pushes database integrity control and data validation back onto the application layer.

And in my opinion that's where that logic should be. I don't like logic in the database because it's not version controlled and it's less apparent what is actually going on.