Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

MySQL to Adopt Solid Storage Engine

Posted by Zonk on Sun Apr 16, 2006 09:19 PM
from the solid-gone-baby dept.
Databases Programming Software IT
hmart writes "As seen on ZDNet's Open Source Blog MySQL is taking another step to defend from Oracle's recent acquisitions of InnoBase and Sleepycat. From the article: 'MySQL responds by getting Solid Information Technology, a proprietary database vendor, to take its solidDB Storage Engine for MySQL open source, under the GPL, starting in June.'"
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

MySQL to Adopt Solid Storage Engine 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • This is good news (Score:5, Interesting)

    by IntelliAdmin (941633) * on Sunday April 16 2006, @09:21PM (#15140461) Homepage
    It seems that Oracle is not taking the threat from MySQL lightly. The purchases they have made have been quite public, but they also have been quietly hiring developers from many different open source projects. It is scary how many of them have dropped off the radar. On a side note: I was always under the impression that MySQL was a 'amateur' database. I was very surprised when I was forced to switch from Microsoft SQL 2000 - MySQL had a much smaller memory footprint, and the performance just blew me away. To this day I still cannot believe the performance difference. It really speaks to the power of Open Source.

    • Re:This is good news (Score:5, Insightful)

      by ScrewMaster (602015) on Sunday April 16 2006, @09:31PM (#15140492)
      Well, it's one thing to acquire a company in order to deny your customers and potential customers access to a competitive product. It's quite another to hire away a bunch of developers and keep them. That's difficult, especially if they happen to be the cream of the crop for a particular industry. As soon as you don't give them what they want (and money is only part of the picture) they'll drop you like a hot potato and look for greener pastures. I'm not slamming Oracle in particular since I don't know what the place is like for the development staff: it might be a great place to work. But job satisfaction is an important aspect to any position for a good programmer, and if you're good (and that is presumably why Ellison is hiring these guys) you have a lot of options. My bet is that a few years down the road you see some of those missing coders back on the radar.

      • Re:This is good news (Score:5, Insightful)

        by grasshoppa (657393) <skennedyNO@SPAMtpno-co.org> on Sunday April 16 2006, @11:21PM (#15140744) Homepage
        The problem being once these important OSS coders see oracle source, they are tainted. Any further OSS contributions will have to be heavily scrutinized for IP violations.

        So oracle does not need to keep them. They just need to expose them to even bits of their db source, and they have tainted the coder.

        Devious, if you ask me. I am impressed. Or I would be if it didn't damage my own interests.
        • The problem being once these important OSS coders see oracle source, they are tainted.

          That's not true, any more than someone can be "tainted" by working at one company and then getting a job at another. There's something to being cautious but it's simply not possible, especially in california which disallows non-compete agreements in almost all cases, to take away someone's open source livelihood by "tainting" him. There's nothing special about open source software.

        • Re:This is good news (Score:5, Informative)

          by swillden (191260) <shawn-ds@willden.org> on Monday April 17 2006, @01:54AM (#15141019) Homepage Journal

          The problem being once these important OSS coders see oracle source, they are tainted. Any further OSS contributions will have to be heavily scrutinized for IP violations.

          Yes and no.

          Strictly speaking, there is no such thing as a "tainted" developer. There are three different forms of IP law that Oracle might try to use to control what the programmers do after they leave the company:

          1. Copyrights. Copyright only covers the specific code, not the ideas. A developer could learn how to do something while working at Oracle, and could then leave the company and implement the same thing and it wouldn't constitute copyright infringement as long as the second implementation was done from scratch. Technically. In practice, if the resulting code was extremely similar, the developer might have a hard time *proving* that he didn't take a copy of Oracle's code with him when he left.
          2. Trade Secrets. Oracle could tell the developers that things they're working on are trade secrets, and make them agree not to disclose them. That only applies to the specific ideas and techniques that are designated as trade secrets, though, and only applies as long as they're secrets that haven't been revealed elsewhere.
          3. Contract. Oracle could make the developers sign non-compete agreements. Those can't last very long, though, and tend to be hard to enforce.

          So, if the developer has access to a good lawyer, it seems like Oracle really can't do much to prevent future work. But, of course, a wealthy corporation can afford legal battles much better than an indiviudal can, and any or all of the above would lend enough credibility to a lawsuit by Oracle that the coder might end up having to fight it in court... which can be really expensive even if you win. Then again, this is exactly the sort of case where the EFF and others would probably be willing to step in and help out.

          Finally, if Oracle failed to terrorize the devs into meekly going along, Oracle probably wouldn't want to go to court very much. Not only is it bad PR, but it does cost a lot of money, even if you're a corporation with deep pockets. There has to be a reasonable expectation that the cost is worth the result, which seems pretty unlikely. Threatening a lawsuit you probably can't win doesn't cost much, but actually pursuing one does.

          So oracle does not need to keep them. They just need to expose them to even bits of their db source, and they have tainted the coder.

          No, I really don't think that's enough. What they really need to do is to terrify the coder with weighty, frightening non-disclosure agreements and non-compete agreements. If they do too much of that, though, they won't get the hire in the first place.

          Of course, IANAL. But I have read the relevant law, and have some familiarity with the applicable precedents, thanks to other cases.

          I really hope that the open source developers who've gone to work for Oracle have run their employments contracts past attorneys of their own.

    • Re:This is good news (Score:5, Insightful)

      by NitsujTPU (19263) on Sunday April 16 2006, @10:38PM (#15140653)
      That's kind of the thing.

      I don't want to offend MySQL devs, but, eh, here goes.

      MyISAM isn't so hot. It doesn't support transactions... it won't enforce your referential integrity constraints... it doesn't work like, probably, it should. It indexes things so you can look them up quickly with SQL queries.

      InnoDB on the other hand, sticks all of the features into MySQL that it needs in order to be considered a serious database engine.

      When Oracle bought InnoDB, they bought all of the stuff that makes MySQL actually useful. In order to stay competitive, MySQL will need a new storage engine... or perhaps keep updating the GPL'd version of InnoDB. The response has been to get a new commerical engine that works out of the box open sourced, so they can keep the edge that they need in order to stay in the game.

      • Re:This is good news (Score:5, Informative)

        by Antony T Curtis (89990) on Sunday April 16 2006, @11:16PM (#15140729) Homepage Journal

        Oh, I doubt that there is a single MySQL developer who would be offended. We are not so aloof that we cannot take criticism - actually we welcome constructive criticism, it lets us know what needs to be improved.

        Perhaps we have been a bit lazy: Assuming that the partnership with Innobase would continue forever and that MySQL would eventually acquire Innobase.

        MySQL has a few advantages - it is a small company which can react quickly to unexpected changes. We learn. Jim Starkey has joined us - he is a veteran of relational database designs and a delight to work with - and we do plan to have our own storage engines with transactional goodness, we already have Cluster but we need something more lightweight usuable by everyone.

        In the meanwhile, it is good to take advantage of the MySQL architecture and make partnerships which can make use of one of our strengths. Having 3rd party storage engines is something which has been quietly encouraged for many years and is now something I think will see more publicity.

        (disclaimer: opinions are my own and not of my employer nor anyone else)

          • Re:This is good news (Score:5, Interesting)

            by Antony T Curtis (89990) on Sunday April 16 2006, @11:49PM (#15140804) Homepage Journal
            Anyway, on a lighter note, this new engine looks pretty hot, and like it could take MySQL in a lot of directions that I never really foresaw it going.


            I think it would be fun to make MySQL as versatile as possible with a huge choice of plug-ins available. Sort of like what Linux is for operating systems but for databases instead. MySQL is platform agnostic and want it to perform well everywhere, including Microsoft Windows and even... SCO (hey, its not their customer's fault).

            If there is anyone out there which has some kind of data storage/retreval system, I am sure that MySQL would be happy to assist and encourage them to make it into a storage engine for MySQL. If they want to GPL their code and join the open-source party, I am sure MySQL would be happy to help in that too.

            • Re:This is good news (Score:5, Funny)

              by NitsujTPU (19263) on Sunday April 16 2006, @11:55PM (#15140814)
              SCO has customers?

              • Re:This is good news (Score:5, Funny)

                by jusdisgi (617863) on Monday April 17 2006, @12:14AM (#15140853)

                SCO has customers?

                No...didn't you see, he said "it's not their customer's fault."

                customer's

                ...is a singular-possessive.

                customers'

                ...is the plural form.

                SCO doesn't have customers. They have a customer.

              • SCO's still somewhat big in the medical profession. Being one of the first "cheap" unixes, a lot of small medical offices went to SCO in the early 90s during the first big rush to digitize patient charts, etc. I've got a buddy who deals with a lot of SCO installs on a daily basis. It's still used because though SCO is a pain in the ass, migrating away from these recordkeeping apps would be even more painful.
              • I think that everyone's like "ok, we kind of win the web browser wars... lets move to Office," the difference is, firefox really is better than IE. Can you really say that OpenOffice is better than MS Office?

                Ah, ok. I was just curious as to your thought process.

                As to whether I think that OOo2 is better than MSO 97 (that's all I have), well, it's hard to say. Word 97 & Excel 97 are very snappy on my Win2k 933MHz/256MB RAM laptop, and OOo2 is really snappy on my Sempron-754 2800+/1GB RAM PC and does eve

      • Re:This is good news (Score:5, Insightful)

        by spiritraveller (641174) on Sunday April 16 2006, @11:30PM (#15140765)
        In order to stay competitive, MySQL will need a new storage engine... or perhaps keep updating the GPL'd version of InnoDB.

        I don't think that is not an option. MySQL AB has a dual-licensing scheme for MySQL. They need another company (like Solid) from whom they can dual license an engine for use with MySQL.

        Now... if they wanted to go completely GPL and quit selling MySQL for use in proprietary applications, they could keep updating the GPL version of InnoDB and keep distributing it. But then they would lose the revenue that comes from the proprietary-licensed versions of their product... and there goes their business model.
            • i agree, even for simple applications transactions are heavily needed.

              you could always do

              insert into A(...., complete) values (.... ,0);
              insert into B..
              insert into C..
              #if smth went wrong, just delete the stuff
              #if it went right, make A valid ...
              update A set complete=1;

              and always query for A's where complete is 1 ... but this still scks :p and there's still invalid data in b's and c's :p locking is a `weird` approach in terms of performance, infact you're getting rid of the performance in most cases :D

      • Re:This is good news (Score:5, Interesting)

        by drDugan (219551) on Monday April 17 2006, @12:22AM (#15140872) Homepage
        PostgreSQL is a much bigger long term threat to Oracle than MySQL. The one place where Oracle still has an advantage over FOS projects is in big iron and big databases. PostreSQL has closed that gap significantly where (I believe) MySQL never will. It simply will not serve the market need that Oracle meets now.

          • Re:This is good news (Score:5, Insightful)

            by killjoe (766577) on Monday April 17 2006, @05:55AM (#15141285)
            "People who choose database vendors and make other such big IT decisions for companies like GM, Boeing, Wal-Mart and such, think "Open source = toy for the geeks"."

            Yes that's why no large corporation in the world uses mysql. Hey wait a minute that's a complete lie isn't it? There are lots of fortune 500 corporations using mysql aren't there. Never mind.

            "They want top notch support, perhaps even an Oracle team to be on-site for a couple of months during deployment, they want someone to blame and to complain to when things don't work right. MySQL provides support but it is just not going to be the same quality."

            Spoken like somebody who has never bought support from oracle or mysql. If you pay mysql half of what you pay oracle for support they will give you the phone number of a developer. How is that for support?

            Mysql offers some of the best support of any database vendor. Go ask any of their big costomers. Then compare what they say to the customers of oracle.

            I don't mean to be a cheerleader for mysql but I really really get tired of the same old "you can't get support or blame somebody" FUD about open source.

            It's over, strike that item from your big book of FUD and find something else to complain about mkay?

          • Re:This is good news (Score:5, Insightful)

            by kpharmer (452893) on Monday April 17 2006, @08:09AM (#15141553)
            > Replication is important to oracle users and that's one area where mysql is a bigger threat then
            > postgres. Clustering is another by the way.

            No, replication isn't that big of a deal to most enterprise databases. About the only people who really think it's important seem to be MySQL content-management users that want failover. That's fine, but enterprise data management is more likely to focus on hot or cold standby solutions for failover, or ETL for copying to a reporting database.

            As a side-note, I'm currently yanking a bunch of replication out of a db2 architecture that some fool put in. It makes life much more complicated when you've got multiple replication interfaces all over the place. It'll be replaced by Federation - which simply redirects queries against original database, instead of copies data.

            And clustering? Although a very small number of Oracle users are using their product for clustering at least there they can handle more than a few gbytes of data. The solution that MySQL purchased a few years ago is limited to the amount of data that will fit into memory. This is pretty much a useless feature for most enterprise projects. Obviously any that have tens of gbytes of data or any that get frequent writes.

            The one thing that MySQL has over Postgresql is third-party support: due to its huge lead over postgresql 4+ years ago most developers based their apps on it. So, now it's ubiquitous. That's a genuine advantage. No real technical advantages that I can imagine however.
      • IBM, Novell and Sun are actually contributing to open source.

        I haven't heard of Oracle doing anything like that. What have they contributed to? Have they changed the licence of anything they own to GPL?

        If not, it doesn't sound good to me.
        • You mean projects like these (see Oracle's development tools page [oracle.com]))
          • Apache ADF Faces
          • Eclipse EJB3 Tooling Project
          • Elipse JavaServer Faces Tooling Project
          • Eclipse BPEL Designer Editor Project

          Take a look at Oracle's OSS page [oracle.com] for more projects. One of the biggest is OCFS, Oracle's clustering file system which they released with a GPL license.

          Sure most of it is to make it easier for them to sell software for Linux users, but it's out there, with various OSS licenses.

  • Note to self: (Score:5, Funny)

    by Anonymous Coward on Sunday April 16 2006, @09:22PM (#15140466)
    buy out Solid Information Technology.

    -Larry Ellison

  • it's about time (Score:3, Funny)

    by RelliK (4466) on Sunday April 16 2006, @09:23PM (#15140475)
    So mysql will now have solid storage? Finally! Oh wait, it's " Solid Information Technology". Never mind...

  • More Info? (Score:4, Interesting)

    by logicnazi (169418) <logicnazi@[ ]il.com ['gma' in gap]> on Sunday April 16 2006, @09:27PM (#15140482) Homepage
    Does anyone know where I can find more info on the sorts of options/features this storage enginge supports?

    For that matter can anyone point me somewhere which describes the deliniation of responsibilities between generic MySQL code and the storage engines? In particular is MySQL just an SQL query parser/optimizer stuck on top of storage engines?
    • can anyone point me somewhere which describes the deliniation of responsibilities between generic MySQL code and the storage engines?

      Interesting question. However, MySQL does not completely abstract the storage engine. Different storage engines have different semantics at the higher levels. For instance, MyISAM does not support transactions, while InnoDB does.

    • Something I blindly stumbled over... (Score:4, Informative)

      by Frosty Piss (770223) on Sunday April 16 2006, @10:15PM (#15140595)
      Within two clicks of the Slashdot story page, I found THIS [solidtech.com].

  • Solid has good stuff! (Score:4, Informative)

    by sgifford (9982) <sgifford@suspectclass.com> on Sunday April 16 2006, @09:33PM (#15140497) Homepage Journal
    We used to use a Solid SQL database a few years back, before I really knew anything about databases or SQL. It was extremely reliable, fast enough for everything we did, and very easy to administer (even for people who didn't know anything about databases or SQL). I haven't used it recently, but if their technology is still top-notch, this will be very good news.

  • Hooray (Score:4, Informative)

    by brennz (715237) on Sunday April 16 2006, @09:47PM (#15140529)
    As Mysql continues to catch come towards the Mid-tier in the market, Postgresql is charging at Oracle.

    The entire Database market is heading towards OSS.
    • It may be charging, but it's still a long long way from offering everything Oracle can offer. That said, Oracle is still quite lacking in its support for Indic and Arabic language handling, so maybe Postgres can accelerate in this area?
  • I guess somewhere down the line MySQL users will be pressured to move off of innodb onto this Solid DB. (At which point, we might see some community backlash and a big controversial fork where the community makes a GPL-only version of MySQL to maintain InnoDB support -- which would please Oracle greatly.)

    I hope the MySQL has gotten something in paper that will make sure that this is the last time that users have to migrate. Sure, they can claim that a migration will be seamless, but who's going to be foolhardy enough to risk their data on a transition like this without significant testing?

    Actually, now that I think about it, I don't know if it is reasonable to expect users to switch "just" so that MySQL will be able to sell commercial licenses to their drivers and what not. The switch to InnoDB took years (and it's probably still ongoing for many users), but in return, those who switched got a lot of new features that made it worthwhile (probably). This time around, there is not much of an incentive for end users -- assuming that the feature sets will be roughly comparable between InnoDB and Solid.
    • There will be no need to pressure existing users off from InnoDB .... InnoDB is GPL code and as such will always be available: This is the strength of open source software, it is very hard for players to pick up their toys and leave the sandbox. If they leave the sandbox, they have to leave their toys there. Besides, Oracle has stated that they do not intend to change Innobase's business. Lets hope that they keep that promise.

      Of course, MySQL can encourage people to use a particular product choice based upon future roadmaps but I don't imagine that InnoDB support will ever be axed.

      (opinions are my own, not of my employer nor anyone else)

  • Good, but how good not known yet (Score:5, Insightful)

    by PizzaFace (593587) on Sunday April 16 2006, @11:41PM (#15140788)
    Solid's database server has a good reputation. Philip Greenspun used to recommend Solid as a cheaper alternative to Oracle, though it seems he now recommends [greenspun.com] PostgreSQL. What all three systems have in common is multi-version concurrency control, which improves concurrent data access by tracking the changing versions of data rather than locking the data when a user might change it.

    I'm just worried about this quote from Solid's V.P. of Marketing:
    So we're going to make available code that works only with mySQL. On the side we have a proprietary line of products.
    It sounds like MySQL will use only a subset of the Solid product. So how good this news is will depend on how complete a subset of its product Solid opens.

  • Solid(TM) and the Oracle connection (Score:3, Insightful)

    by adnonsense (826530) on Monday April 17 2006, @03:29AM (#15141133) Homepage Journal

    Says here [sql-info.de] that the marketing VP quoted in TFA, Paola Lubet, used to work for Oracle.

    Now I wouldn't want to read anything into that, I'm guessing there's a lot of rotation between database companies, and it's a private company [solidtech.com] held by a bevvy of investors, so Larry Ellision presumably won't be able to drop it in his shopping basket when he pops out for some milk. On the other hand the investors sound like venture capitalists (I may be wrong, corporate finance is not my field) who might be interested in any short-term returns on their investment that a large, cash-rich company could offer.

  • MySQL tries to play catch up ... (Score:4, Insightful)

    by Tetard (202140) on Monday April 17 2006, @05:42AM (#15141269)
    ... while others (PostgreSQL) have all one needs. I guess that's an unavoidable dynamic of free software (and a good one as well -- just like in other competing open source projects). So probably one day MySQL will have everything that PostgreSQL has today, but why wait ? It's mostly transparent to move from one to the other, and there are tons of guides and scripts to convert from MySQL to PgSQL. Even PhpMyAdmin has its Pg pendent (PhpPgAdmin).

    And it's painful to go back when you've learned to do proper logic separation using stored procedures, triggers, views and transactions, things that way too many projects duplicate in the PHP or Ruby front-end, relegating the DB to the "simple" role of being a storage backend (even Ruby on Rails forces you to think that way via the MVC architecture).

    For that purpose, use SQLite -- it does what you need, is very high performance (on-disk, non-concurrent access -- can't get any faster than that). For real solid DB work, with garanteed integrity, just the way RDBMS were meant to be, go for PgSQL.

  • it is solid! (Score:3, Informative)

    by sad_ (7868) on Monday April 17 2006, @05:50AM (#15141276) Homepage
    we're using HP data protector backup/restore software, which uses solid as its database for storing all data information.
    HPDP itself is as stable as an italian taxi driver stuck behind two priests in a skoda, but thank GOD, the database is rock solid and doesn't corrupt when HPDP goes belly up again.

    so all in all, a good pick of mysql!

    • None (Score:5, Informative)

      by mrnobo1024 (464702) on Sunday April 16 2006, @09:29PM (#15140486)
      No matter which storage engine you use in MySQL, the SQL syntax is still the same. All you have to change is the ENGINE= line in your schema definitions.
      • You might adopt different strategies in code to deal with storage layers that supported different levels of transactionality or locking atomicity.

        • Re:well, not entirely (Score:4, Informative)

          by jadavis (473492) on Sunday April 16 2006, @10:37PM (#15140649)
          There are actually many differences. Full-text indexes (FTI) only work with MyISAM, for example.

          If you change storage engines, you certainly need to examine all non-trivial MySQL code.

          With MySQL, it's often hard to get all the features you want at one time. In the case of full text indexes, you can't also have transactions because only InnoDB has transactions.
      • Perhaps if your SQL is trivial and/or you're writing with portability in mind then abstraction is a good idea. If you're doing anything with transactions, locking, indexing, anything which requires the use of SQL which isn't available or identical on all databases then you can't (fully) abstract. If you're not writing with portability in mind abstraction is a waste of cycles and, more importantly, development time.
    • Here's a different idea. Don't reinvent the wheel.
    • You mean hire Sybase to write a database engine for them (up to version 6.5 SQL Server was a Sybase product) and then head hunt a bunch of Oracle DB experts to build your own version (which is what they did when they cut over to version 7)?
      • And lets all be glad that MSSQL is secretly Sybase under the covers. Because of this we have the beautiful FreeTDS packages for Perl that happily talk to MS SQL server. Those of us stranded in MS shops can actually work this way, imagine the bloodshed if MSSQL was completely proprietary!

      • Re:Here's an idea.. . Develop your own! (Score:5, Insightful)

        by jadavis (473492) on Sunday April 16 2006, @10:53PM (#15140678)
        MySQL is about choice... You can choose to use it or you can choose to use something else. You can choose to store your data in InnoDB, BerkeleyDB, Cluster, MyISAM, Memory, CSV

        "Choices" is positive spin. Some might say that MySQL is all about sacrifices. Here are some examples:

        (1) "MySQL has many applications written for it"
        * Not if you enable strict mode, or if you use storage engines that don't support the features you need.
        (2) "MySQL is optionally SQL compliant with strict mode"
        * Only if you want to forego 99% of the existing MySQL applications, and start fresh.
        (3) "MySQL has transactions"
        * Not in MyISAM, which means no full text indexing.
        (4) "MySQL is free"
        * Only if your application which links against the client library is also GPL.
        (5) "MySQL is fast"
        * Only if you use MyISAM, which means no transactions or many other features that aren't available in MyISAM.

        I could go on. Anyone can talk about how MySQL has a feature, but you have to make sacrifices for those features. And I think many of those are bad, unnecessary sacrifices. MySQL implements features not to give their users choice, but to give MySQL AB a marketing advantage. Their advocates and salespeople will always say "yes" to all of those features above, but it's not until later that the customer realizes that they can't use the features together.

        • Hmm.. I'll bite.

          (1) "MySQL has many applications written for it"
          * Not if you enable strict mode, or if you use storage engines that don't support the features you need.

          If your application is designed for MySQL specificially without strict mode, then strict mode is not for you. It is more useful to people porting their applications from some other product to MySQL than to the existing MySQL user base.

          (2) "MySQL is optionally SQL compliant with strict mode"
          * Only if you want to forego 99% of the existing MySQL applications, and start fresh.

          Ditto above. Perhaps the existing MySQL user wants to go to strict mode in order to support databases *other* than MySQL. Have you concidered that?

          (3) "MySQL has transactions"
          * Not in MyISAM, which means no full text indexing.

          MyISAM was never designed with transactions in mind. It performs its intended function excellently. Not all data is useful to keep in some kind of transaction context - take for example a table mapping UPC codes to product names and descriptions: it will never need to change in a transaction so having transactional overhead would be wasteful.

          (4) "MySQL is free"
          * Only if your application which links against the client library is also GPL.

          Myth used to scare people away from opensource GPL code.

          (5) "MySQL is fast"
          * Only if you use MyISAM, which means no transactions or many other features that aren't available in MyISAM.

          Some people would disagree with that statement. Quite a lot of people have found that for their needs, MySQL is lighter and faster (or at least, as fast as the big name products) even when never using MyISAM tables.

          There will be people whose needs are best served with products from Oracle, IBM, Microsoft, Sybase... I am sure that no one in MySQL claims that it is the only solution to all problems: MySQL is a young database product which is actively being developed so it will improve.
          • MyISAM was never designed with transactions in mind. It performs its intended function excellently. Not all data is useful to keep in some kind of transaction context - take for example a table mapping UPC codes to product names and descriptions: it will never need to change in a transaction so having transactional overhead would be wasteful.

            This is typical LAMP programmer thinking. What do I need transactions and data integrity in a database for? I'll just code the checks into my application. I prefer instead to put checks both in the database and in the application.

            (4) "MySQL is free" * Only if your application which links against the client library is also GPL. Myth used to scare people away from opensource GPL code.

            This is no myth. MySQL's client libraries are definitely GPL. If you link to them you must abide by the terms of the GPL. Alternatively, you can purchase a license from MySQL AB. MySQL AB spins this up so much saying that they are open source but what they really mean is that they are open so long as you are open.

            I'll stick with PostgreSQL. Unlike MySQL, PostgreSQL is a serious alternative to Oracle or MS SQL. It is also BSD licensed and thus there are zero restrictions on its usage within a commercial product and there is no need to purchase a commercial license.

            MySQL is okay for the LAMP mentality but when you start getting in to ORM/ERM (Object/Entity relational mapping) with packages like Rails's Active Record or WebObjects's Enterprise Objects you need a more serious database. As another poster has pointed out in this thread I give it only a few more years before mainstream open source web development moves into the ORM camp.

              • I found this page [mysql.com] which states that DBD::mysql uses the MySQL client libraries (It says this for Net::MySQL).

                If you perldoc DBD::mysql, it says it's licensed under the same license as perl (the artistic license).

                Unless DBD::mysql is saying that their code is licensed under the artistic license, but as soon as it's built against the MySQL client library it becomes GPL (and just leaving out the last part), I don't see how the MySQL client libraries could possibly be GPL only. .. Any takers?
      • > Isn't it better to have a choice of technologies?

        uh, better than what? If the answer is stability, then no.

        So, MySQL has the following storage plug-ins: MyISAM, Innodb, Sleepycat, etc, etc, etc. as an enterprise data architect (ok, sounds pompous, how about someone that implements a *lot* of database solutions) I really don't care about a wide variety of storage engines that mostly don't meet my needs. Of all of the above, only Innodb is a good general-purpose solution. The others are useful only i

          • Re:Here's an idea.. . Develop your own! (Score:4, Informative)

            by kpharmer (452893) on Monday April 17 2006, @12:31PM (#15143263)
            > What would be the list of priorities for you for features/changes to be made to MySQL in order for
            > you to seriously concider it. Bear in mind that MySQL does not have an infinite amount of developers
            > so delivering on all of them overnight would not happen.

            Now that MySQL has implemented most of the standard database features, the next step is to harden them and the rest of the codebase. At this point I'm not interested so much in features as I am high-quality & robust implementations.
                - this means that if I add a column to a table I won't have to spend hours copying the data back & forth under the covers
                - it means no more gotchas - with broken date handling, exception handling, type conversions, value truncations, etc.
                - it means that individuals clients shouldn't be able to turn off strict mode.
                - it means that non-strict mode should be deprecated - and gone in a few years
                - it means that the optimizer should be able to handle very complex joins and almost always come back with the very best possible query

            Now, *after* the above have been addressed there are some additional features to add. These are mostly oriented towards reporting functionality, where I think mysql is pretty weak right now. My list would include:
                  - oracle-style range partitioning: this means that you can using mysql for large reporting & warehousing applications. We're not talking union-all-views here, but the ability to attach & detach partitions, and disregard partitions of data from queries. I often see 10x performance gains from partitioning over indexing in this kind of app.
                  - query parallelism: need to be able to split reporting query work across CPUs. These large queries, often scanning a 100,000+ rows can typically get linear performance improvements in my experience from query parallelism.
                  - automatic query rewrite: need to be able to automatically rewrite queries in order to hit summary tables if they exist. This is critical for some types of powerful reporting tools, or reporting performance boosts for commercial apps.
                  - materialized views: simple method to manage summary tables. Not critical since this can be developed in other ways, but this has become the preferred way to manage summary tables.
                  - federation: the ability to redirect a query against a table to another database to be resolved. This allows you to define reference tables on one database, then share them across many.
                  - query failover: the ability for the mysql client to automatically reroute a query to a failover server. This allows you to provide failover without any code changes at the application layer.

            that's all i've got time to write, but should cover most of what I'd look for first.

    • Re:LARP (Score:5, Funny)

      by bani (467531) on Monday April 17 2006, @12:42AM (#15140898)
      I have been using Perl for 5 years. After 1 month with Ruby, I'm not going back.

      That's like saying "i have been eating dogshit for 5 years. After 1 month with steak & eggs, i'm not going back.". Hardly an impressive statement at all.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.