Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Major Changes To MySQL Coming Soon 301

Posted by timothy from the whose-sql dept.
Meltr writes: "This ZDNET article details some of the coming changes to the MySQL database server. In 4.0, to be released in mid-October: 'support for the Unicode character set, the SSL (Secure Sockets Layer) protocol, embedded database links and multitable updates' and in 4.1, to be released in December: 'nested queries and stored procedures'."
This discussion has been archived. No new comments can be posted.

Major Changes To MySQL Coming Soon More

Major Changes To MySQL Coming Soon

Comments Filter:

  • FULLTEXT search (Score:3, Informative)

    by Swamp ( 19020 ) on Wednesday October 10, 2001 @04:18AM (#2409852)
    I'm just looking forward to being able to tune the FULLTEXT search function without recompiling the database server!

  • Reporting Tools (Score:2, Insightful)

    by Anonymous Coward
    Universal Objects has also announced that their Unicode report server has been ported to Linux and is available now. Cheap, multilingual solutions might be what Linux needs for acceptance.. I belive we could beat Microsoft at the whole "total cost of ownership" game here.. What Unicode compliant database software is available free or cheap to use this with?

  • MySQL other database comparison (Score:4, Informative)

    by Secure42 ( 527416 ) on Wednesday October 10, 2001 @04:46AM (#2409897) Homepage
    It sounds great, MySQL it is trying to implement many features that were missed without loosing speed.
    You can have a look to these comparison between Mysql-PostgreSQL and other open source databases [geocities.com].

  • Stored Procedures! Yay (Score:2, Interesting)

    by serps ( 517783 )
    Excellent. One of the reasons my company decided to hold off on porting to mysql was the lack of stored procedures. A pity; now they've moved to DB2 and the moment is lost.
    • We've just done exactly the same thing. I miss MySQL's overall simplicity...it makes it really easy to develop quickly. after 6 momths of using DB2, i still feel like it's more in the way than actually helping me get the app developed.

      there's no way we can go back now either...we're an IBM strategic partner (but the upside of that is we get nice hardware to play with for free...where's the Regatta?)
    • I can tell already that this is going to be a flame war, but here are my two cents: PostgreSQL has stored procedures, unicode support, transactions, triggers, rules, and all sorts of other goodies! In fact, there is precious little that PostgreSQL doesn't have. I am using it for several projects at work, and I love it. It's great that MySQL is adding features, but it has a lot of catching up to do.
      • In fact, there is precious little that PostgreSQL doesn't have.
        I'll tell you what PostgresSQL doesn't have compared to DB2, for example. IBM.
        • In fact, there is precious little that PostgreSQL doesn't have.
          I'll tell you what PostgresSQL doesn't have compared to DB2, for example.

          IBM.

          Yup, there's no doubt about it.A major sticking point in the adoption of truly enterprise-wide free software like PostgreSQL (or mySQL) is the fact that there is *any* risk factor involved in the support arrangements. IBM, like it or not, is just not going to go away. I don't think that, say, Red Hat will go away either, but their support for PostgreSQL in its incarnation as the official Red Hat Database system is more questionable. After all, Great Bridge was (alas) unable to stay in business by doing PostgreSQL development and support contracts.

          It is a wonderful thing that Open Source products do provide you with the source, but in situations where you have a major league database system that controls all your customer accounts, and you have a problem that has to get solved *today*...this isn't really a niche that is well covered yet for all Open Source products.

        • Having delt a lot with IBM DB2 support, I can tell you that it's a very sharp double-edged sword. Yes, you can get product support (for a rather expensive price), but it's honestly not very good. In fact I'd say it's really bad in the cases where you really need it, such as when a production system is crashing or doing other things that make no sense.

          Also, if linux is super-important to you, be aware that DB2 on linux isn't up to production quality yet (unless you throw massive amounts of hardware at it, and even then it's marginal). It appears IBM is still learning the linux ropes. Support for DB2 on linux also isn't as good as on other OS's, from what I've heard. (It's certainly not as good as on AIX, which is what we now run DB2 on, but that's no surprise ;) ). I can't say db2's performance or stability on windows is all that great either. If you must go with x86 hardware for your database, then you should probably look at MSSQL or maybe Oracle.

          Also, while I haven't looked at PostgresSQL, they'd be very hard pressed to do a worse job on documentation than DB2.

  • Decent comparison of mysql and pgsql (Score:5, Interesting)

    by Khazunga ( 176423 ) on Wednesday October 10, 2001 @05:05AM (#2409926)
    Does anyone know of a good comparison of both databases? Not the usual "X as feature A, while Y has not. Y is faster.". These are open-source products, so there's room for design analysis, not just the ZDNet style checklists... There's room to review the design and implementation decisions. This would ideally involve established members of both dev communities.

    What I'd like to see is a profound comparison of mysql and postgresql. I'm a happy user of both, and I currently have pgsql serving a 8 million pageviews/month site, and handling load gracefully. AFAICare, pgsql is at least fast enough. I also never had any reliability/data loss problems with mysql, despite heavy concurrent access. AFAICare, mysql is robust enough. I'd really like to find out what are the core differences in both designs to get a grasp of how fast they may evolve.

    • Re:Decent comparison of mysql and pgsql (Score:3, Informative)

      by Anonymous Coward
      Ok you can have a look to these comparisons: -http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_fea tures.html -http://www.geocities.com/mailsoftware42/db/ -http://www.mmlabx.ua.es/mysql-postgres.html (Spanish) -http://openacs.org/philosophy/why-not-mysql.html -http://phd.pp.ru/Software/SQL/PostgreSQL-vs-MySQL .html -http://www.mysql.com/information/crash-me.php

    • Re:Decent comparison of mysql and pgsql (Score:2, Informative)

      by Anonymous Coward
      Ok you can have a look to these comparisons:
      -http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_fea tures.html
      -http://www.geocities.com/mailsoftware42/db/
      -http://www.mmlabx.ua.es/mysql-postgres.html (Spanish)
      -http://openacs.org/philosophy/why-not-mysql.html
      -http://phd.pp.ru/Software/SQL/PostgreSQL-vs-MySQL .html
      -http://www.mysql.com/information/crash-me.php

  • Um, transactions anyone? (Score:2, Informative)

    by FastT ( 229526 )
    Another Open Source debacle. They add gobs of new features while leaving the most fundamental and important feature untouched (again). Feh.

    Go ahead, flame away, I can take it.

    • With the introduction of the Berkely DB table type, MySQL gained transactional support. It'd be nice to have native transactions for all table types, but at least this is better than nothing at all. Of course, if you want to complain about useful-but-missing features, complain about decent stored procedure support (coming, but the keyword here is "decent" -- if they only support one language, like perl, then it becomes useless), foreign keys, subselects (apparently coming in 4.1), and triggers. Of course, the way the MySQL project seems to be going, they're going to end up reinventing the wheel originally designed by Oracle 20+ years ago, while steadfastly denying that the missing functionality is useful up until the point where they announce that they'll be adding said functionality.

  • Why MySQL ? (Score:4, Insightful)

    by Anonymous Coward on Wednesday October 10, 2001 @05:06AM (#2409929)
    Yes, why ? Mysql is a very popular free sql database system , and I still have problems figuring out why.
    It supports almost none of the sql features I need. The solution to my needs(which includes free/opensource) is PostgreSQL,
    which do supports the features i require(subqueries, locking, stored procedures,views,triggers,other _real_ nice features..).
    One point that often comes up is that mysql is very fast, and it is fast, but atleast for my projects only silghtly faster than postgresql(2-4%),
    and in many special cases posgresql is way faster.
    Also the point of mysql beeing very fast disappears if you use the locking features of mysql, BDB/Innodb tables.
    For me, its postgres over mysql anytime.

    • Re:Why MySQL ? (Score:5, Insightful)

      by pere ( 23710 ) on Wednesday October 10, 2001 @06:37AM (#2410050)
      The answer is "because it does the job".

      Most small projects does not need transactions, subqueries or locking. And to really take advantages of such features you need to have some good understanding of databases.

      With mySQL you can actually make fearly decent, fearly fast and fearly stable application without using hours trying to design things optimal, (and actually without not really understanding what you are doing.)

      If you worry about +2-4 percent performance, how to handle peeks of hundreds of hits a second... then you have several good databases to choose from.

      If you should store a few thousand posts, and are hoping for a few hundred hits a day, and your web-application had deadline yesterday, and you are aout to start developing (90% of the web-application of today).... mySQL is a killer!

      (You can use it for other things as well. And it does scale fairly well (so Im told)... but then you should consider several other good databases..like PostreSQL)

      • Re:Why MySQL ? (Score:3, Insightful)

        by brunes69 ( 86786 )
        I partialy agree wit this, but I would never base any application of mine on something as incomplete as MySQL (I too use PostgreSQL). Why do you ask? Simple. Who knows how large your project will get, or what substantial new features you will want to incorperate in the future. You may never need locking, but subqueries? C'mon, that is basic stuff. Sure you can get around needing them, but its a big pain in the butt and ends up being much moe inefficient. This is why I alays stick with the best product first, to leave my opions open, and won't have to re-do everything from scratch when I switch from MySQL (non SQL-92 standard) to any other DB.
        • This is a poor way of working. You should work out from the start how large your project is going to get and the functions you are going to need then pick the best tool for the job. You can _then_ future-proof the application as much as possible, for instance using database wrappers to make the code DB independant. Also, if you start on something that is _missing_ features then porting to a compatiable-language application with _extra_ features should mean NO rewriting of code. From your "I'm going to install the best possible no matter what the expense just in case" attitude I bet you were a hit during the dot-com boom :-P

          Phillip.
    • I was going to post a well reasoned reply to this, but, hmm, about 1/2 hr ago I couldn't log into /., and all the non-static pages were just taking me back to the front page. Hmm, that couldn't be because MySQL crashed (again) could it?

  • Mysql is ace (Score:3, Interesting)

    by Anonymous Coward on Wednesday October 10, 2001 @05:15AM (#2409942)

    1. Microsoft Access is more functional, easier to use and deploy than MySQL.

    More functional? I could explain theoretically why that statement is utterly ludicrous, but I'll merley give a practical example:

    A big British financial organisation maintained internally, its publicly available financial data in Access. I wrote a system for them, using GNU/Linux, MySQL and mod_perl, which allowed web visitors do perform complex searches on this data. The internally-maintained big Access dataset was imported into the MySQL datbase via an import system I wrote for them. Now here's the interesting thing - they began to realise that the web-based system, even over an ISDN line, returned data substantially more quickly and reliably than did Access, even after they upgraded to the (ACID compliant) SQL server! Indeed, the latter constantly corrupted their data, would get into all sorts of unremovable row-locks and god knows what else in its attempt to remain beautifully ACIDic. Eventually, they ditched it and now use my system (with a content management client they've had written which accesses MySQL via myODBC). They've been using this for just under three years now, and there has not been, cumulatively, even one minute's downtime.

    • Yeah, but MySQL doesn't have the paperclip, does it? Nuff said. :)

    • Re:Mysql is ace (Score:2, Interesting)

      by Red Avenger ( 197064 )
      You speak as if you know a lot about MySQL and thats great. It sounds to me that you aren't as familiar with SQL server and as such will trash it now. We have a guy at work who does the same thing. Anything made by MS is instantly crapware not fit for anyone. Problem is this guy is a server administrator who is in love with linux.
      We are a windows shop and he does everything in his power to push linux over windows always saying snide comments. He doesn't even take the time to learn how to use it properly. Anything will be better if you don't give it a chance. But if its your job to administer the servers. Shouldn't you at least do a good job? If I take money from someone to do a job I owe it to that person to give them good service. Is this different in the Open Source crowd?
    • Jet sucks, I agree wholeheartedly. But MS Access can now use MS SQL Server databases for its backend, and it comes with MSDE, the db engine for MS SQL Server. It's crippled to only perform 5 concurrent operations (it serializes them after that), and your db size is limited to 2 gigs, but you otherwise get the full db backend. Then compare MSSQL2k's pricing to Oracle or Sybase when you do want to upgrade your backend. Access has raised the bar significantly here... I can't see using Access as anything but a front-end though. I think you and the original poster are comparing apples and oranges.

  • The best opensource DBMS/R is here ... (Score:5, Insightful)

    by Anonymous Coward on Wednesday October 10, 2001 @06:00AM (#2409999)
    I am quite frightened when i see people still using MySQL ...

    Ok, it's a nice database but it lacks from major steps :

    - fast and decent transactions
    - procedures
    - triggers
    - views ... (AFAIR there is no views)

    Why do not people user alternative database such as PostgreSQL or Interbase ?

    For instance insterbase and its sister projects (IB Phoenix : http://www.ibphoenix.org/ , FireBird: http://firebird.sourceforge.net , ...)

    The basic specs of interbase are :
    - full SQL92 compliant (entry level)
    - not fully SQL99 compliant

    For instance you have :

    - fast transactions
    - super fast blob/clob feature
    - procedure (full SQL92 here!!!)
    - trigger
    - strucutred data types
    - JDBC2.0 driver (type 4 JDBC3.0 is underway ...)
    - cool tools (admin, major crash fix and recovery stuffs ...)
    - easy data deployment (thru .gdb files)

    Under linux there are 2 architecture, the classical server and the super server (cf the docs).

    There are also cool and nice free GUI admin tools such as IBAccess:
    http://sourceforge.net/projects/ibaccess/

    All these stuffs are opensourced and free (as in beer) !

    No more hesitation ... go for a powerfull database ;-)

    • Re:The best opensource DBMS/R is here ... (Score:5, Insightful)

      by Colin ( 1746 ) on Wednesday October 10, 2001 @06:17AM (#2410027)
      I use MySQL for one of my web based applications, and I use Oracle for others. For the one I use MySQL for, I chose it because:

      - It's easy to run.
      I don't have to do much (if any) maintenance and management - I don't need to check if redo logs are too small, don't need to check for extents growing out of control etc.

      - It's fast.
      For my application - with simple inserts and deletes, MySQL is really quick. That saves me money - I can get away with a single processor Linux box for my database server, rather than something much more expensive.

      - I don't need the features of a larger database.
      I'm using MySQL to store and retrive information - basically a distributed file system. I don't need clever locking, transactions, views, foreign keys, triggers, stored procedures. On the applications I do need those features, I use Oracle.

      - It's cheap
      I looked at PostgreSQL, but it was going to take me a while to figure out how to get it set up - I find MySQL very easy to install and get running. Oracle was going to be very expensive - and it's not that easy to install and get running properly.
      When you add in the costs of installation, learning how the software behaves, and the management time in keeping the software running, MySQL (for me) came out as the most cost effective option.

      Colin.
      • Why do you imply that postgresql is hard to setup?
        It's very easy, a piece of cake. So you don't
        need the features of postgresql. Does it hurt to
        have them on hand if you need them in the future?
      • PostgreSQL isn't easy to install and get running properly? RH and Mandrake, at least, will install it for you when you install Linux. Automatically. Set it up so it starts up when you boot up and dies gracefully when you shutdown.

        It doesn't get any easier than that.

        PostgreSQL is *simple* to run and *simple* to administer. I've not used MySQL so can't directly compare, but the effort required to keep a PostgreSQL server running is so close to zero that MySQL can't possibly be significantly easier to administer.

        I'm not knocking MySQL in this comparision, just wondering how the heck someone who is competent to administer Oracle can describe PostgreSQL as being anything other than trivial to install and administer.
      • It's[MySQL] easy to run.

        I looked at PostgreSQL, but it was going to take me a while to figure out how to get it set up -...

        Here's how I read this: "I spent five minutes looking at the Postgres docs. Then I gave up and went back to MySQL."

        I know this isn't true, at least I suspect it is not from the content of your other posts. But I think the most cracked-out zealotry for MySQL comes largely from people for whom MySQL has been their only database -- script kiddies and beginning Perl/CGI peons in start-ups that have MySQL as default from their hosting provider or somesuch. Most of them don't even know what most database terms mean, let alone can derive a coherent value statement from them. People scream loudest when they are threatened by obsolesence.

      • Might I suggest some additions:

        • linux.sybase.com - has all the fancy triggers and stored procedures, and the binary license is free (for the 11.0.3.3 release). Sybase is also very close in syntax and behavior to MS-SQL Server (they were the same codebase to release 4.8), so it's a good Linux evangelist tool for MS shops. They also have a 64-bit version for Alpha. On the downside, it's not very ANSI-SQL 92 compliant.
        • Postgres - getting more of the fancy features everyday, and support within RedHat is very strong - no need to recompile the webserver to use it. I have never understood why RedHat doesn't include DBD:Pg, though. Does Postgres have foreign keys yet?

        These are all really great tools; why leave them out? I like Oracle too, but $10k per processor is pretty steep. Hey, it's big and slow, but at least it's expensive!

    • I am quite frightened when i see people still using MySQL ...

      Ok, it's a nice database but it lacks from major steps :

      - fast and decent transactions
      - procedures
      - triggers
      - views ... (AFAIR there is no views)

      First of all MySQL does has robust transactions. InnoDB's table type really rocks. Probably it is not very stable yet (there was found some problems with blobs some time ago) but it becomes better and better.

      As for procedures and triggers and all other simular stuff. I wonder if it is really important to have it. I've seen some projects with heavy usage of procedures, triggers and other stuff. All busness logic of applications was implemented by them. It was very unmaintanable. IMHO more powerfull approach is three-tear architecture where middle layer (outside database) implements all busness logic itself.

      IMHO procedures are often overused. Probably they are required sometimes but only sometimes. If you think you need them than rethink you design. Maybe all logic you are going to implement with them should be implemented in middle layer?

    • Perhaps this is my complete ignorance in regards to alternatives to mySQL, but my webhost and many other webhosts already have it set up with rather easy access.

      Do I have the option to load in an alternative? Or should I take the time and energy it would take to do that to learn and understand the limitations of mySQL.

    • My company is currently trying to decide between MySQL and PostgreSQL, with the latter being the likely choose.

      We're currently using Interbase, and I have to say that it's the biggest pile of fetid horror I've ever had the displeasure of having to maintain. Why?

      • First off, you have to specify the exact path of the database file on the remote machine. That is, you can't connect to database FOO on host BAR - you have to connect to /var/databases/FOO.gdb. Heaven help you if you ever change your directory layout and run multiple applications against the same server.
      • The command line client, isql, is awful. It has no supports whatsoever for readline-esque features such as command history, or even deleting the previous character. Standard procedure is to type queries in a text editor and then paste them into the isql shell.
      • A nice feature we discovered: suspending the isql client with ^Z will lock the server until you foreground the client process again. We were NOT amused to discover this: "HEY! THE $#!*(@# SERVER IS FROZEN AGAIN! WTF?!?!?"
      • We've experienced several (!!!) cases of database corruption where we were completely unable to recover any data inserted into a database after that point.
      • AFAIK, no equivalent of mysqldump exists for Interbase. At least, I was unable to find one when I critically needed it (see previous point). I eventually hacked one up in Perl that works OK for our needs, but that still rather surprised me. AFAIK (yes, twice in one post! :), you can only back up the binary database to another binary file. BTW, my boss gave me permission to release my backup tool under the GPL. Email me if interested.


      The only reason that we're using the much-despised database server is that our rather largish apps are written against it, and it will take a bit of effort to change. Also, given the lack of the SQL dump utility (other than the hack job I put together), getting information from Interbase to anything else is non-trivial.

      It may be good in theory, and I'm sure that some people like it. For us, however, Interbase is completely undependable and just barely usable for routine tasks.

  • Which front-end are you using for your MySQL-PgSQL Databases?
    I am interesting from hearing about your experience.
    I have tested:
    - MS Access through MyODBC
    - StarOfficce through MyODBC or UnixODBC (it is missing native support connection to MySQL but it is in StarOffice TODO list, maybe in forthcoming StarOffice 6.0? :)
    - Rekall [thekompany.com]: it is still in Beta but seems really awesome
    Do you know any other alternative which one it is your prefered? i would like hearing about you
    • phpmyadmin [sourceforge.net]

      phppgadmin [sourceforge.net]

      • Yep, phpMyAdmin is great; really everything you'll ever need to administer your MySQL database. Once a month or so I drop into command-line access via telnet to do a big, tricky query, but that's more a "because I can" kind of thing -- phpMyAdmin always allows you to execute queries directly if you want.

        As far as user front ends go -- just write everything in PHP. Look at the phpMyAdmin code if you want some ideas; they don't mind! Anyone with a decent amount of Web development and general programming knowledge can whip up a good-looking, functional PHP-based Web interface for a MySQL database in a very short time.
    • In that past I've used Access to prototype, then exportsql (in the Mysql contrib page - it's too slow get grab a link right now) to create the script for mysql.
      Now I generally use PHPMyAdmin [phpwizard.net] to do it through the web.
    • DBTools [bol.com.br] Is a pretty nice Windows-only front end (Though it will easily admin a server on a linux box.) - It looks a lot like Oracle's tool did 5 years ago, but it really works pretty well.
      This is the tool I recommend to people coming from MSAccess. I often use it when creating tables because I can never remember the syntax for doing auto-increment fields...
      It will take you about 5-10 minutes to figure out how it all works and it doesn't insult the intelligence of the command-line crowd.
      Hope this is of some use to somebody...

      Cheers,
      Jim in Tokyo

  • great to see progress! (Score:4, Insightful)

    by Lumpy ( 12016 ) on Wednesday October 10, 2001 @07:08AM (#2410092) Homepage
    This is great! When I forayed into the SQL land 3 years ago I dried postgreSQL first because it was a "pure" SQL that was a true GPL and free.. but honestly, MySQL is tons easier to set up and use and program for. So that is what I settled on, it just added a step for me, I had to show a client how to download and install it to meet the license requirement at that time.. (Shoulder driving, click there, click ok, now type rpm -i *.rpm.. cool I can take over now!) I use it extensively today, and the documentation seems to be greated for MySQL than postgreSQL. Is that a fact though? is there sources for postgreSQL for dummies? or nice comprehensive manuals? or 3rd party books?
    • the docs on the postgrersql home page are superb. They've combined their three docs (Admin,User,Programmer) into one so it is fairly easy to use and they have a nice sql reference.
    • I would recommend trying PostgreSQL again. Relatively recently (v7.0 and v7.1) there were some major improvements in terms of speed at least. As to setting up PostgreSQL (i.e. create and configure a database), it is very easy, once used to it, and the documentation is pretty good (http://www.postgresql.org/idocs/ [postgresql.org] ).
  • I'm very new to MySQL and I only used it with the Innobase backend so far.
    But what's the best MySQL type of (transaction-enabled) tables :
    • BerkeleyDB
    • InnoDB
    • Gemini

    Or something else, new to MySQL 4?
    Anyone has experience or benchmarks with these different types of tables?

  • Why people use MySQL (Score:5, Insightful)

    by ACK!! ( 10229 ) on Wednesday October 10, 2001 @07:47AM (#2410143) Journal
    It goes a little like this:

    1. Someone needs a small easy to install database quick.
    2. Sysadmin knows PostGres is superior but also knows that MySQL is dead easy to set-up quickly. He has set up MySQL before since someone told him how easy it was. He uses that.
    3. People are so impressed in the organization that he got the thing up quickly they start suggesting MySQL for larger projects where it falls flat.
    4. The organization gets turned off to Open-Source databases and chooses Oracle or DB2 instead totally bypassing PostGres which is sad.

    In the end PostGres gets completely bypassed. Lots of people cut their teeth on MySQL so when someone needs a small database set up really quick they choose it. If more people used PostGres initially I think they would never look back. However, I understand immediately why MySQL is used so often.
    • Find me a link, or point me to the docs that tells me what to do after typing apt-get install postgresql postgresql-client that will get me set up with a user called "web", and a database called "webdata" that I can use from PHP.

      With MySQL its:

      • apt-get install mysql-server mysql-client
      • vim /usr/share/doc/mysql-server/README.Debian (because apt-get told me to)
      • mysqladmin -uroot password 'newpassword'
      • mysql -uroot -pnewpassword
      • CREATE DATABASE webtest;
      • USE webtest; CREATE TABLE test ( blah INTEGER NOT NULL );
      • GRANT ALL PRIVILEGES ON webtest.* TO web@localhost IDENTIFIED BY 'some-password'; (found the syntax by searching the mysql manual on mysql.com)
      • exit
      • mysql -uweb -pwebtest webdata


      I spent a few hours one weekend trying to perform these equivalent operations with pgsql, etc. Granted I work with MySQL every day, but I wanted to try out PostgreSQL and see how it compares. It took me forever to find out that I needed to 'su' to user postgres in order to connect to the freaking database! Grr.

      I'm willing to try, but somebody needs to point me to the right parts of some manual, FAQ, or HOWTO ... because dammit if I didn't actually go and do just what I said I would do above to make sure that it worked, and now I have an installation of MySQL running in less than 5 minutes.

      --Robert

      • I'm not sure I understand. Why should a relational database -- a hugely complex and complicated program that is used to do complex and complicated things, in an environment that can be set up into hundreds of different configurations -- be easy to install?

        When I make the decision to use something other than a flat-file and go with a relational database, I usually have a larger window than 5 minutes to setup, install, make structural and architectural decisions. The difference between 5 minutes and a day is irrelevant when you're talking about a development time of weeks or months.

        I've never used MySQL. I've found that anything that I don't need transactions and stored procedures for, I can accomplish quite well with simple flat files.

      • from memory:

        root@host# su - postgres
        postgred@host$ createuser web
        [create new databases?] [hit no]
        [add new users] [hit no]
        postgres@host$ createdb webdata
        postgres@host$ psql
        [add the db structure interactively or read it in from a file, see the man page for psql]
        [use GRANT to selectively give 'web' and whoever else privledges on 'webdata' or the structures therein. this is stone standard sql, of course.]
        postgres@host$ logout

        then use this for your PHP connection string, roughly speaking:
        'localhost:5432:webdata','web','' (no passwd)

        the 5432 is the default port it runs on in tcp/ip mode. which is iirc the default in most cases.
        if you wanted to give the 'web' user a password that isn't hard to do but the particulars have slipped out of my head at the moment. this assumes you're postgres owner user name is 'postgres' of course, and that you've started the postmaster daemon already. don't know if the debs do that, I don't run debian.

        that should get you started. more info is the docs, try specifically the getting-started guide, and then like the administrator's guide. Postgresql is a _lot_ more flexible than mysql, the price you pay for that is a little more complexity.

        Oh, and you don't need to su to postgres to connect to the database, but you DO have to have made a postgresql-user for $login to connect from $login. 'createuser' isn't hard to remember. :^)

        I can have postgresql up in about 5 minutes too, if I use binary packages (I usually compile from src). It's just familiarity. For comparison, it takes me ages to remember the mysql-way to do the things I've described here, e.g. the "IDENTIFIED BY" is a new one on me.

        HTH
    • I've gone through a similar path, but for me mySQL has done everything I've thrown at it. I have 50 people banging at it continuously every day, and what they do is mission-critical.

      The truth is that many of us have been with mySQL for years. When Postgres was first created, it was slow, very difficult to install, and used some kind of non-standard version of SQL. mySQL was fast, easy to install, and easy to upgrade from the mSQL database I used before. So I have been using mySQL ever since, with no need to switch.

      I might well use Postgres if I was starting database programming for Unix/Linux now, because the feature set is in fact better. But it looks like mySQL is going to gain the missing features quickly, so it doesn't seem like switching would be worth the effort.

      D
    • If setup is the problem, then the system administration design is lousy.

      When fixing this, forget "wizards". Don't configure via makefiles. Don't use user-edited text files. Make the setup mechanism find out as much as possible by itself. "You should never have to tell the computer something it already knows", as Apple once put in their developer guide. Ask how little the application really needs to know to get its job done.

    • Try throwing 20 million rows in and out of the server everyday. Big RDBMSes still have a place. Write portable SQL as much as you can.

  • Ahhh...a MySQL post.... (Score:4, Funny)

    by bozone ( 113268 ) on Wednesday October 10, 2001 @07:54AM (#2410151)
    1. Search Slashdot for old articles on MySQL
    2. Set filter to 3
    3. Cut'n Paste a rant about MSSQL/Oracle/DB2/PostgresQL being superior
    4. Cut'n Paste a list of features that MySQL needs to be a real RDBMS
    5. Make it known to the world that I will never use MySQL until it has the above features
    6. Watch my karma grow
    ...my work here is done...
    • Maybe people are repeating those rants because they still hold? Without support for simple things like stored procedures or views (really, i can take one or the other in my case, but i can't lack both), and subselects, I just can't use MySQL. No hard feelings, but I certainly won't join the clamoring throng that defends a product too mediocre for me to use.
  • According to the article:

    "The GPL allows open-source programs to be changed by users, but those changes aren't official and can't be sold commercially unless they're given back to and accepted by the owner."

    That's not exactly how I understood it. My impression was that the GPL was a recursive license allowing the free use and modification of code, but requiring that said modifications also be made freely available under the GPL. I didn't think the person whose code I was modifying had to accept my modifications in any way. Nor did I think it was directly incumbent upon me to send them to him.

    I wonder what it is about journalists that makes them so capable of half-understanding so many things?
  • It's about fucking time!

    MySQL has been mired in the stone ages of Dbase4 for years; these will be welcom additions and will definitely help MySQL overtake some of its lofty closed source competitors.

    Me, I'm sticking with PostGreSQL. But I applaud the effort of the developers to make their application into something that DBAs worldwide can feel proud to add to their resumes.

  • To all those who are comparing MySQL to PostgreSQL, I'd like to comment on why this is good.

    First, competition will make them both better. The whole point of open source is *more* choice, not less. Stop complaining that MySQL is finally catching up to PostgreSQL and use which one you want. They both have their strengths and weaknesses. It's not like they both cannot coexist.

    Second, I use MySQL occasionally now because most ISPs seem to support it. PostgreSQL is great, but I cannot use it because my clients have long since chosen their ISPs and it is a major PITA to change for many reasons.

  • I never hear much about "alternative" commercial databases like Frontbase or SOLID Server... what good are they ? Did anyone tried them in a web environement ?
    • I've never heard of either of the databases you mention, so I can't comment on them.

      Typically, there are two reasons why people go with commercial databases:

      - Support
      - 'Quality' (more robust, more scalable, etc.)

      Support is pretty obvious... something goes wrong, you call. I'm sure some companies are much better at providing support than others, but it's a pretty safe bet that you'll get better support for a commercial database than a free one. And before the flames start, by support I mean 24x7 support, the kind of support you need when a system is down. Popping into an IRC channel and hoping someone's awake isn't a very good support plan when you're losing business by the second :)

      Quality depends greatly on what you're trying to do. For example, would you open an account with a bank that uses MySQL to keep your account information? Or trust a hospital to keep your medical info in MySQL? Big databases like DB2 and Oracle provide the tools you need to ensure data integrity. They also have a well-proven track record of use in industries where losing or corrupting data simply is not an option (I'm talking things like NYSE and financial institutions, not some e-store or a simple website).

      Another issues is scalability. People love to tout MySQL's performance, but it's very easy to see where you can make it fail. Not having row-level locking means good luck using it in a OLTP system, for example. It also doesn't cluster (which is an absolute requirement if you're going to do anything serious on x86 hardware).

      On the other hand, it'd be pretty silly to pay for something like DB2 just to run a small website.
  • How do they plan to do SSL? OpenSSL isn't licensed under a GPL-compatible license.

    If they've built a whole new SSL library, I'm impressed.
  • Anyone know a good way to address a SQL Server database from an application using the mySQL API?

    That is, is there any type of library available that would let my Unix C program talk ODBC to a SQL server system?

    I know about ODBCSOCKETSERVER, and it's what I use now, but it's not robust enough for some of the things I want to start doing, and I'd really like to have a system that directly talks ODBC under Unix instead of having to go through a Windows box with ODBC installed. (I don't want to run the bridge on the computer that actually contains the SQL server interface).

    Thanks for any thoughts.

    D

  • Why use any DBs at all? (Score:2, Interesting)

    by deblau ( 68023 )
    Wearing my programming hat, I have to use the right tool for the job. If I don't need lots of nifty DB features, I'll use my native filesystem structure to store data, or even a flat file. Remember those? If I need bells & whistles, I'll choose a DB that has just what I need, and no more. Why waste cycles (or licensing fees) on worthless features? If I need transactions (for example), and I don't want to spend $$ on proprietary DB licenses or on man-hours trying to figure out a complicated open-source DB (remember TCO?), I'll code it myself with something simple like MySQL on the back end. If I do need scalability/lots more features/whatever, I'll pony up the time/money for the big boys.

    Right tool, right job.
  • I will agree that for 99.9% of MySQL users MySQL runs just fine. They don't need, nor care about, sub-selects, row-locking, triggers, etc.

    We used to run MySQL but found that it died *horribly* on heavy multiuser loads. (e.g. 500 concurrent users, all updating/insert/etc.)

    I investigated the problem and found out that table locking really, really sucks. Last summer when we had this problem we didn't have the luxury to mess around with pre-alpha table structures and spend countless hours poking around with settings.

    I carefully explored the other RDBMS's out there and eventually picked Sybase ASE 11.9.2 for Linux as the best choice. I can say it was hands-down the best choice we made. Now we're at 12.5 which supports SSL, XML, etc. and a host of other features MySQL hasn't even thought of.

    Instead of 'dealing' with MySQL we're making money with something else.

    So here it is:
    If you are having problems with MySQL - DON'T PUT UP WITH IT. There are many other fish in the sea that will better fit your application. Simply because it is 'free' or 'popular' does not make it better for your application.

    As someone else said, I always follow the 'pick the best tool for the job' test. If it is out of our price range, we either find a way to buy it or move on to the next item on our list.

    I think far too often people perform the 'open source' or 'free' litmus test first -- leading to major headaches down the road.

    If we were in this situation today I think we'd rather have picked Postgres, simply because it was a lot cheaper and offers many of the performance-enhancing features as the 'big three'! :)

  • You have to laugh (Score:3, Informative)

    by ErikZ ( 55491 ) on Wednesday October 10, 2001 @03:35PM (#2412284)
    I keep on seeing the same statement, over and over, saying:

    "I don't understand why MySQL is so popular, the only thing it has going for it is tha it's easier to install!"

    Answer...staring...right...at...you.

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close