Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: Re: OT: Ways of managing changes to a database's structure during a project.

by EvdB (Deacon)
on Feb 04, 2004 at 11:27 UTC ( [id://326469]=note: print w/replies, xml ) Need Help??


in reply to Re: OT: Ways of managing changes to a database's structure during a project.
in thread OT: Ways of managing changes to a database's structure during a project.

I hear what you are saying about the testing - it is a very valid point.

As for the getting it right at the design stage I agree, but it is not always possible or even desirable. I happen to have very few changes to make but a change is a change and requires respect - hence the OP.

Changes can occur for lots of reasons, usually they are used to add features. For example say I am ( and I really am ) designing a small simple web shop. After a few months of trading it turns out that discounts would be a good thing for customers spending over a certain amount. To accomodate this the database (and code) needs to be changed. This sort of thing cannot always be spotted at the initial design stage and it would be impossible to take into account all the possible future features that are needed.

In summary: Yes, getting it right at the start is a good thing, but so is making changes based on lessons learnt.

--tidiness is the memory loss of environmental mnemonics

Replies are listed 'Best First'.
Re: Re: Re: OT: Ways of managing changes to a database's structure during a project.
by demerphq (Chancellor) on Feb 07, 2004 at 09:14 UTC

    After a few months of trading it turns out that discounts would be a good thing for customers spending over a certain amount. To accomodate this the database (and code) needs to be changed.

    Actually, I would think that for adding such functionality you would only need to add to a DB, not actually modify the existing structure. (I dont consider table additions to be a modification.) Perhaps your tables weren't sufficiently normalized? ;-) (Code changes would for sure be required.)

    Anyway, snarkyness aside, my approach with stuff like this tends to be to write a perl script that does the DB modification via SQL. I test it on copies of the production DB, and then once happy and the code is approved for production run it on the production DB. I like to use the perl script to run the SQL because I find that its usually the easiest way to ensure newly added fields have the appropriate values assigned to them. For instance, ill use alter table to add a field as nullable, walk the table updating each record so it has the correct value, then alter table again to set it not-nullable, and perhaps add an index on the new columns.

    Anyway, good luck.


    ---
    demerphq

      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi


Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://326469]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (7)
As of 2024-03-19 08:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found