When was mysql 5.1 released
Time to check the startup guides. Well, one just has a single password change, another has 3 or 4 lines of 'delete from user The reference for GRANT just has a bunch of caveats and warnings, and the "User Account Management" section goes on and on and somehow doesn't manage to tell me what I want to know.
I decided my time would be better spent eliminating the MySQL-isms from the app in question so that it can run on Postgres like everything else on the server. Some of it I'm not sure how it ever worked. I spent much of last night doing my third Postgres install.
It took me roughly one and a half hours to get it to where I wanted it, with a user that can access it over the local network and an empty database from which to build my app. My third mysql install took roughly 20 minutes to get to that point, and that was a few years ago when I didn't know half as much about databases as I do today. I don't know what the general trends in the population are, but for me and the people that I've dealt with, MySQ.
You are both essentially in agreement, and what you're saying boils down to "I'm used to X, and when I tried to do the same thing with Y, which I'm not used to, it took me longer that it would have done with X". I've used both systems a fair bit.
As a sysadmin I find MySQL easier to work with, because the way the data files closely mirror the structure of the database, and it doesn't mind too much if you tar up a database, copy it over to another. The manual seems to describe this in the connection access [mysql. It answers your question on precedence most specific to least specific, first match wins , but not the others.
That's a good goal when designing a system that has to integrate into and with 3rd-party systems. However, doing so for an in-house app is stupid, as you won't be able to take advantage of any of the features of any particular RDBMS. In that instance, I think it's better to simply isolate the RDBMS-specific bits rather than leaving them out altogether.
I've heard this a few times. Every time, the process has been:. But yeah, it is about as easy to me as mysql. Although, the primary deployment for MySQL seems to be running on the same machine as the web server. The default config isn't secure if you have untrusted users on the machine i.
My favorite auth method for server-in-a-box is "ident sameuser" over UNIX sockets. In that case it seamlessly integrates with the OS's underlying securi. It just does things differently, the storage space is configured in files and databases are created with SQL queries. I see that compared to this, pgsql requires some additional setup before getting at the SQL prompt.
If they've used MySQL and nothing else, they're probably self taught and don't really understand what they're doing. Oracle and MySQL were the worst.
Oracle because it was just horrible to install, MySQL just because it was hard to install in a configuration with even a hint of ACID compliance at the time. It was that experience trying to configure MySQL for data integrity that caused me to dump it and move to Postgresql. One thing I like about postgresql vs MS Sql is the triggers. Pg triggers are per statement or per row, before or after. There's also a rule system and the ability to rewrite the query, for updateable views or other tricks.
The lacking features are clustered indexes, replication, and partitioning. I'll also mention hash indexes -- it has them, but they're not journaled, and they're not generally recommended. I'm not going to comment on MySQL s.
PgSQL is not the only, nor necessarily the best open source choice. There are DB2, Firebird, Ingres, and dozens more. Some of them have mature implementations of the features new to 5. MySQL is a very valid choice also, for a variety of reasons that you may not have considered.
Or are you saying Facebook, Flickr, Yahoo! DB2 isn't open source. There are ups and downs to any project. When I had a Postgres database to admin, I was told to look into replication. Maybe it was just his short-sightedness or cluelessness, but it sounded like the same. Log shipping. Postgres has had Slony for replication, and has done so for years.
The worst thing about MySQL replication was that when it crapped out, it would not issue any warnings and provided n. When an open source project is shipped with major bugs though, what do I hear? Is it just possible that people who develop open source are human, and make the same decisions, for the same reasons, as their closed-source counterparts?
Which might lead to the conclusion that different methods don't necessarily yield different results; ie, that open source innately presents no inherent technical advantage over closed source, only social and legal advantages. Uh oh I think that's my cue to post and run now I think the difference is that a lot of open source projects operate on a release-early-release-often philosophy - what software engineers refer to as the waterfall model.
In such a scenario, bugs will appear in earlier releases and decline in number sharply over time. Closed source projects tend to operate on the more classical release schedule, which tends to be a lot slower with a lot more expansive software lifecycle, but SHOULD produce far far fewer bugs in each release. I think the difference is that a lot of open source projects operate on a release-early-release-often philosophy.
Waterfalling is a relatively rapid cycle between implementing and testing in small stages, each stage feeding into the next, as a cascading series of waterfalls. The RASDIT software life-cycle states that after testing comes deployment, after deployment you go right back to the start and re-assess requirements. There is no direct feed between one cycle and the next you re-us.
It is possible to write software this way and you will have a very high probability of producing robust, reliable, efficient code. It probably won't be maintainable, but it will very likely work and work damn well. Which is why the "maintainable" is such an important element. The theory is that even though this method is slow, the software will converge on the users' needs as the amount of fresh code required will drop with each full cycle.
It's entirely possible this is the methodology used in mission-critical systems, such as power stations, as you don't want to patch often and the requirements will change ver. But you gotta put this all in perspective, some glib talk about how everyone is equal in the eyes of bugs just doesn't apply here.
First off, the context. We're talking about a database, your warehouse for your most valuable asset. This is not a place where you want to encounter mistakes, and caution is the word. You might hear excuses for some, but those people are idiots. If you read the article, the things he says basically boil down to "this product is as stable as a house of cards and if you use it, treat it with all the care and caution you'd give a newborn child.
Honestly, I think I'm gunna be sick. I don't care if MySQL is a good product or a bad product as such, I only use it for stupid things that do not matter at home, like my MythTV, never ever on anything that could be called "production. These people should just come out and say "there's no explanation we can give, this is crapware and we're really sorry if you got hosed by it. Don't use it at all if you aren't already.
I only use it for stupid things that do not matter at home, like my MythTV, never ever on anything that could be called "production. I wish applications like that would stop using MySQL and server-based databases in general , but I don't think there's a good alternative that isn't written in Java that supports multiple simultaneous connections.
I like the approach used by the Java embedded H2 database engine [h2database. It is quite likely that the people who jump all over proprietary software that has a poor quality release are not the same people as the one's who are defending MySQL. It's like if you ask me for directions, and I send you in the wrong direction and make it sound like I know what I'm talking about. You would probabl. It just has them on a different scale and there's a different release.
If you look through the past release notes for pgsql, you'll see that occasionally one release would come out with some horrific server crashing bug, get reported and get fixed.
Now, the timeframe is what is the key. For MySQL there are server crashing bugs that have been in place since or before. For PostgreSQL, once such a bug is documented and reproduce-able, it is generally squashed in hours, days, and occasionally, for really complex problems, in a week or so. Instead of cursing every product with which a writer has had bad experiences, the key to reducing grief is to remain aware of the likely risks and rewards of each approach.
We can be as relativistic as we want, as though every system is a snowflake with it's own beauty, but in the real world, sometimes value judgments are useful. For instance, if you design a truck and I design a car, we can both respect each others' designs, and differ on opinion. You might prefer towing capacity, and market that benefit to construction workers and farmers. I might market the fuel economy and handling to commuters.
If someone designs a car that sometimes explodes when it rains and the steering wheel in the trunk, it's a bad design, period. What happens if KDE crashes and burns? You revert to a working version, or pick up some other desktop environment. If you're a novice, maybe you are in trouble. A desktop carries very little state -- and even less important state -- so switching back and forth doesn't cost much.
The costs of the scary problems Monty mentions could be arbitrarily high. If you lose data, or an application goes down, or you produce a wrong result and then base a decision on that wrong re. There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead. Try the CryptoTab Browser.
It works like a regular web browser but mines Bitcoin for you while you browse! Works on all devices. Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool and take advantage of SourceForge's massive reach.
Follow Slashdot on LinkedIn. This discussion has been archived. No new comments can be posted. MySQL 5. Full Abbreviated Hidden.
More Login. Score: 3 , Interesting. Share twitter facebook. Re:"Fair and balanced" summary?? Score: 5 , Insightful. Parent Share twitter facebook. Score: 4 , Insightful. Re: Score: 2. And still having so many of these problems after a 3-year release cycle doesn't look good. Score: 4 , Funny. Score: 5 , Funny. Re: Score: 2 , Insightful.
Wait a minute Score: 5 , Interesting. With all due respect to Ryan, I agree with Monty here. Not just 5. What's more, some of those bugs like the one [mysql. Score: 3 , Informative. You call software that can bring down multiple slaves with a drop table statement [mysql. Have fun with that. Except MySQL supports permissions [mysql.
As Ryan said there is no such thing as bug free software Some of the bugs in Monty's list are pretty scary. Your standards for a DBMS are different than mine. I would really like to read about a specific bug Monty spoke of, but it looks like they secured this bug information from the public.
Score: 2. By arrive do you mean "GA" or "actually works"? Re:well Score: 5 , Insightful. Re: Score: 2 , Funny. While we are using car analogies: If your car dies, just do what microsoft suggests, and close all of the windows.
Re:well Score: 5 , Informative. Beta Quality Score: 2. Re: Score: 3 , Insightful. Everyone here knows what he's talking about when he says "beta". It'll be a few years at least before people who know the term "beta" will get confused by TFA's use of it, and it'll be much longer than that before anyone on this forum will get confused.
It's entirely possible, even likely, that the trend will reverse itself in that time. I haven't seen any other site abuse the term as badly as Google, and most places use it properly. Wow Score: 5 , Insightful. Re:Wow Score: 5 , Interesting. Re: Score: 3 , Informative. Because different people have different needs. At the beginning of an application's lifecycle, it's very likely that they'll want a simple database that anyone can set up and use.
However, as the application grows up and the developers get more experience and more experienced developers get hired on, they start to wish for some of the more advanced features. In addition, since MySQL got so popular so quickly, develope. Re:Wow Score: 4 , Informative. That's only using the client which hides the actual queries from you. I've used MySQL for years So you'll know for next time If you mention the issue, who knows?
Maybe it will be fixed. Usability or documentation issues are not always obvious to the developers Re:Wow Score: 5 , Informative. Now, 6. You can create users and databases from inside pgsql. The createuser and createdb scripts are just wrappers around this. How does MySQL simplify this? I've wondered about this in the past. Should I be working with Postgre instead? What are the compelling differences, and how do they stack up against SQL Server with things like stored procs, triggers, and man.
There were , downloads in the last 10 days, so thank you for the vote of confidence. As we move forward, I know we will continue to improve our release processes, and benefit from the input of our users and from additional resources at Sun.
I expect there will be some interesting stuff coming out of the labs at Sun as they do more optimization of MySQL in conjunction with Sun servers and storage. It's exciting to see the collaboration between software engineers and systems guys when they drill down on issues like performance and scalability down to the microcode level. But I'm getting ahead of myself Here are the latest Insider stories. More Insider Sign Out. Sign In Register. Sign Out Sign In Register.
Latest Insider. Check out the latest Insider stories here. More from the IDG Network. What a year! Solaris exec touts Unix platform's strengths. Flame war: The great Windows 7 debate. Related: Open Source. How to choose a low-code development platform.
0コメント