Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

MySQL 5.1 Improves Performance, Partitioning, Bug Fixes

CmdrTaco posted more than 6 years ago | from the not-sure-that-title-quite-parses dept.

Databases 146

kylehase writes "CIO.com has a writeup about MySQL's 5.1 release planned for next week. Among the enhancements are many bug fixes from 5.0, some of which may increase performance 20% or more, as well as 'partitioning, events scheduling, row-based replication and disk-based clustering.'"

Sorry! There are no comments related to the filter you selected.

ObPg (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23047006)

First Post(greSQL troll)!

It's nearly caught up to PostgreSQL. (5, Informative)

Anonymous Coward | more than 6 years ago | (#23047016)

MySQL has nearly caught up to PostgreSQL [postgresql.org] in terms of features.

PostgreSQL's Generalized Search Tree (GiST) indexing is still better than anything MySQL has to offer, in terms of performance and capability.

The PostgreSQL OpenFTS full text search engine is another marvel of engineering. It routinely outperforms similar extensions for MySQL in terms of performance, memory usage, and concurrency.

I hope that an upcoming release of MySQL deals with the maximum field size problem. With PostreSQL, there is a max field size of 1 GB. For MySQL, it's a mere 50 MB. For textual representations of certain geographic system data, it's not unusual these days to have individual fields that need to store 500 to 600 MB of data. PostgreSQL handles these fields fine. MySQL fails.

Re:It's nearly caught up to PostgreSQL. (-1, Flamebait)

Vectronic (1221470) | more than 6 years ago | (#23047130)

How much did you get for that advertisement?

Re:It's nearly caught up to PostgreSQL. (1, Interesting)

m50d (797211) | more than 6 years ago | (#23047302)

Probably less than slashdot got for this one

Re:It's nearly caught up to PostgreSQL. (5, Informative)

IversenX (713302) | more than 6 years ago | (#23047224)

MySQL fails in many other cases, too.

Many people see MySQL as the consistent winner in database benchmarks. I don't mean this in a bad way, but a lot of people are so focused on the performance of MySQL vs. PostgreSQL, that they forget that MySQL is usually only fast for really simple queries.

That would be fine, though, if it weren't for the failing integrity.

In terms of data integrity, PostgreSQL is kilometers ahead of MySQL. With MySQL, I have seen tables get badly corrupted, sometimes even beyond repair(!) if a disk runs full. That's simply unacceptable.

The syntax is also pretty lax. Adding an integer and a string? No problem. String and a float? Sure.

You want a contraint? Sure, it'll accept that query. Will it honour the constraint? Not so much.

Createing an InnoDB table, for (some) referential integrity? Sure, it'll give no errors, but if innodb support is disabled for any reason, it will create MyISAM tables instead, without any hint or warning. This has the potential to create great data loss.

Inserting a row with a primary key value outside the legal range? It'll give no errors, but it also wont insert the row. Instant data loss.

I know it's popular database, but I would probably not recommend MySQL for any project. If you need something lean and fast, try SQLite. Then you _know_ you don't get any type checks and fancy things like that, so you code for it. If you want to proper, free database, go with PostgreSQL. Half-baked is not my kind of tea. I really hope they will work on data integrity in the upcoming releases, but I fear it's not going to happen.

Re:It's nearly caught up to PostgreSQL. (1, Flamebait)

locokamil (850008) | more than 6 years ago | (#23047362)

No offense intended... but how do you bake tea?

Re:It's nearly caught up to PostgreSQL. (3, Funny)

chunk08 (1229574) | more than 6 years ago | (#23047398)

1. Pick tea leaves
2. Preheat oven to 400 degrees farenheit
3. Arrange leaves on baking sheet
4. Bake until crispy and dry, but not burnt
5. ???
6. Profit!

Re:It's nearly caught up to PostgreSQL. (4, Informative)

Splab (574204) | more than 6 years ago | (#23047822)

While I generally agree with you a few points and additions.

Createing an InnoDB table, for (some) referential integrity? Sure, it'll give no errors, but if innodb support is disabled for any reason, it will create MyISAM tables instead, without any hint or warning. This has the potential to create great data loss.

This is not entirely true. MySQL will revert to MyISAM even though you specifically asked for InnoDB - it will however issue a warning that it is doing so, this of course is a moot point since most application programmers never check for warnings.

And just to feed the flames while we're at it, MySQL will fail to fire triggers on cascading events.

If you got table A and B and C where B references some information in A and C in B all cascades on updates in A, then any update trigger on C (and possibly B) will fail to fire. This is a very big problem if you are using triggers to keep at least some form of consistency.

To top it up most replication services in MySQL are at best flaky, usually they replicate by using the binary log, so if the primary fails you lost the X last seconds/minuttes/hours (depending on setup and load) of transactions. Even if you got the binary log on a GFS you are still in big trouble since the secondary still needs to replay all transactions leading to the failure - I've heard of sites where this was taking minuttes to complete! (This might change in the new version)

Personally I wouldn't touch either PGSQL or MySQL in a mission critical environment, they are very nice toy databases, but when shit hits the fan - and it WILL happen - you need a reliable system with instant failover, which neither database can provide.

Re:It's nearly caught up to PostgreSQL. (5, Insightful)

segedunum (883035) | more than 6 years ago | (#23048396)

Personally I wouldn't touch either PGSQL or MySQL in a mission critical environment, they are very nice toy databases
I hear this refrain from every terrified analyst who ever wants to bring up the dreaded subject of open source databases, and I see no hard evidence for it. Sorry, but my bullshit detector goes into overdrive when I hear the phrase 'mission critical' and 'toy databases'. MySQL has its shortcomings, and has generally been the web database backend of choice (and it powers quite a few large 'mission critical' web sites), but Postgres really has been the open source database that has kicked on. Failover? Mirroring? Clustering? Yer, there are ways and means of doing that pretty well, and I have seen ample evidence that it can be trusted with lots of 'mission critical' tasks.

I've managed to start using Postgres in an organisation that has traditionally been all Oracle. The main reasons are the huge cost involved of additional licensing for additional servers, the incredible amount of DBA assistance that all Oracle installations seem to need and which they don't have the resources to provide and Oracle's incredible ability to suck any system resources you have into a black hole on any system. When any 'mission critical' database has the memory footprint of either MySQL or Postgres, and when it can actually start up in time for the end of the next ice age, give me a call.

but when shit hits the fan - and it WILL happen - you need a reliable system with instant failover, which neither database can provide.
An awful lot of people have been waiting an awful long time for that shit to hit the fan - and in the meantime it has cost them an arm and a leg in not only licensing and support costs, but also in a needless waste of system and hardware resources.

Re:It's nearly caught up to PostgreSQL. (4, Interesting)

Splab (574204) | more than 6 years ago | (#23048732)

Might want to get your BS detector checked then.

MySQL fails at some very critical points. As I said in previous post it fails to fire triggers on updates.
Also MySQL believe its better to serve a best effort than a failure - this is probably the biggest NO GO! out there. YOU NEVER EVER do something other than requested in a database. If the transaction model fails you are using no more than an advance file pointer.

Now PG is a very nice database, they got all the right things implemented, and often better than the competition.

PG however does not have any support for scaling, if you want to scale you need some form of middleware to handle it - and currently you have to buy continuent for that - which is a nice product, they however don't support stored procedures and triggers.

And please don't just hit google for PG and scaleability, and come back saying there are all sorts of products out there - most of them are based on triggers and some very bad methods for propergating data - all of them lack the ability to take down primary or secondary server(s) in a running environment and put a new up without interruption in the data flow.

An awful lot of people have been waiting an awful long time for that shit to hit the fan - and in the meantime it has cost them an arm and a leg in not only licensing and support costs, but also in a needless waste of system and hardware resources.


That line alone tells me you got your head so far up your OSS arse you are seeing pink elephants.

IBM Denmark just went down this week for a whole day, pretty sure their big clients are a bit unimpressed in their failure to bring multimillion installations back online.

If postgres can handle your situation then fine, but in my environment a database failure means everything comes to a grinding halt. And when you promise clients 99.999% uptime you sure as hell need subsecond failover *hint you can't do that with anything that reads binary logs from primary* and zero loss of transactions.

Re:It's nearly caught up to PostgreSQL. (0)

Splab (574204) | more than 6 years ago | (#23048758)

bloody hell, forgot my point with IBM.

When multimillion dollar installations fails and you are paying for the support + guarantee on uptime you got somewhere to send the bill if shit hits the fan.

What will you do when your PG installation fail? Go on IRC and ask for help?

Re:It's nearly caught up to PostgreSQL. (5, Insightful)

growse (928427) | more than 6 years ago | (#23049250)

"Phone Sun" I believe is a reasonable answer to your last point. I also believe they're not the only people who do support.

But you're right - anyone who picks MySQL or Postgres to power a super-resiliant mission-critical service is an idiot. And anyone who uses Oracle to power a non-resiliant low to medium load webservice is also usually an idiot.

Tools for the jobs people, tools for the jobs.

Re:It's nearly caught up to PostgreSQL. (0)

Splab (574204) | more than 6 years ago | (#23049632)

Actually Oracle does come in a "thin" cheap client.

To be honest I haven't checked the new prices on MySQL support, but carrier grade support was very expensive before, and I doubt it has improved with the Sun takeover. They do have support, and it is according to rumors fast, however you don't get that support unless you cough up the money for it.

Re:It's nearly caught up to PostgreSQL. (1)

Firehed (942385) | more than 6 years ago | (#23051234)

I'm sure you won't like the example, but Facebook is almost entirely powered by MySQL. Granted, it's very heavily modified (at least according to their jobs pages) to provide better support for pretty much everything that'll get mentioned in all of these comments, but they say that most or all of those changes will be released back into the public for future revisions.

I believe that Google also uses MySQL heavily, or at least did at one point. However, that's just some vague recollection and could be totally wrong.

Re:It's nearly caught up to PostgreSQL. (0)

Anonymous Coward | more than 6 years ago | (#23051802)

Tools for the jobs people, tools for the jobs.
Precisely why these discussions never go reasonably...

Re:It's nearly caught up to PostgreSQL. (1)

merryberry (974454) | more than 6 years ago | (#23049904)

bloody hell, forgot my point with IBM. When multimillion dollar installations fails and you are paying for the support + guarantee on uptime you got somewhere to send the bill if shit hits the fan. What will you do when your PG installation fail? Go on IRC and ask for help?
Tools for the job; if you are spending millions on software then go with the a company that is going to charge you millions. If you want a kick ass database for free then go with PG.

Re:It's nearly caught up to PostgreSQL. (3, Interesting)

Anonymous Coward | more than 6 years ago | (#23048008)

SQLite really isn't that fast and lean though. It's really only good for tiny data stores (in which case you can use RAM instead). If you take the same data and stuff it in the various DB systems you will see SQLite databases are huge compared to MySQL or PostgreSQL (lots of wasted space). Then there is the performance which isn't bad but not better than the other databases.

Don't get me wrong, I like the idea of SQLite. Per-user databases are needed very badly. I just wish SQLite performed better on normal sized data sets.

Re:It's nearly caught up to PostgreSQL. (1)

ThwartedEfforts (2976) | more than 6 years ago | (#23048188)

I have to disagree, for whatever "normal sized data sets" means. Admittedly anecdotal, but I was once getting unacceptable performance from MySQL on a 400+ million row table with a few simple joins, and it turned out to be faster to export all the data to flat text, import it into an SQLite database and run the entire thing in SQLite. Same hardware, same OS, otherwise idle machine. Unfortunately, there wasn't enough time to investigate exactly what the cause was for the slowdown in MySQL, perhaps it could have used an "optimize table" or two, but the execution plan appeared legit, we just chalked it up to MySQL being comparatively slow to SQLite.

Re:It's nearly caught up to PostgreSQL. (1)

Bronster (13157) | more than 6 years ago | (#23051368)

I had a bunch of ~200k record databases with about 8 simple tables in them. Indexing data for mail server backups in fact. I was doing lots of indexed queries on said tables, and once the sqlite database hit a certain size it went seek crazy.

By seek crazy I mean that per single _indexed_ query it would perform about 200 seeks on the database file. Multiply that by many thousands of index checks for your typical backup run and it was game over for sqlite.

The machine has 16Gb of memory and a maximum of 30 concurrent backup threads, so I wound up just slurping the entire database into hashes in memory (perl) at startup and doing hash lookups instead. Massively faster.

So yeah, not such a big sqlite fan as I once was. It didn't scale well for me.

I'm Already Gone (4, Insightful)

segedunum (883035) | more than 6 years ago | (#23048220)

We've already started a migration from MySQL to Postgres, and we're not going back. Full Text Searching was one of the features, but Postgres all round just has a lot more to it. You can make the thing look like an Oracle database if necessary, there's auto vacuuming now, asynchronous commits and a ton of other performance improvements that don't skimp on features.

I really can't see why anyone would choose MySQL now, apart from inertia and backwards compatibility.

Re:I'm Already Gone (0)

Anonymous Coward | more than 6 years ago | (#23050016)

I've setup some large document management systems using Owl with a Postgre db backend, and the performance difference with MySQL is clearly noticeable. The only issue i had with Postgre is that it's a tad more difficult to admin, but this is mostly because i'm used to the MySQL way, which is more accesible.

I'm not going back any time soon either.

Re:I'm Already Gone (1)

ShieldW0lf (601553) | more than 6 years ago | (#23050024)

MySQL has lax enforcement of constraints. Which is a big black eye, and makes it totally unsuitable for a number of important tasks for which people are willing to pay good money.

However, when you've already made the choice that you're going to compromise on your constraints and referential integrity, it makes multi-master clustering a lot easier.

This is the niche in which MySQL fits.

That said, I don't like it, and use Postgres for my own projects.

Re:It's nearly caught up to PostgreSQL. (1)

mindas (533922) | more than 6 years ago | (#23048424)

Don't know the specifics of your project, but isn't it better to use a tool that is designed to do the job (FTS in this case)? Lucene is pretty much de facto standard these days, robust and free.

Re:It's nearly caught up to PostgreSQL. (0)

Anonymous Coward | more than 6 years ago | (#23049654)

blah blah blah no native replication in postgres

Sounds... 'Enterprisey' (0, Funny)

Anonymous Coward | more than 6 years ago | (#23047032)

AKA: Here comes the suck!

What?!? (1)

skrolle2 (844387) | more than 6 years ago | (#23047034)

From TFA:

MySQL had said it would release 5.1 in the first quarter, which ended March 31, and some developers have been getting impatient for the new release.
What?!? I've been running 5.1 on a production server for almost a year now.

Probably, we should have called it 6.0, because there's so much stuff in there and we've been working on it for a couple of years.
What?!? The 6.0 alpha has been available for half a year, it's already in developement, OF COURSE you can't call 5.1 6.0 since both are in development. What the hell is this guy on?

Re:What?!? (0)

Anonymous Coward | more than 6 years ago | (#23047094)

You've been running a MySQL 5.1 beta, not the final release. It's okay to do that for testing purposes, but it's unwise to run a production site with beta software. The risk of data loss is just too great.

Re:What?!? (0, Redundant)

larry bagina (561269) | more than 6 years ago | (#23047148)

It's also unwise to run a production site on MySQL :p

Re:What?!? (4, Informative)

Anonymous Coward | more than 6 years ago | (#23047192)

I don't understand how you can say things like that when HUGE sites like Flickr are MySQL based...and Google uses MySQL code for their DB...

Re:What?!? (1, Insightful)

ortholattice (175065) | more than 6 years ago | (#23047384)

I don't understand how you can say things like that when HUGE sites like Flickr are MySQL based...and Google uses MySQL code for their DB...
Both of these applications involve non-critical data. Google doesn't care if two separate searches for the same thing, one immediately after the other, give different results (which is often the case, probably due to different servers not being sync'ed to each other, not saying it's a MySQL problem; the point is that the data is loosey-goosey and non-critical). And, you forgot /. itself, which uses MySQL. They definitely don't care about the precision of the data; heck, they still can't even get "page 1 of 2" and "page 2 of 2" not to have overlapping results after 10 years or whatever in business.

I think your case would be better made if you showed a HUGE user of MySQL for financial applications. Does Google use MySQL to handle their general ledger and billing?

Re:What?!? (1)

asaivan (1025940) | more than 6 years ago | (#23047408)

It's just different DBs for different purposes. (I'm the poster of the comment you replied to, I hit AC on accident).

Re:What?!? (1)

theantix (466036) | more than 6 years ago | (#23048628)

Do some research before you talk about things you dont understand. For starters, Google uses MySQL for their ads, not searches. Searches are done via Bigtable, which is actuall pretty cool. However I find it extremely unlikely that Google would trust their ad system to something they felt was "loosey-goosey".

Regardless there are plenty of large scale institutions which use MySQL cluster for financial and other critical applications. MySQL Cluster is extremely robust, and thanks to rolling upgrades and built in redundancy it is a very safe and reliable system.

Disk Clustering (2, Interesting)

TheLinuxSRC (683475) | more than 6 years ago | (#23047056)

I am really looking forward to disk based clustering in MySQL. I have tried the NDB clustering, but the hardware requirements can be hefty. I am also curious about performance in this area. Contrary to what one might assume, the in-memory clustering is generally slower than storing the files on disk. I am curious how the disk based clustering fares compared to NDB clustering and a traditional on-disk MySQL DB.

Re:Disk Clustering (1)

dysk (621566) | more than 6 years ago | (#23047304)

Contrary to what one might assume, the in-memory clustering is generally slower than storing the files on disk. .
Are you sure this holds up for mysql's shared nothing architecture? Most other DBMSes use a shared block device (a SAN) for clustered databases, which is a whole other perforamnce profile.

Re:Disk Clustering (1)

EricFenderson (64220) | more than 6 years ago | (#23047784)

Disk-based clustering will still use NDB. Previously, NDB tables stored everything in memory. Now, NDB can store data on disk. There are still some limitations. Those columns must be non-indexed, for example.

Re:Disk Clustering (1)

aauu (46157) | more than 6 years ago | (#23047850)

Read carefully, NDB supports placing some types of data columns on disk. Blobs are not tables.

When you talk clustering there are two architectures:

A single active instance that can migrate between nodes: This is red hat, drbd, windows, veritas clustering. This is a high availability option where an instance will migrate to a new node by dismounting disk resources, moving ip addresses and starting the instance on a new node. This can be in response to a node failure detected by cluster heartbeat/monitor or for administrative purposes such as software/hardware maintenance. This architecture is also supported by SQL Server and Oracle. This architecture can be implemented for many types of services such as email.

Multiple active instances that cooperatively share a single set of physical database files: This is Oracle RAC and MySQL NDB (the database has to be able to persist to files for shutdown/startup) with memory files. The disk enhancement for NDB allows blobs to be disk based. The databases tables/indexes still need to be memory resident.

Note that in both clustering architectures damage to the database files is still a significant vulnerability. SANs represent the best host for cluster files. DRBD can recover from disk failure, although you should already be raid 10 or 20 for you database files.

Clustering is a high availability mechanism and not a disaster recovery methodology. Backups or other file recovery mechanisms are required.

Re:Disk Clustering (1)

Mad Merlin (837387) | more than 6 years ago | (#23050160)

...although you should already be raid 10 or 20 for you database files.

RAID 20? I don't think that exists. Perhaps you meant RAID 50 or RAID 60...

Re:Disk Clustering (1)

aauu (46157) | more than 6 years ago | (#23051002)

Raid 10 is striped mirrors. Raid 20 is striped triplets.

Re:Disk Clustering (2, Informative)

theantix (466036) | more than 6 years ago | (#23048696)

With NDB Cluster 5.1, all of the indexed columns are still in memory, so the performance impact is minimal for the types of queries and DML that NDB is good for. At least, in my testing it has been.

For things NDB cluster is really bad at, like querying against non-indexed tables... even the memory based NDB is terrible compared with the innodb/myisam. So you wouldn't be doing that anyway, but the indexed columns would be relatively unaffected by the change.

Re:Disk Clustering (1)

redwoodtree (136298) | more than 6 years ago | (#23050740)

From my tests and working with MySQL professional services, once disk based clustering is turned on, performance tanks across the board, even on the memory portion.

This technology has a long, long way to go. There are very few real world applications for NDB cluster right now.

License status. (2, Interesting)

DAldredge (2353) | more than 6 years ago | (#23047078)

Do they still insist that simply connecting to the server process requires a commercial license if you aren't GPL?

Re:License status. (2, Informative)

Doug Neal (195160) | more than 6 years ago | (#23047282)

The client library is GPL. There's nothing to stop anyone writing their own client library under another license, but nobody's done that yet (as far as I know).

Re:License status. (4, Informative)

Fweeky (41046) | more than 6 years ago | (#23047654)

php-mysqlnd [mysql.com] is a replacement for libmysql, under the PHP license.

Re:License status. (3, Informative)

DAldredge (2353) | more than 6 years ago | (#23047754)

http://www.mysql.com/about/legal/licensing/commercial-license.html [mysql.com] The Commercial License is an agreement with MySQL AB for organizations that do not want to release their application source code. Commercially licensed customers get a commercially supported product with assurances from MySQL. Commercially licensed users are also free from the requirement of making their own application open source. When your application is not licensed under either the GPL-compatible Free Software License as defined by the Free Software Foundation or approved by OSI, and you intend to or you may distribute MySQL software, you must first obtain a commercial license to the MySQL product. Typical examples of MySQL distribution include: * Selling software that includes MySQL to customers who install the software on their own machines. * Selling software that requires customers to install MySQL themselves on their own machines. * Building a hardware system that includes MySQL and selling that hardware system to customers for installation at their own locations. Specifically: * If you include the MySQL server with an application that is not licensed under the GPL or GPL-compatible license, you need a commercial license for the MySQL server. * If you develop and distribute a commercial application and as part of utilizing your application, the end-user must download a copy of MySQL; for each derivative work, you (or, in some cases, your end-user) need a commercial license for the MySQL server and/or MySQL client libraries. * If you include one or more of the MySQL drivers in your non-GPL application (so that your application can run with MySQL), you need a commercial license for the driver(s) in question. The MySQL drivers currently include an ODBC driver, a JDBC driver and the C language library. * GPL users have no direct legal relationship with MySQL AB. The commercial license, on the other hand, is MySQL AB's private license, and provides a direct legal relationship with MySQL AB. With a commercial non-GPL MySQL server license, one license is required per database server (single installed MySQL binary). There are no restrictions on the number of connections, number of CPUs, memory or disks to that one MySQL database server. The MaxDB server is licensed per CPU or named user.

Not this crap again... (2, Insightful)

Wiseman1024 (993899) | more than 6 years ago | (#23048482)

When will people realize the licensing issues are *solved* now?

Surely, I can see clueless people 100 years from now still bitching about MySQL's licensing terms.

Re:Not this crap again... (1)

Just Some Guy (3352) | more than 6 years ago | (#23049526)

When will people realize the licensing issues are *solved* now?

They are? So you can write non-GPL software with a MySQL backend now? Great!

Re:Not this crap again... (2, Informative)

kylehase (982334) | more than 6 years ago | (#23051686)

Sure you can, just don't distribute the software. Every commercial case listed in the license above describes distributing MySQL in whole or part.

I'm no lawyer but it seems if you develop a non-GPL commercial service that runs a community-licensed MySQL backend it's perfectly fine to charge for your service.

as long as is still free i don't give a hoot (-1)

Anonymous Coward | more than 6 years ago | (#23047100)

free beer good even if coors

Twofo Goatse (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#23047110)

Goatse. [twofo.co.uk] [goatse.ch]

You nerds love it.

When shall we get a decent front end? (3, Interesting)

bogaboga (793279) | more than 6 years ago | (#23047112)

I am wondering when we shall ever have a free as is OSS, fully programmable front end to MySQL. All the free front ends available suck big time and the non free ones, though somewhat functional, are not available without some kind of restrictions.

In my opinion, the day MySQL will have a fully programmable front end...I mean one that a programmer can add business logic to, program input masks, direct functionality at widget or control level and use to generate customized reports depending on various metrics, MySQL will kick ass. Right now, all front ends to MYSQL suck big time and there does not appear to be an end in sight - sadly.

SQL Maestro is very promising but it's not free!

Re:When shall we get a decent front end? (1)

larry bagina (561269) | more than 6 years ago | (#23047176)

When will you start developing it? OSS exists because someone has an itch that needs scratching.

Re:When shall we get a decent front end? (0, Troll)

OeLeWaPpErKe (412765) | more than 6 years ago | (#23047332)

When I get paid for it. I want about 3000$/month. The state here wants another 3000.

When do I start ?

Re:When shall we get a decent front end? (1)

isilrion (814117) | more than 6 years ago | (#23047508)

When do I start ?
How could we know? You are the one who wants the feature, and the money... That's your problem, not ours.

Re:When shall we get a decent front end? (1)

Blackknight (25168) | more than 6 years ago | (#23048234)

Not everybody that uses OSS software is a developer. I'm a system admin and I've done my fair share of shell scripting, PHP and Python but I still can't write every application that I need from scratch. If MySQL had something like Enterprise Studio it would be really nice, phpMyAdmin is ok but it's missing some things.

Re:When shall we get a decent front end? (1)

bXTr (123510) | more than 6 years ago | (#23048406)

Not everybody that uses OSS software is a developer.
Not everyone who uses OSS software has to be a developer to contribute. There are developers out there who wouldn't mind being paid to make an Enterprise Studio-y front end for MySQL for you. Hell, anything is possible; it's only a question of time and money.

Re:When shall we get a decent front end? (2, Interesting)

Animats (122034) | more than 6 years ago | (#23047276)

SQL Maestro is an administrative tool, not a report generator.

PHP Generator for MySQL [sqlmaestro.com] is free and useful for generating simple database-driven web sites.

Admittedly, the MySQL Query Browser is clunky, but at least it finally works. For several releases, it was badly broken.

Re:When shall we get a decent front end? (0)

Anonymous Coward | more than 6 years ago | (#23047310)

I've never used it but you can try out OOO Base [openoffice.org] which is a copy of MS access. I'm guessing that is the solution you are looking for. I'm wondering, thought, how many people still use MS access? I mean you can make a simple web-based app and people can access it from anywhere. Why bother with a full blown app?

Re:When shall we get a decent front end? (1)

barzok (26681) | more than 6 years ago | (#23047342)

OO.o Base is far from a "copy of MS Access." I tried to use it once and couldn't figure out how to put together a simple form for adding records to a table.

Re:When shall we get a decent front end? (1)

Kirkoff (143587) | more than 6 years ago | (#23047594)

I messed around with it a few times. They made some good strides in 2.3. I have yet to try anything with the 2.4 release but it is slowly getting there. It's not a copy of MS Access though - it is all built around a page model which is very odd when creating forms.

Re:When shall we get a decent front end? (1)

Planesdragon (210349) | more than 6 years ago | (#23048620)

I'm wondering, thought, how many people still use MS access? I mean you can make a simple web-based app and people can access it from anywhere. Why bother with a full blown app?
MS Access is the archtypical "toy" database -- useful for very-small projects that don't need to go beyond one computer, or that would otherwise be done by hand using some badly written spreadsheets.

I've used Access to parse some very large data sets, and I've seen it used as the primary database for limited-run data-sets. Sure, most of these COULD be done via a single server hosting it somewhere... but that's unneeded complexity for the lower end of tasks.

Re:When shall we get a decent front end? (1)

Shados (741919) | more than 6 years ago | (#23049916)

You know that Access isn't a database, yes? And that its quite often used on "real" databases? And that if you start with the "toy" database, it can easily later be upgraded to a "real" one? Which is a fairly large part of its usefulness.

Re:When shall we get a decent front end? (4, Funny)

ianare (1132971) | more than 6 years ago | (#23050028)

Toy database for small, unimportant projects? I don't think so. Access is one of the most stable, reliable, and secure DB systems out there, as the following shows so well:

Among revelations contained in the memos was information that the Microsoft Access database used by the Diebold system to collect and calculate votes was not protected by a password.
source [wired.com]

Re:When shall we get a decent front end? (1)

bogaboga (793279) | more than 6 years ago | (#23051382)

MS Access is the archtypical "toy" database -- useful for very-small projects that don't need to go beyond one computer, or that would otherwise be done by hand using some badly written spreadsheets.

I suggest you get your facts right before posting, otherwise you make us grade you in a certain way. Access is NOT a database. It IS a front end to Microsoft's Jet Database engine.

Having said that, Access itself is fully programmable using Visual Basic. Virtually, all components of what you see on the screen and what they do or how they respond after specific events can be programmed. There is nothing in the OSS world that comes close to this.

I am still looking for a way to make OpenOffice.org's database front end enforce input masks for Canadian postal codes which are in the following format: [A-Z][1-9][A-Z][1-9][A-Z][1-9].This effort is proving almost impossible. Catching an error at form level is better and faster than waiting for the DB to flag it and return an error.

Re:When shall we get a decent front end? (1)

dysk (621566) | more than 6 years ago | (#23047322)

Sadly, management tools and report generation are hard, and they require a level of coordination that's easier to achieve in one company and much harder in an open source environment.

A brilliant programmer can come up with some really solid and innovative code (ex. reiserfs), but to make a nontrivial management tool you need a combination of programmers, designers, and yes, managers, working in tight concert.

I personally am okay with paying for front ends when they're needed, so we can get kickass scalable solid database backends for free.

Re:When shall we get a decent front end? (5, Insightful)

NevarMore (248971) | more than 6 years ago | (#23047354)

Fully programmable front-end for a database?

You mean like C, C++, Java, Ruby, PHP, Python, OO Calc, ASP, C# ??

Re:When shall we get a decent front end? (1)

Danny Rathjens (8471) | more than 6 years ago | (#23048198)

I'm confused at his request, also. Perl is my mysql front-end and I can do absolutely anything with it. Maybe he is asking for the old MS Access style graphical "form" interface for inputting data and generating reports or perhaps he is talking about a GUI administrative interface like phpmyadmin.

Re:When shall we get a decent front end? (2, Informative)

Shados (741919) | more than 6 years ago | (#23048248)

He's talking about a 4th gen RAD front end, so yeah, like MS Access, eDeveloper, Oracle Developer (is that still how its called?), etc. There are a few up and coming one in the open source world, but none really that are feature complete.

Re:When shall we get a decent front end? (1)

Planesdragon (210349) | more than 6 years ago | (#23048630)

Maybe he is asking for the old MS Access style graphical "form" interface for inputting data and generating reports or perhaps he is talking about a GUI administrative interface like phpmyadmin.
Yes, both of those qualify as a "front-end."

phpmyadmin fails as it's an unnecessary layer of abstraction -- I shouldn't have to run a webserver on my db engine, or local machine, just to admin my database outside a command shell.

Re:When shall we get a decent front end? (1)

dookiesan (600840) | more than 6 years ago | (#23048460)

I'm thinking that he wanted something you could click your mouse on, but still customize. You should be able to do a lot of things with the database using your mouse alone. A first step would be graphical tools for extracting and displaying the data; maybe then you can move on to modifying it.

Re:When shall we get a decent front end? (0)

Anonymous Coward | more than 6 years ago | (#23049440)

I think he was referring to blist.com

Re:When shall we get a decent front end? (1)

lakeland (218447) | more than 6 years ago | (#23049698)

I think he means like SQL Server Reporting Services, MS Access and SQL Server Analytic services.

Hard to be sure though.

The tools like Mondrian, JasperSoft, Petaho, Navicat, etc. They're all okay, but nothing like as polished as Microsoft's.

Re:When shall we get a decent front end? (0)

Anonymous Coward | more than 6 years ago | (#23047468)

Programmable front end? How about, say, Java DB, which I would add, is fully programmable. It is, after all, a programming language. Then, there are also the interfaces, for say, Python, which again,are fully programmable, and you can add business logic... So, what exactly are you looking for?

Re:When shall we get a decent front end? (1)

shmlco (594907) | more than 6 years ago | (#23047860)

"... the non free ones, though somewhat functional, are not available without some kind of restrictions."

Yeah, like they expect you to pay for them.

Re:When shall we get a decent front end? (1)

Richard_at_work (517087) | more than 6 years ago | (#23048194)

Dunno if its what you are after, but have you tried HeidiSQL?

Re:When shall we get a decent front end? (1)

Wiseman1024 (993899) | more than 6 years ago | (#23048502)

You mean Access? You could try Rekall, Kexi and OpenOffice Base, for example. I think they all work with Python, which is a huge advantage over Access.

Re:When shall we get a decent front end? (1)

carlzum (832868) | more than 6 years ago | (#23050390)

I work with Oracle, MySQL, and SQL Server 2005 and find the front-end tools pretty much equivalent. I develop with Toad (third party) for Oracle and MySQL and Management Studio for SQL Server. They highlight code, debug, and make ordinary database commands easier to execute, but they're far from the complete development environment you're describing. I think "front-ends that suck" is common to all database vendors. My business logic and reports live in Java/.NET and other tools like Reporting Server and Jasper. IMO, the tools available for MySQL are not any better or worse than commercial software.

Get PostgreSQL! No, shut up! YOU shut up! (5, Funny)

g_adams27 (581237) | more than 6 years ago | (#23047146)

I would simply like to point out that this MySQL update is completely irrelevant because PostgreSQL has had (g_adams27, fill this part in before submitting) for a very long time, and MySQL is simply playing catchup.

...

And now I would like to strongly disagree with g_adams27, who obviously doesn't realize that MySQL is an excellent choice even compared with PostgreSQL, and I wish he'd stop making silly comparisons.

...

In response to that, I say: g_adams27, SHUT UP! You obviously don't recognize the fatal flaws that MySQL still has, in that it still can't (fill this part out later) even after years of development. PostgreSQL is obviously the superior option, and you can take your stupid MySQL advocacy somewhere else.

...

Oh, yeah? Well maybe YOU should shut up! I can't say I'm shocked at g_adams27' mean-spirited response, because that's typical of PostgreSQL jerks. MySQL is AWESOME, and YOU need to shut up, jerk!

...

Well, g_adams27, maybe you should take your TOY MySQL and go play with your dollies, while us REAL sysadmins use a REAL RDBMS to do REAL work! Idiot.

...

And now, allow me, g_adams27, to step in to the middle of this debate and simply point out that you're BOTH right, and that MySQL and PostgreSQL are perfectly good choices.

Just doing my part to shorten this thread.

Re:Get PostgreSQL! No, shut up! YOU shut up! (1, Offtopic)

UnknowingFool (672806) | more than 6 years ago | (#23047178)

On that same note, I would like to say the emacs is way better than vi. That's right. You heard me. Bring it! :P

Re:Get PostgreSQL! No, shut up! YOU shut up! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23047196)

But neither can beat pico.

Re:Get PostgreSQL! No, shut up! YOU shut up! (0, Offtopic)

Evanisincontrol (830057) | more than 6 years ago | (#23047274)

On that same note, I would like to say the emacs is way better than vi. That's right. You heard me. Bring it! :P
Dammit, Emacs [xkcd.com]

Gentlemen, please! (1)

mstahl (701501) | more than 6 years ago | (#23051604)

Let's not start another religious war on slashdot!

Re:Get PostgreSQL! No, shut up! YOU shut up! (0)

MrNaz (730548) | more than 6 years ago | (#23047416)

If you don't stop using MySQL I'm going to tell the teacher! Also you're a poopy head locks no returnies!

Re:Get PostgreSQL! No, shut up! YOU shut up! (1, Funny)

Anonymous Coward | more than 6 years ago | (#23047496)

By golly. Over a hour after this story popped up and there were only 37 comments posted. You perform magic with your words of wisdom, g_adams27!

Re:Get PostgreSQL! No, shut up! YOU shut up! (1)

Godji (957148) | more than 6 years ago | (#23047684)

Not to start a flamewar, but how many of the aforementioned features does PostgreSQL already have (available or planned)?

Note that I am not asking which DBMS is better for any definition of "better".

Re:Get PostgreSQL! No, shut up! YOU shut up! (1)

iluvcapra (782887) | more than 6 years ago | (#23048324)

I must say, I've been sitting at this PostgreSQL machine at this contract web design gig, and I don't know what all of you Postgres people are talking about! I started this 100 row SELECT statement 20 minutes ago, and it STILL hasn't finished. MySQL has it's problems, but seriously, guys!

Always look over your head for joke before replying. I wish I could find a link to the original post.

Excellent! *rubs hands together* (1)

Nail (1195) | more than 6 years ago | (#23050554)

The whole Slashdot article commenting process distilled into a single comment. With this, my "Library in a Book", and my "Election in an Argument", I will Take Over The World! MUAHAHaHahaha! Somehow...

woo! (1, Offtopic)

elmaxxgt (980095) | more than 6 years ago | (#23047188)

yes! what a great month, with kubuntu 8.04's release also soon... oh man, new toys! :D

Re:woo! (0, Offtopic)

cbart387 (1192883) | more than 6 years ago | (#23047244)

Fedora 9 is this month as well. I very looking forward to the faster X startup/shutdown. [fedoraproject.org] :) Full list is here [fedoraproject.org] .

Re:woo! (1)

elmaxxgt (980095) | more than 6 years ago | (#23047278)

oh wow, thanks for the link, i will have to play with this too D: you insensitive clod! :)

And I just managed to get the 5.0.51a compiled... (0)

Anonymous Coward | more than 6 years ago | (#23047230)

Was painful to port the VC project files from the 5.0.45 release to compile the 5.0.51a. The funny think is that it adds some additional binaries which are not available through the makefiles at all.

This article reminds me why I'm still in school (0)

Anonymous Coward | more than 6 years ago | (#23047672)

Events scheduling? Row-based replication? Disk-based clustering? Back to the textbooks...

Re:This article reminds me why I'm still in school (0)

Anonymous Coward | more than 6 years ago | (#23048044)

That's one of the reasons I left the PC industry. I just couldn't take it anymore, Office Space style.

Computers burned me out over the timespan of only ~10 years.

Re:This article reminds me why I'm still in school (0)

Anonymous Coward | more than 6 years ago | (#23048072)

meh. School is all philosophy. The only way to learn is in the real world.

Stop the damned comma-frenzy headlines already (0)

Anonymous Coward | more than 6 years ago | (#23048274)

Here's what the f'ing "let's use commas for all of it despite that it's grammatically wrong - 'coz everyone else does so" headline expands to:

MySQL 5.1 improves performance, partitioning and bug fixes.

Total brainpower.

Decipher for non DB types (2, Insightful)

tji (74570) | more than 6 years ago | (#23048302)

I do use databases for various apps and projects, but only enough to do what I need. I am by no means a DB expert.

So, can someone more DB-literate explain some of the new features?

- Disk based clustering: I assume this means I can dynamically expand the size of my database by adding more disks. Is this correct? Does PostgreSQL also support this (my project where this would be handy currently uses pgsql)?

- Partitioning: I can think of several things this could mean.. Splitting data among several tables at some logical dividing point. Or, limiting the size of tables so they can't overrun the complete storage space. What does this mean in MySQL 5.1 terms?

Re:Decipher for non DB types (5, Informative)

theantix (466036) | more than 6 years ago | (#23048760)

- Disk based clustering: I assume this means I can dynamically expand the size of my database by adding more disks. Is this correct? Does PostgreSQL also support this (my project where this would be handy currently uses pgsql)?
Disk based clustering only applies to people using the MySQL NDB Cluster product, which is quite different from the traditional MySQL product. So for the vast majority of MySQL users who use MyISAM or InnoDB tables, this doesn't really affect them at all.

- Partitioning: I can think of several things this could mean.. Splitting data among several tables at some logical dividing point. Or, limiting the size of tables so they can't overrun the complete storage space. What does this mean in MySQL 5.1 terms?
This means splitting an existing table along logical dividing points, but still acting as a single table. Let's say you partition it by date, well then you would insert/select/update like normal -- but a query or update that looks at the date would only have to look at a smaller partition of the table to know what row needs to be updated.

Re:Decipher for non DB types (1)

merryberry (974454) | more than 6 years ago | (#23049934)

And to add, partitioning in mysql 5.1 is probably not going to be production ready.

Did they fix perf (1)

melted (227442) | more than 6 years ago | (#23049318)

Did they fix perf in subselects and multi-way joins? No? Didn't think so.

Re:Did they fix perf (1)

diegomontoya (712934) | more than 6 years ago | (#23049462)

Subqueries in Mysql is as useful in the real-world deployments as paper and pencil. Actually, at least with p&p, I can doodle some fancy comics.

Subselects is so limited in the indexes it can use the performance as melted has pointed out is bad. To me, it's not bad, it's unusable in just-in-time page generation. Usable for cron jobs and data warehousing but forget about it if you want it "fast".

about **** time! (2, Informative)

diegomontoya (712934) | more than 6 years ago | (#23049408)

As a heavy user of Mysql since 4 series, 5.X has been the buggiest, slowest, with the most god-awful slow release schedule of them all. 4.1 alpha was higher quality in terms of bugs/stability than all the stable "5.0" releases and 5.1 just takes forever to get even beta revisions out the door. Mysql is getting slower and slower at getting releases out the door. Expect Mysql 6.0 in 2011 if not later.

I'm a paid mysql enterprise subscriber and I'm pissed at their pace.

It's one thing to have a slow stable release but for crying out loud, shorten your "beta/rc" releases please? The amount of bugs fixed between each release is staggering which is why the bleeding edge adopters need faster releases!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?