use Perl

• Re: Database challenge: upgrading data (Score:1)

  by runrig (3385)

  Set permissions and/or add database triggers?

  Or maybe I still don't quite get the problem...
  • Re: Database challenge: upgrading data (Score:1)

    by Beatnik (493) on 2008.02.21 2:45 (#61189) Homepage Journal

    Let me elaborate... Suppose you develop some application that uses a database as a backend. You store pretty much everything in your database, including user-modifiable data (the stuff you expect your user to change because that's the purpose of the application) but also the data that's important to the application itself. Let's assume you have some help files stored in the database. There is some chance that the user translated them, did some extra HTML cleaning, etc. For the upgrade, we shouldn't really overwrite the user-data but we would like to overwrite the application data. Adding a checksum seemed like a good idea because that way we can be sure something has changed and we can ask the user for confirmation. Also consider that the user has current data already in the database.. using the normal schemas. Adding extra triggers is not really going to help in upgrading now (it might for the next upgrade ofcourse, ignoring the fact that those triggers are often RDBMS specific or even version specific and that we run this app on a multi-RDBMS platform).
    
    Does that make any sense?

    Reply to This

    Parent

    • Re: (Score:1)

      by runrig (3385)

      Oh, I get it now. I've seen one app deal with it by keeping the user-defined data (help messages and prompts and things like that) separate from the default system data. If the user updated anything, it was copied and then flagged as user defined. The app preferred to fetch the user defined data first, then the non-user defined data. That way you could update the default app data without overwriting the user defined data.