October 28, 2008 at 6:39 am
While that's a nice idea that I prefer to agree with, it fails to account for the DEPTH of the stupidity I encountered, which simply cannot be "explained away" by anything other than perhaps "malice of no thought" 😀 (aka "refusal to think", as opposed to the inability to do so) ...
Steve
(aka smunson)
:):):)
jgrubb (10/27/2008)
I try to live by "Never attribute to malice that which can be adequately explained by stupidity."http://en.wikipedia.org/wiki/Hanlons_Razor
You can't "make it easy", but you can make it easier to live with.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
October 29, 2008 at 2:51 am
Asking about the attributes of MySql on a MS SQL Server based forum is a bit like asking about the attributes of Islam on a Catholic one, and many of the answers you get will be flavoured by a great deal of dogma.
I'd suggest that really the best bet would be to ask your technical specifics on the MySql forum. We run both here. MS SQL initially because we were forced to by a customer, and MySql because that's what I knew initially, and when I had the DBA function thrust on me I stuck with what I knew I could make work.
There's a time and a place for both MySql and MS SQL. It's the perception of "free" that makes MySql attractive to management, but there's another side of "if it's free it must be crap" that pervades many development communities too.
Just remember "free" doesn't mean cost-free. Training may be needed to adequately harness it - the degree of training will be dependant upon your application. While MySql lacks a lot of the the functions that come with MS SQL server, there are dozens of third-party add-ons available that more than make up for this.
As I mentioned before, I use both, and IMHO none is "better" than the other, they're different.
October 29, 2008 at 8:23 am
Yeah, we were starting to get into the realm of bashing. I do have some reservations about MySQL as general purpose DB, but other than that, it works fine. As to "Dangers", the biggest is the hidden cost of training and supporting multiple DB types.
In specific about Open Source, I prefer the direction of Postgres over MySQL, but one could call that personal. I have noted some arrogance and disdain in the O-S community, but it has gotten better, especially in the application space.
There are some things O-S does well, like infrastructure (OS, DB, Networking) and some things that have problems (Business apps, Gui's). The ones that do well are ones that are mostly Objective. Stability and connectivity are easy to agree on what is good. Business rules and "look and feel" aren't.
October 30, 2008 at 8:11 am
When I worked for an online Technical Publication Subscription service, we were faced with the same task. We were an SQL Shop and the new Exec came from a shop that converted from Oracle.
Actually we were not told to use MySQL, just to use open source. We settled on MySQL after doing a lot of research on what is available and what features there are and what bugs everyone else ran into.
There are a lot of sites out there using MySQL as the Engine. Craigslist.org is just one of them.
It can be done, just don't be afraid of the unknown. Learn about it so it is not unknown.
October 30, 2008 at 8:48 am
That sounds a lot like "the cost of learning new things is zero", because by NOT acknowledging those costs, it's EASY to recommend new things. I'm certainly not recommending never using new things because there might be a learning curve and associated costs, but I am saying that failure to understand and recognize those costs exist AND that they are NOT trivial, is a problem that a properly run business will see as an essential part of the problem's solution equation.
All too often, there are recommendations made that come with no more than "let's learn a new thing", or "it's free", when the truth is rather far removed from the statement that's made to try and justify new actions.
There's no issue if you can determine the costs of training, changes to process, and the nature of the risks of a new way of doing things, but to gloss over those critical pieces of information is to intentionally ignore things that are sufficiently important that the ignoring of them rises to the level of intentional stupidity.
That statement may well raise people's dander, and start afresh the idea that perhaps I'm "bashing open source". That's really not the case. Instead, I'm simply pointing out the fact that the most common argument used to justify O-S projects is either that "it's free", or that the cost is trivially low, or "don't be afraid of the unknown", or even that "because it's O-S, it MUST be cheaper", when none of those arguments is likely to be the least bit accurate when everything necessary is taken into account. Perhaps the MOST IMPORTANT factor to take into account is the RISK. Adopting an O-S project might make one dependent on a certain skill-set, for which one might only have ONE employee, and without knowing how many others are available in the local job market, taking that risk might mean being suddenly UNABLE to conduct business if that one employee leaves or becomes disasbled or dies. That's not the kind of risk a smart business should be taking, and that's why I have such an aversion to incomplete analysis.
Steve
(aka smunson)
:):):)
mtrafzer (10/30/2008)
When I worked for an online Technical Publication Subscription service, we were faced with the same task. We were an SQL Shop and the new Exec came from a shop that converted from Oracle.Actually we were not told to use MySQL, just to use open source. We settled on MySQL after doing a lot of research on what is available and what features there are and what bugs everyone else ran into.
There are a lot of sites out there using MySQL as the Engine. Craigslist.org is just one of them.
It can be done, just don't be afraid of the unknown. Learn about it so it is not unknown.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
October 30, 2008 at 10:03 am
smunson (10/30/2008)
Adopting an O-S project might make one dependent on a certain skill-set, for which one might only have ONE employee, and without knowing how many others are available in the local job market, taking that risk might mean being suddenly UNABLE to conduct business if that one employee leaves or becomes disasbled or dies.
But that argument is surely more correctly levelled against everything which is new to an organisation, rather than specifically against open source. And that dependency on a single individual is something every small company would recognise instantly.
Let's face it, at then end of the day, no database is free or even cheap when it comes to the level of training needed to be proficient. Even version changes incur training costs
The cost of MS-SQL licensing is what's driving me personally to move towards dropping it here if I can persuade the one insistent customer that we can deliver reliability regardless of platform. We have the luxury of having people already proficient in MySql so training costs are less of an issue. That existing proficiency was also a factor in choosing MySql over Postgre
October 30, 2008 at 10:17 am
It might be if not for the evidence I've seen that demonstrates that the vast bulk of arguments for O-S projects fell into the kinds of problem categories I've identified, as compared to the arguments for other things. Given, my exposure may or may not be representative, but it was a LOT of exposure, on a regular basis, and over a multi-decade timeframe.
FWIW... it was the consistency of those poor supporting arguments despite readily available information contradicting them, that convinces me there was more to it than just being dumb. It was repeated effort, often even AFTER the idea was publicly discredited. Nothing of that nature usually goes on for long without intent and/or hidden agenda, and I watched it happen for decades... it was a lot like the Dilbert cartoons (love those, as they've always been so incredibly on the mark).
Steve
(aka smunson)
:):):)
alec.wood (10/30/2008)
smunson (10/30/2008)
Adopting an O-S project might make one dependent on a certain skill-set, for which one might only have ONE employee, and without knowing how many others are available in the local job market, taking that risk might mean being suddenly UNABLE to conduct business if that one employee leaves or becomes disasbled or dies.But that argument is surely more correctly levelled against everything which is new to an organisation, rather than specifically against open source. And that dependency on a single individual is something every small company would recognise instantly.
Let's face it, at then end of the day, no database is free or even cheap when it comes to the level of training needed to be proficient. Even version changes incur training costs
The cost of MS-SQL licensing is what's driving me personally to move towards dropping it here if I can persuade the one insistent customer that we can deliver reliability regardless of platform. We have the luxury of having people already proficient in MySql so training costs are less of an issue. That existing proficiency was also a factor in choosing MySql over Postgre
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
October 30, 2008 at 10:51 am
smunson (10/30/2008)
It might be if not for the evidence I've seen that demonstrates that the vast bulk of arguments for O-S projects fell into the kinds of problem categories I've identified, as compared to the arguments for other things. Given, my exposure may or may not be representative, but it was a LOT of exposure, on a regular basis, and over a multi-decade timeframe.
New things cause problems, whether or not they're paid for and come in a shiny box. I just think it's a bit much to suggest that O-S = rubbish. MySql is a tried and tested product which works. It's not rubbish, but moving to it from MS-SQL or to/from any other RDBMS will cause some issues and some cost. That was the point I was trying to make somewhat ineloquently.
Given we were discussing the perils of introducing a MySql app into an a predominately MS-SQL establishment, perhaps we should leave the pro/anti O-S evangelism for another time, since we'll never agree on it anyway. 😉
smunson (10/30/2008)
Dilbert cartoons (love those, as they've always been so incredibly on the mark).
You're not kidding 😀
October 30, 2008 at 10:52 am
alec.wood (10/30/2008)
smunson (10/30/2008)
Adopting an O-S project might make one dependent on a certain skill-set, for which one might only have ONE employee, and without knowing how many others are available in the local job market, taking that risk might mean being suddenly UNABLE to conduct business if that one employee leaves or becomes disasbled or dies.But that argument is surely more correctly levelled against everything which is new to an organisation, rather than specifically against open source. And that dependency on a single individual is something every small company would recognise instantly.
Let's face it, at then end of the day, no database is free or even cheap when it comes to the level of training needed to be proficient. Even version changes incur training costs
The cost of MS-SQL licensing is what's driving me personally to move towards dropping it here if I can persuade the one insistent customer that we can deliver reliability regardless of platform. We have the luxury of having people already proficient in MySql so training costs are less of an issue. That existing proficiency was also a factor in choosing MySql over Postgre
Unfortunately, many complex O-S apps get introduced because there is no initial capital costs. I've personally been involved (over objections) in 3 companies that had O-S crammed into the org without expertise because it was "free" and "Someone said it was easy". One got our networked hacked because the "Someone" didn't think Linux needed to be patched, another spent about the same on training and consulting to setup a sendmail infrastructure as the Exchange upgrade would have been. We had a passable exchange admin. Another lost a bunch of files because "Someone" thought a journaling file system was "too much overhead"
The problem is not whether it's new, what the purchase cost is, etc. It's that the combination "free" to the financial guys and O-S Evangelists get things changed that shouldn't be.
October 30, 2008 at 11:24 am
Alec,
I'm pretty sure I've never suggested that "O-S = rubbish". It's always been the arguments for it that were, most of the time. There's certainly nothing wrong with MySQL either, provided that one properly plans for it's uses and understands it's risks and limitations the same way they understand any other RDBMS they might choose to use. I think, on that point, we're on the same page...
Steve
(aka smunson)
:):):)
alec.wood (10/30/2008)
smunson (10/30/2008)
It might be if not for the evidence I've seen that demonstrates that the vast bulk of arguments for O-S projects fell into the kinds of problem categories I've identified, as compared to the arguments for other things. Given, my exposure may or may not be representative, but it was a LOT of exposure, on a regular basis, and over a multi-decade timeframe.New things cause problems, whether or not they're paid for and come in a shiny box. I just think it's a bit much to suggest that O-S = rubbish. MySql is a tried and tested product which works. It's not rubbish, but moving to it from MS-SQL or to/from any other RDBMS will cause some issues and some cost. That was the point I was trying to make somewhat ineloquently.
Given we were discussing the perils of introducing a MySql app into an a predominately MS-SQL establishment, perhaps we should leave the pro/anti O-S evangelism for another time, since we'll never agree on it anyway. 😉
smunson (10/30/2008)
Dilbert cartoons (love those, as they've always been so incredibly on the mark).You're not kidding 😀
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
November 18, 2008 at 11:51 am
I'm new here and this is my first post.
DISCLAIMER: My background is totally LAMP - since about 1995. I've been using MySQL since the 3.x days and have never touched anything else, other than basic CRUD in DB2/SQL Server, until about a year ago when I was forced to use SQL Server 2000 and more recently 2005.
From a programming and admin perspectives, MySQL is easier.
Admin: The GUI tools are simple and I like them that way. phpMyAdmin is nice when you're on a remote PC that does not have the GUI tools installed. Replication is very simple to setup but be careful, the application needs to be compatible with the replication feature.
Programming: You can do things like SELECT LAST_DAY(NOW() - INTERVAL 1 MONTH) to get the last day of the last month. What's the equivalent in SQL Server 2005? Do you need to look at documentation to find out? This is just one example and each time you spend 1 hour instead of 5 minutes it is costing you money.
I'm not sure where the idea that MySQL is more difficult to use comes from but it certainly is not true in most cases.
For the DTS/SSIS/ETL arguments you can do most thing with your scripting language of choice. But if you really need the GUI or something more powerful, then get a third party tool, there's a bunch to choose from.
November 18, 2008 at 12:13 pm
FWIW ... early 2008 I joined a webcast regarding mysql and performance.
The main eye catcher was "to avoid joins"... because that was apparently considered for the niche "oracle / db2 / sqlserver".
Since it was only a very small system my sailing club wanted and the ISP didn't offer sqlexpress but only a payable sql2000 db or a free mysql, I still implemented a 3-nf database.
Learned a lot about it, read many books topics.
IMO, like with any RDBMS, if you want to support it, you need to get it in your fingers by learning and practicing.
btw there is a nice freeware called "toad for mysql" from Quest software. I use it in combination with the Mysql admin tool.
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
November 18, 2008 at 12:36 pm
SELECT LAST_DAY(NOW() - INTERVAL 1 MONTH)
SQL Server Equivalent: select dateadd(mm, datediff(mm, 0, @TestDate), -1)
November 19, 2008 at 8:02 am
Flammon (11/18/2008)
I'm new here and this is my first post.DISCLAIMER: My background is totally LAMP - since about 1995. I've been using MySQL since the 3.x days and have never touched anything else, other than basic CRUD in DB2/SQL Server, until about a year ago when I was forced to use SQL Server 2000 and more recently 2005.
From a programming and admin perspectives, MySQL is easier.
Admin: The GUI tools are simple and I like them that way. phpMyAdmin is nice when you're on a remote PC that does not have the GUI tools installed. Replication is very simple to setup but be careful, the application needs to be compatible with the replication feature.
Programming: You can do things like SELECT LAST_DAY(NOW() - INTERVAL 1 MONTH) to get the last day of the last month. What's the equivalent in SQL Server 2005? Do you need to look at documentation to find out? This is just one example and each time you spend 1 hour instead of 5 minutes it is costing you money.
I'm not sure where the idea that MySQL is more difficult to use comes from but it certainly is not true in most cases.
For the DTS/SSIS/ETL arguments you can do most thing with your scripting language of choice. But if you really need the GUI or something more powerful, then get a third party tool, there's a bunch to choose from.
Unfortunately, you've hit the crux of the problem. MySQL was designed for ease of use for C and Web programmers. Nothing wrong with that, but decisions were made that for people in the serious RDBMS world were critical shortcomings. Since you have been using since 3.x, you remember when MySQL didn't really support FK's, Views and Constraints. Triggers and Stored Procs weren't introduced until v5. I saw many comments from core MySQL people to the effect that Data and Referential integrity didn't belong in the DB. Many MySQL Users were of the opinion that "good" application programmers didn't make mistakes, so you could rely on them to "do the right thing" with the data".
(pause for the laughter to die down)
For a central, general purpose data store, integrity, reliability, and recoverability are Crucial. If you don't need these, the over head and expense of a full DB is hard to justify. MySQL was used primarily to serve content behind LAMP websites early on. The initial designers wanted to have a fast system that had flexible query capability for data driven sites. ACID qualities and integration were afterthoughts.
Since V5, MySQL has been on a path to a full featured DB, and is getting there. Still has a way to go in my mind. For many, if not most, users, it has come far enough. Your mileage may vary. I don't dislike MySQL. I've used it successfully many times. You do need to be cognizant of where it came from and who drives it's direction.
November 19, 2008 at 5:30 pm
jgrubb,
nice synopsis and I think you've hit it. It works well in places, just be aware of what you're getting (and missing).
Viewing 15 posts - 31 through 45 (of 46 total)
You must be logged in to reply to this topic. Login to reply