Stusser, umm… yeah. Really… you need a good nickname - mySQUEEL!!! how about that? I hate to stand in the way of a zealot spreading ignorant hate, so go at it man. Us morons will will just keep playing with our “toy”… oh if only we did it for real money like you…
Chet
Yes, it was crazy of me to respond, like an ignorant bum pretending to be a vietnam vet, that wasn’t meant to be offensive at all.
Hey, I do it for a living, I have strong opinions.
I didn’t mean to imply that your business is piddly-shit. You own your own business, I work on salary, it’s very likely that you make more than I do. Don’t get all bent out of shape, I wasn’t looking to compare dick size, I’m just talking about databases.
Paging Dr. Liz!
I too do it for a living, and with Oracle also, and I’ve got nothing against MySQL. MySQL is light years away from competing with Oracle or being able to offer the same enterprise features but a Ford Mustang is light years away from being able to tow the same load as a Hummer. Doesn’t mean there is anything wrong with the Hummer or the Mustang.
One of my main gripes with MySQL is that it won’t throw an error when you feed it bad data, it’ll mangle it and insert it into the database without complaining instead.
As for MySQL being much faster than PostgreSQL, I’d like to see some (recent) benchmarks to back that up.
MaxDB is pretty good, but then it wasn’t made by the same people. MySQL AB bought SAP DB and renamed it.
Anyone who has used the jet engine with any significant table size and then claim it is better than mysql???
For what it is, Access is fine. When you need it use something as central repository holding large numbers of rows (ie millions) in tables and being accessed by a reasonable number of people then Access is a fucking nightmare to keep running let alone support.
Wow and I thought it was only on Usenet where you have to circumscribe every statement you make with caveats and reams of context so as to provide the correct interpretation to all possible questions.
Meanwhle, back on topic (which wasn’t the relative merits of databases and DBMSs, but this user’s requirements):
It’s for my job. Right now, we download tables from SQL Server databases into MS Access, then we normalize the data using Access queries. Right now, all told, I have 3 Access databases all about 750mb (after compacting, it’s over 1,000mb each not compacted) that downloads the data and normalizes the data, not to mention the user conflicts that occur. It’s really inefficient and I think MS Access is reaching it’s size limits. I work for a large corporation and our IT department has each of us locked down real good, so I can’t get SQL Server or Oracle since I’m in Finance. So, I need something like Access but with better database functionality, size and data normalization features.
(my emphases at interesting places).
Can you tell us (in broad terms) what this data is? Since you’re in the Finance department I would have thought any, um, Financial things would be handled by your existing systems, whatever they are. So this stuff is additional analysis beyond what those systems produce? I’m guessing here.
I think when you say ‘normalize’ you actually mean ‘transform’ into a format you can query off more easily. But when you say ‘user conflicts’ that sounds like you are actually updating the data, which isn’t consistent with just query analysis. Multi-user updating is probably Access’ biggest weakness (this is being polite); I’d say it’s that problem you are seeing, rather than necessarily size limits. I have read-only Access databases of hundreds of meg that perform fine.
I’d suggest that since this data you want to transform and examine is already in your corporate SQL Server, it’s really a job easiest done by your internal IT chaps to provide you with the means to get the information you want. Pulling data out of SQL Server and then looking for a database to put it back into seems… redundant.
MySQL with myisam tables is faster than pretty much everything. With InnoDB it’s roughly the same speed as oracle, sql server, db2, etc. Postgres used to be incredibly slow, now it’s pretty competitive on speed.
Nick, I question whether you’ve had to support clients trying to use mysql in the enterprise. It’s a frickin’ nightmare.
Pulling data out of a production db to put it in another for analysis and datamining is extremely common; it’s called a reporting db.
Depends on what you mean by “in the enterprise”.
If we are talking about enterprise in the sense of a database with an SLA of five nines, 0% tolerance for lost transactions, heavy update loads, and complex schemas, then no I have no supported such a database. Nor would I, that’s would be nuts. MySQL isn’t suited for such an environment. MySQL isnt an enterpise database in that sense.
There’s lots of room for databases that don’t have full enterprise features. I’ve supported application databases that can tolerate 12+ hours of downtime a day, databases that can lose 5% of transactions and still be considered to be running acceptably, etc. It all depends on the business needs of the client and the application. MySQL can be a great solution with great cost savings and good performance in those environments.
Yep I think we agree on that, mysql is appropriate for some uses and not for others.
I have been forced to support mysql in the enterprise, and it leads to staying up all night two to four nights per week, constant conference calls with unhappy clients who blame me and not the db… never again.
Absolutely. But here we’re suggesting pulling data out of a production dbMS and then putting it in another dbMS, which just seems silly.
Maybe it’s one of those evil ultracorporate places where IT guard the gates to the data with slavering three-headed dogs or something. In which case, yeah I’m out of my depth as how best to operate in such an environment.
Absolutely. But here we’re suggesting pulling data out of a production dbMS and then putting it in another dbMS, which just seems silly.
Maybe it’s one of those evil ultracorporate places where IT guard the gates to the data with slavering three-headed dogs or something. In which case, yeah I’m out of my depth as how best to operate in such an environment.[/quote]
No. At my company (running Oracle, about a million customer records, several tables over a million rows, chewing through tens of thousands of batch records a day), we already have a totally different set of tables for reporting than for normal operations, and an entire process for populating and maintaining the reporting tables. We will soon be moving those tables into their own database, because the reporting DB load is orders of magnitude more query intensive than the normal transactional load, and we don’t want the insane reporting queries munging performance for our batch runs.
This is totally standard enterprise data warehouse dogma – see this article by a warehousing guru for the basics of why.
Cheers!
Rob
Yes, it’s very common. We normally use materialized view replication or logical standbys for reporting dbs. This allows us to separate load from production and reporting uses and also minimizes risk from users running adhoc shit in the production environment.
Different tables - of course
Different db - highly advisable
Different server - absolutely
Different DBMS - ??
I guess IT won’t let them have their own SQL Server.
MySQL Gotchas < mysql gotchas
A story on the street? I’ve been a DBA longer than I can remember and you are fooling yourself if you think mysql is a real rdbms like Oracle or DB2.
And the final nail in the coffin for postgresql, igor suggests it. Has he ever had a clue about a single thing he posts about? No. And now is no exception.
No, but this did make you look like you don’t know what you’re talking about. Next time bring some evidence to the table.
Igor, you are 15 and still dont know what you are talking about. The problem you never seem to grasp, you can never even understand what a post or thread is about, so you just spout complete and utter fucking nonsense.
And now i will go back to ignoring you, because really - not one single post by you has ever been worth reading.
Chet
Poor chet. Honestly. Go back to being a stout defender of Valve and leave the database talk to those who know what they are doing, okay?
By the way, what you say about me in this thread is still worthless, because unlike you, I demonstrated a knowledge of mysql problems.
You have to be a troll. You have to be.
I don’t think anyone was suggesting that MySQL was better or even on par with Oracle or DB2. The question, was whether it was better than using Access.
The fact that it is free is also of great advantage.
Also Igor, most of the bugs listed in that document you linked to were fixed in 4.1. But if you really want to find a list of bugs for any language you can. That’s the cool thing about OpenSource, problems get fixed. And if they don’t, you can always fix them yourself.
K
I do agree with everything you said, I just can’t figure out why you brought the Open source thing up? The DB I recommended, Postgresql, is also open source, and if you want to get technical about it – it’s more Free than MySQL since you can use it without paying anyone in a commercial project. For MySQL it’s only commercially free if you are using it with PHP (because their licenses are “incompatible”). In fact, PostgreSQL is BSD so I could make my own fork called igorsql, close the source, and nobody would be the wiser. Try doing that with MySQL and the GPL license.