in reply to Re: Re: Re: Re: Re: Re: Version Control in Database Applications
in thread Version Control in Database Applications

Referential integrity constraints? Probably not. Most likely this will be a MySQL database. Does MySQL even have views? It didn't last time I worked with it, but I'm not fully up to speed on new developments.

Yes, this implementation would make reversion irreversable. I guess that might not be desirable although that's a better question for the clients than for me. I could implement a reversible reversion by creating a new version as a copy of the old one. That should be pretty easy to implement considering that the checkout routine will already need a cloning capability.

I think in this case my users really will want full versioning capabilities. The system they're using now has them and I think they've gotten pretty used to it. However, given what a pain this is to implement I think I can make a pretty strong argument that going with something simpler could save them a lot of money in development.

Thanks for the help,
-sam

  • Comment on Re: Re: Re: Re: Re: Re: Re: Version Control in Database Applications

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Re: Re: Version Control in Database Applications
by cowens (Beadle) on Jun 11, 2002 at 14:29 UTC
    You are probably better served by using PostgreSQL instead of MySQL. MySQL is not a very good database for a multiuser aplications (lack of decent locking, referential integrity, etc.). I know MySQL has come a long way since I last looked at a year or two ago (I think they may finally have referential integrity), but I still think it does even come close to PostgreSQL in terms of ACID compliance.

    UPDATE: Apparently MySQL now has some weird form of row level locking for some table types.
[reply]
      Please read How MySQL Compares to PostgreSQL. They put it much better than I could ever hope to!

      Aside from all the excelent reasons listed there I prefer MySQL for one more reason - it's fully implemented. Take a look at PostgreSQL's ALTER TABLE, DROP and VACUUM implementations sometime! I've had more headaches working on PostgreSQL for the past year than I ever got using MySQL.

      -sam

[reply]
        Okay, It had been a year or two since I read up on MySQL so I went and read the page you suggested. And as far as I can see almost nothing has changed. In fact, things are worse than I remeber them (no subselects?). Here is a list of necessary features that MySQL still lacks (from the page you suggested):
        • Foreign keys -- no referential integrity
        • Constraints -- no database level issurance against bad data
        • Triggers -- no cascading deletes, no database level auditing, or any of the other tricks triggers can do
        Nice features that most Relational DBs have that MySQL doesn't
        • Unions
        • Views
        • Cursors
        • Subselects
        • Stored Procedures
        From the prouct page:
        MySQL 4.1, the following development release

        Internally, through a new .frm file format for table definitions, MySQL 4.0 lays the foundation for the new features of MySQL 4.1, such as nested subqueries, stored procedures, and foreign key integrity rules, which form the top of the wish list for many of our customers. Along with those, we will also include simpler additions, such as multi-table UPDATE statements.

        After those additions, critics of MySQL have to be more imaginative than ever in pointing out deficiencies in the MySQL Database Management System. For long already known for its stability, speed, and ease of use, MySQL will then match the requirement checklist of very demanding buyers.
        I agree with the last statment, except to point out that it doesn't take a whole lot of imaginiation to criticize them for lack of standard relational DB features.
[reply]

In Section Meditations