Slashdot Mirror
MySQL Gets Functions in Java
Java Coward writes "Eric Herman and MySQL's Brian "Krow" Aker have released code to allow the DBMS MySQL to run Java natively inside of the database. The code allows users to write functions inside of the database that can be then used in SELECT/INSERT/UPDATE statements. So when will someone do Ruby?"
Now how about a way to do online backups of the new table types with out having to buy a license to do it?
Rumor has it that he was fired (or was going to be, so he "resigned"). I'd wait a couple weeks to make sure no backdoors are found.
If you have java in the database, it will make it possible to integrate JMS (messaging). A lot of the big databases let you do this, e.g. have a trigger that sends a message to invalidate a cache entry. That sort of thing can be useful.
I wouldn't say that Java's main advantage is compatablity with almost every platform
I would say that it is definitely one of Java's advantages. I think this feature is useful from the perspective that more small applications will be written by developers that may not be skilled with SQL coding. Many open source projects start out with one developer, and that single developer might not have an arsenal of skills. That is where this sort of thing helps out, that single developer will now be able to use his/her favorite host-language (if Java is his/her favorite host-language) to solve a SQL problem that he/she may not be capable of solving with SQL. Later on, if/when the project grows, the embedded Java may get removed, but at least something had been released, and the concept gets proven.
As an Oracle DBA, at a small company, we're constantly looking for less expensive SOLID alternatives to our traditional Oracle/Solaris approach to the back end.
...
When I say solid, I mean is able to handle very large files (excess of 50GB per datafile), has stored procedures and trigger infrastructure (a traditional MySQL weak point, and the main reason we've passed on it so far), an integrated backup system a la netbackup/RMAN, and prefereably a back end compiled scripting solution a la PL/SQL.
This looks like a sorta kinda solution to the last (PL/SQL alternative), but I'm curious to know about the rest, and also how it performs. Ideally for us, we'd also like to see better clustering and large system support examples in the real world before we embarked onto this particular voyage with.. say a production ERP system.
Are we talking about a good replacement for Access or for DB2 here?
Enquiring minds want to know
-chitlenz
Imagination is the silver lining of Intelligence.
I agree, migrating from another database to mysql is a pain in the ass and impossible, due to the lack of a lot of functionalities you said.
Postgresql, in the other side, is close to other databases, and migrating to it maybe is a pain in the ass too, but not impossible.
Last version of Postgresql is really fast, so why should I use Mysql?
ajf
This idea has been around for a while; at least since the late 1980's. The motivation for these kinds of DBMS features is that there are lots of programming situations where SQL's types and expressions aren't powerful enough, and that the language doesn't have a lot of modularity. User-defined functions are supposed to overcome this limitation.
This kind of feature brings MySQL closer to being an "Object-Relational" database.
From a theory point of view it goes a long way towards implementing the Relational Model's idea of a 'domain' (not just INTEGER, VARCHAR or whatever, but PART_NUM, PERSON_NAME etc). This is supposed to improve the integrity of the data in the database.
From a practical systems point of view it can have a big performance impact. If you're opening cursors and then looping over some Java code on the client to identify only those result rows that you're interested in, then you're paying a pretty big 'system tax' to transfer the data from the DBMS through the connection and into the external program's address space. Pushing the code (which will have to run anyway) into the DBMS eliminates the transfer overhead.
The point of the original Postgres was to figure out how you incorporate these features into a query processing framework. Most modern DBMS products have the feature; some of them do a better job implementing it than others.
But in most shops employing RDBMS, you have one team that maintains the OS, one team that maintains the database, one team that maintains the network, and finally a team that writes and maintains the actual applications. What the poster is probably worried about is being a DBA when some application programmer uses Java badly and then his boss leans on him, as the DBA, to make the process work faster.
I work in such a company, as an application programmer. Where I work, it's not up to the DBA to make things run faster - if an application is too slow, it's our problem. True, we can call on the various other people to help us in tracking down the cause of the problem, working out what needs to be done to improve the situation, etc, but ultimately it's our responsibility. It may be that the solution is to increase the spec of the machine(s), or upgrade the network, but we'd still be very much involved in coming to that decision.
So, as a counter example - from my position as a programmer, I'd be rather upset if my otherwise well-performing code is crippled by an underspecced machine or poorly-configured database. I trust the people responsible to do their jobs properly, though.
It's official. Most of you are morons.
That was spread (as I recall) because of default passwords not being changed on sample databases. I know lots of people that dont change their default MySql root password. (I tellem but WTF, its their bandwidth...)
Seems like they are trying bring MySql in direct competition with M$SQL server... ( as a spreader of worms )
The knees jerk so fast on /. whenever Java is mentioned, in any context, that I'm surprised someone doesn't have their eye put out.
Of course there exist myriad reasons why one would prefer to standardize on a common language for DB SPs. Java, in this regard, is the most mature alternative at present. Even the notoriously skeptical Thomas Kyte and the pontificating Steven Feuerstein see the validity of Java in the database at the SP level.
Of course, *we* can all keep fighting amongst ourselves about such things while Visual Basic and C(flat) become the only languages we have to chose from for everything we endeavor to do.
how many folks can you find who are *experts* good with both SQL & Java? (BTW,I don't mean that they can write simple joins, group bys and unions. I mean good enough to understand access paths and parallelism choices). Of the 100+ java developers I've worked with over the last four or so years I've only met *1* who would meet that critieria. So, exactly who's going to be making the performance-tuning decisions? Nope - bad idea, a simple tuning problem will need a committee to figure it out.
keep in mind that since we've mostly dropped the idea of writing all business logic in stored procedures, they're primarily being used these days for very simple procedures. Nothing fancy - convert an ip from a string to an integer, etc. You don't need *or want* a big language for this. Nor should you sweat too much that it is proprietary - who cares when you can learn the basics of the language in 5 minutes.
Obligatory comment/troll about how much MySQL is not ready for the enterprise eventhough it actually is.
.. but its just not there yet. I'm counting the days until I can get this overpriced trash off our database servers. :(
Spoken like a true linux zealot with absolutely no foundation in relational data management.
Do you realize that referential integrity is a fairly new feature in MySQL? Do you understand the reasoning behind a transaction based DBMS? How about the simple normal forms layed out by Boyce and Codd?
Anyone who's done any extensive DB work will tell you how lacking MySQL is. I *love* linux, its the only OS I run at home, and I follow the progress of the MySQL project with an almost religious fervor. I can't *WAIT* until it can compete in a production environment
Perhaps when there's a Jython-like JVM based Ruby implementation?
Seriously (given the number of ignorant "why use Java it's so slooooow" posts) as far as I can tell the current Ruby implementations are slow compared to Java. Would you really want to use a slow interpreted language for database functions, rather than one with close-to-C performance?
Also on the subject of knee-jerk Java bashing, I can't understand why so many C++ programmers resist Java, tooth and nail. Yes, Java has a somewhat bulky memory footprint (that may not be such a problem going forward with all the new 64-bit architectures out there). However, you get a ton of niceties as well, and a very sane language compared with C++. Java runs very fast these days, given sufficient JVM heap. Gcj is also getting there in terms of being useful, and provides an OSS traditional ahead-of-time compiler for Java code. Java may not be an ECMA standard, but it is open enough to permit free implementations.
Java isn't perfect...but it is better than many of the alternatives, and deserves more respect than it seems to get here on /. and among programmers in general. At least it is well supported on Linux by it's originators, unlike C# and .Net.
OK, time to do something useful now... :-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait