Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] XP, database design and cost of change

Expand Messages
  • David Corbin
    No worries.. I don t see any reason to believe that DB changes are inherently more expenseive than any other changes. I have yet to be on a project where
    Message 1 of 24 , Jan 28, 2002
    • 0 Attachment
      No worries.. I don't see any reason to believe that DB changes are
      inherently more expenseive than any other changes. I have yet to be on
      a project where the database didn't undergo changes with each release,
      and such changes were not the death of the project.

      Fear is the mindkiller. Don't be afraid of the situation. Embrace Change.

      You have claimed that it is "ruinously expensive". Can you support this
      claim?


      Miriam Busch wrote:

      >Can you do XP (esp. the planning game, refactoring all the time) for database
      >applications (using relational DBMS)?
      >
      >I'm afraid that you need the traditional analysis and design part at least
      >for database design: Changes to the database scheme are expensive -- the
      >flattened change cost curve is just not true for relational databases.
      >
      >You may find a way to cope with it as long as you are not in production:
      >Automatically recreate your database with every build and regenerate your
      >test data. But at least when your in production, you want to avoid change
      >concerning your database design because it is ruinously expensive. (You need
      >to migrate your data, you may introduce inconsistencies you cannot solve
      >automatically...)
      >
      >So I'm looking for opinions and even more experiences: Can you do XP when
      >using relational databases? Is there a XP way of designing databasis?
      >
      >Thanks,
      > Miriam Busch
      >
      >
      >
      >To Post a message, send it to: extremeprogramming@...
      >
      >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >
      >ad-free courtesy of objectmentor.com
      >
      >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
      >
    • miriambusch
      ... I know... That s why I m asking. ... Ruinously was maybe an exaggeration. What I meant: Changing the database scheme is far more expensive that changing
      Message 2 of 24 , Jan 28, 2002
      • 0 Attachment
        --- In extremeprogramming@y..., David Corbin <dcorbin@m...> wrote:
        > No worries.. I don't see any reason to believe that DB changes
        > are inherently more expenseive than any other changes. I have
        > yet to be on a project where the database didn't undergo changes
        > with each release, and such changes were not the death of the
        > project.

        > Fear is the mindkiller. Don't be afraid of the situation.
        > Embrace Change.

        I know... That's why I'm asking.

        > You have claimed that it is "ruinously expensive". Can you
        > support this claim?

        "Ruinously" was maybe an exaggeration. What I meant: Changing the
        database scheme is far more expensive that changing code. It is so
        expensive that you will avoid change instead of embracing it.

        When changing the database scheme, you need additional migration
        code for your real world data. It may happen that you actually need
        information for old data you cannot obtain automatically. So you
        have to allow NULL-values when you actually don't mean to. With
        several changes to db design, you will have a lot of different
        constraints concerning your "legacy data" and that is not what
        "simple design" is about...

        One small example: While coding you find that an attribute or method
        name was not chosen properly. You will replace it with a proper
        name, you will rebuild the project, all your tests run andeverything
        will be fine.
        Scenario 2: You find that an attribute name in a database table is
        against intuition. Will you change it?

        I would not. The value of changing it is the same as in the first
        scenario, but the price is higher.

        Hope you disagree with my reasoning and convince me...
        Miriam
      • David Corbin
        ... I don t agree. It may require *some* more work, but not much. Not with the right tools. ... The only solution I can see here, is to allow NULL to start
        Message 3 of 24 , Jan 28, 2002
        • 0 Attachment
          miriambusch wrote:

          >--- In extremeprogramming@y..., David Corbin <dcorbin@m...> wrote:
          >
          >>No worries.. I don't see any reason to believe that DB changes
          >>are inherently more expenseive than any other changes. I have
          >>yet to be on a project where the database didn't undergo changes
          >>with each release, and such changes were not the death of the
          >>project.
          >>
          >
          >>Fear is the mindkiller. Don't be afraid of the situation.
          >>Embrace Change.
          >>
          >
          >I know... That's why I'm asking.
          >
          >>You have claimed that it is "ruinously expensive". Can you
          >>support this claim?
          >>
          >
          >"Ruinously" was maybe an exaggeration. What I meant: Changing the
          >database scheme is far more expensive that changing code. It is so
          >expensive that you will avoid change instead of embracing it.
          >
          I don't agree. It may require *some* more work, but not much. Not
          with the right tools.

          >
          >When changing the database scheme, you need additional migration
          >code for your real world data. It may happen that you actually need
          >information for old data you cannot obtain automatically.
          >
          The only solution I can see here, is to allow NULL to start with, and
          add the constraint later. But it's very rare in my oppinion that you
          add one REQUIRED column that you can't generate it automatically.

          There's another point here. You always have the option to NOT use
          constraints at all.

          >So you
          >have to allow NULL-values when you actually don't mean to. With
          >several changes to db design, you will have a lot of different
          >constraints concerning your "legacy data" and that is not what
          >"simple design" is about...
          >
          >One small example: While coding you find that an attribute or method
          >name was not chosen properly. You will replace it with a proper
          >name, you will rebuild the project, all your tests run andeverything
          >will be fine.
          >Scenario 2: You find that an attribute name in a database table is
          >against intuition. Will you change it?
          >
          Yes. And I have. If I've got adequate tests.

          >
          >I would not. The value of changing it is the same as in the first
          >scenario, but the price is higher.
          >
          The price is about an 5 minutes of work by hand, for me, or 2-3 hours of
          coding, and 30 seconds of my time, if I ever get around to adding that
          feature for my tool. Every release, I extract the data from the schema
          into an XML file. I then make any tweaks I need to in vi (remove a
          column, rename a column, remove a table, etc.) and then I run another
          script with populates the database again.

          >
          >Hope you disagree with my reasoning and convince me...
          >
          If it is as expensive as you say, you must not have very good tools for
          doing this type of thing. what do you use to do this type of stuff?

          >
          >Miriam
          >
          >
          >
          >
          >To Post a message, send it to: extremeprogramming@...
          >
          >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
          >
          >ad-free courtesy of objectmentor.com
          >
          >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >
          >
          >
        • Dossy
          ... Is this a law of working with databases? I don t think so. ... Have you done any study of database versioning? Unfortunately, I don t know (offhand) of
          Message 4 of 24 , Jan 28, 2002
          • 0 Attachment
            On 2002.01.28, miriambusch <miriambusch@...> wrote:
            > "Ruinously" was maybe an exaggeration. What I meant: Changing the
            > database scheme is far more expensive that changing code. It is so
            > expensive that you will avoid change instead of embracing it.

            Is this a "law" of working with databases? I don't think so.

            > When changing the database scheme, you need additional migration
            > code for your real world data. It may happen that you actually need
            > information for old data you cannot obtain automatically. So you
            > have to allow NULL-values when you actually don't mean to. With
            > several changes to db design, you will have a lot of different
            > constraints concerning your "legacy data" and that is not what
            > "simple design" is about...

            Have you done any study of database versioning? Unfortunately, I
            don't know (offhand) of any good books to recommend ...

            Here's a 5 minute description (which does the technique absolutely
            no justice -- use this as a primer to get an understanding of the
            technique ... do not go blindly and implement it without some
            real thorough thought, please):

            Make sure every table has a column which represents the version
            number of the row. Create meta-tables which map version numbers
            to "rules" so you can intelligently handle rows of different
            versions in a generic fashion.

            When you change the schema, change your DML functionality to
            set the version column to the right version (easy as incrementing
            the previous version number) and add rows to your meta-tables
            describing the new version of the schema.

            When you fetch data from the schema (through stored procs, of
            course), depending on what version number you get, return the
            data appropriately (using the meta-tables to assist the stored
            proc. in knowing how the data should be returned for that
            particular version).

            Some schema changes require a forced migration which may
            obsolete certain old versions (not necessarily all). In those
            cases, you'll have to create some kind of migration tool that
            pulls out the rows with the appropriate versions that have
            become obsoleted and update them appropriately. Having the
            rows versioned will help you identify the minimal set of
            data that needs to be migrated, though.

            -- Dossy

            --
            Dossy Shiobara mail: dossy@...
            Panoptic Computer Network web: http://www.panoptic.com/
            "He realized the fastest way to change is to laugh at your own
            folly -- then you can let go and quickly move on." (p. 70)
          • Charlie Poole
            ... I think, the database field gets people mixed up between develupment and administration. As an analogy, think of a company that develops an embedded
            Message 5 of 24 , Jan 28, 2002
            • 0 Attachment
              > On 2002.01.28, miriambusch <miriambusch@...> wrote:
              > > "Ruinously" was maybe an exaggeration. What I meant: Changing the
              > > database scheme is far more expensive that changing code. It is so
              > > expensive that you will avoid change instead of embracing it.
              >
              > Is this a "law" of working with databases? I don't think so.

              I think, the database field gets people mixed up between develupment and
              administration.

              As an analogy, think of a company that develops an embedded product. They can
              use an agile approach to development, embracing change readily in the software
              side of things and to a slightly lesser degree in the hardware side.

              Eventually, the product is ready and they go to manufacturing and shipping the
              product. That process is highly deterministic. It can be so because, by the time
              the product is ready, what remains to be done has been done many times before
              and needs to be reliably repeatable.

              With databases, I think there is a development phase and a manufacturing phase
              too. The manufacturing phase falls under the heading of database administration.
              By fully decoupling most of the app from the persistence layer and decoupling
              the persistence layer from the underlying data tables, you can make this
              manufacturing phase easier, but you generally still need it.

              Charlie Poole
              cpoole@...
            • Morris, Chris
              I have a semi-related question to this thread. First, some fixture: I m early in development of a new database system, and so far have been dropping and
              Message 6 of 24 , Jan 30, 2002
              • 0 Attachment
                I have a semi-related question to this thread.

                First, some fixture:

                I'm early in development of a new database system, and so far have been
                dropping and re-adding all tables whenever I have a schema change. I'm not
                going to be able to do this in production, so I want to change my
                development habits to do schema changes as if the data were production data,
                because it will be one day.

                For example, right now I need to do an alter table statement, no big deal.
                But I've also got a master script to create all the tables on a new database
                (which I'll eventually run to setup the production database). Here's my
                question: as I go forward, accumulating alter schema scripts, should I also
                update the master create script, or just lose the master create script and
                when I need a new install simply chain together the original create script
                with all the alter scripts?

                The former option has the advantage of a slim, trim script for a new
                install, but then I'd be maintaining both the new install script and the
                update trail of alter scripts for upgrades -- duplication, plus the burden
                of ensuring that both paths (new script and collection of upgrade scripts)
                result in the same schema.

                The latter option removes duplication, I retain the option to either setup a
                brand new database or upgrade any older database to the latest and greatest
                all with the same stuff. But I'm afraid this chain of updates would become
                unwieldy.

                Thoughts?

                Chris
              • Dossy
                ... How about this: Lose the master DDL script, and when you need a new install, simply reverse engineer your existing live database and create a new DDL
                Message 7 of 24 , Jan 30, 2002
                • 0 Attachment
                  On 2002.01.30, Morris, Chris <ChrisM@...> wrote:
                  > just lose the master create script and when I need a new install
                  > simply chain together the original create script with all the alter
                  > scripts?

                  How about this:

                  Lose the master DDL script, and when you need a new install,
                  simply reverse engineer your existing live database and create
                  a new DDL script based on that.

                  It's a fairly trivial exercise, and can be made easier with a
                  handful of scripts, or even easier with a nice tool like
                  ERwin that has a "reverse engineer" feature.

                  -- Dossy

                  --
                  Dossy Shiobara mail: dossy@...
                  Panoptic Computer Network web: http://www.panoptic.com/
                  "He realized the fastest way to change is to laugh at your own
                  folly -- then you can let go and quickly move on." (p. 70)
                • Charlie Poole
                  ... Something I ve done in periods of rapid change is to generate a reverse-engineered script every day and put it under source control. It then becomes very
                  Message 8 of 24 , Jan 30, 2002
                  • 0 Attachment
                    Dossy wrote:
                    >
                    > On 2002.01.30, Morris, Chris <ChrisM@...> wrote:
                    > > just lose the master create script and when I need a new install
                    > > simply chain together the original create script with all the alter
                    > > scripts?
                    >
                    > How about this:
                    >
                    > Lose the master DDL script, and when you need a new install,
                    > simply reverse engineer your existing live database and create
                    > a new DDL script based on that.
                    >
                    > It's a fairly trivial exercise, and can be made easier with a
                    > handful of scripts, or even easier with a nice tool like
                    > ERwin that has a "reverse engineer" feature.
                    >

                    Something I've done in periods of rapid change is to generate a
                    reverse-engineered script every day and put it under source control. It then
                    becomes very easy to see all the diffs that have occured over any arbitrary
                    period.

                    Charlie Poole
                    cpoole@...
                  • Dossy
                    ... Especially useful technique when there isn t a single person filling the database architect role (particularly common in really extreme XP teams, I d
                    Message 9 of 24 , Jan 30, 2002
                    • 0 Attachment
                      On 2002.01.30, Charlie Poole <cpoole@...> wrote:
                      >
                      > Something I've done in periods of rapid change is to generate a
                      > reverse-engineered script every day and put it under source control. It then
                      > becomes very easy to see all the diffs that have occured over any arbitrary
                      > period.

                      Especially useful technique when there isn't a single person filling
                      the "database architect" role (particularly common in really extreme
                      XP teams, I'd imagine).

                      It's easier to evolve a good design, including database design,
                      incrementally over time than to try and plan for _every_ possible
                      thing up front (because our knowledge is limited to a priori
                      knowledge, up front). Reverse-engineering the schema to facilitate
                      change management is a good way of coping with this kind of change,
                      though.

                      Thanks for mentioning the technique, Charlie -- I hope folks
                      give it a try and find it as useful as I (and perhaps you) have.

                      -- Dossy

                      --
                      Dossy Shiobara mail: dossy@...
                      Panoptic Computer Network web: http://www.panoptic.com/
                      "He realized the fastest way to change is to laugh at your own
                      folly -- then you can let go and quickly move on." (p. 70)
                    • Charlie Poole
                      ... I discovered it for myself on a non-XP, non-anyProcess team where everyone changed whatever they wanted. It was basically self-protection. It s interesting
                      Message 10 of 24 , Jan 30, 2002
                      • 0 Attachment
                        The real Dossy wrote:
                        > On 2002.01.30, Charlie Poole <cpoole@...> wrote:
                        > >
                        > > Something I've done in periods of rapid change is to generate a
                        > > reverse-engineered script every day and put it under source control. It then
                        > > becomes very easy to see all the diffs that have occured over any arbitrary
                        > > period.
                        >
                        > Especially useful technique when there isn't a single person filling
                        > the "database architect" role (particularly common in really extreme
                        > XP teams, I'd imagine).

                        I discovered it for myself on a non-XP, non-anyProcess team where everyone
                        changed whatever they wanted. It was basically self-protection.
                        It's interesting to realize that the same thing gives benefit in a
                        well-disciplined XP environment.


                        Charlie Poole
                        cpoole@...
                      • Morris, Chris
                        ... Know of any tools that will then take two versions and create a diff script -- a script that could be applied to a database of schema revision 5 to bring
                        Message 11 of 24 , Jan 31, 2002
                        • 0 Attachment
                          > Something I've done in periods of rapid change is to generate a
                          > reverse-engineered script every day and put it under source
                          > control. It then
                          > becomes very easy to see all the diffs that have occured over
                          > any arbitrary
                          > period.

                          Know of any tools that will then take two versions and create a diff script
                          -- a script that could be applied to a database of schema revision 5 to
                          bring it up to schema revision 12?

                          Chris
                        • Dossy
                          ... That sounds a lot like a UserStory ... Do a spike solution. Give an estimate ... -- Dossy -- Dossy Shiobara mail: dossy@panoptic.com
                          Message 12 of 24 , Jan 31, 2002
                          • 0 Attachment
                            On 2002.01.31, Morris, Chris <ChrisM@...> wrote:
                            > > Something I've done in periods of rapid change is to generate a
                            > > reverse-engineered script every day and put it under source control.
                            > > It then becomes very easy to see all the diffs that have occured
                            > > over any arbitrary period.
                            >
                            > Know of any tools that will then take two versions and create a diff
                            > script -- a script that could be applied to a database of schema
                            > revision 5 to bring it up to schema revision 12?

                            That sounds a lot like a UserStory ...

                            Do a spike solution. Give an estimate ...

                            -- Dossy

                            --
                            Dossy Shiobara mail: dossy@...
                            Panoptic Computer Network web: http://www.panoptic.com/
                            "He realized the fastest way to change is to laugh at your own
                            folly -- then you can let go and quickly move on." (p. 70)
                          • Charlie Poole
                            Chris, ... My first thought was that your SCM does it, but now I see what you mean. So, given two sets of scripts that each generate a database, produce a
                            Message 13 of 24 , Jan 31, 2002
                            • 0 Attachment
                              Chris,

                              > > Something I've done in periods of rapid change is to generate a
                              > > reverse-engineered script every day and put it under source
                              > > control. It then
                              > > becomes very easy to see all the diffs that have occured over
                              > > any arbitrary
                              > > period.
                              >
                              > Know of any tools that will then take two versions and create a diff script
                              > -- a script that could be applied to a database of schema revision 5 to
                              > bring it up to schema revision 12?

                              My first thought was that your SCM does it, but now I see what you mean. So,
                              given two sets of scripts that each generate a database, produce a script that
                              will migrate one database to another.

                              Now that you've thought of it, I definitely want one!

                              Creating such a program - if it doesn't exist already - would be non-trivial
                              but it seems fairly doable. Especially so since you might be able to
                              leverage the database software to parse the scripts and create the internal
                              structures that represent the database.

                              Charlie Poole
                              cpoole@...
                            • Pit Capitain
                              ... Charlie, if you only look at the (empty) database schema, such a tool is possible, indeed. However, if you also consider the migration of existing data,
                              Message 14 of 24 , Feb 1, 2002
                              • 0 Attachment
                                On 31 Jan 2002, at 17:57, Charlie Poole wrote:

                                > Chris,
                                >
                                > > Know of any tools that will then take two versions and create a diff
                                > > script -- a script that could be applied to a database of schema
                                > > revision 5 to bring it up to schema revision 12?
                                >
                                > My first thought was that your SCM does it, but now I see what you
                                > mean. So, given two sets of scripts that each generate a database,
                                > produce a script that will migrate one database to another.
                                >
                                > Now that you've thought of it, I definitely want one!
                                >
                                > Creating such a program - if it doesn't exist already - would be
                                > non-trivial but it seems fairly doable. Especially so since you might
                                > be able to leverage the database software to parse the scripts and
                                > create the internal structures that represent the database.

                                Charlie, if you only look at the (empty) database schema, such a
                                tool is possible, indeed. However, if you also consider the migration
                                of existing data, you don't get enough information from the two
                                scripts generating the database versions.

                                For example, suppose you introduce a column in an ORDER table
                                that - for performance reasons - holds the sum of all items
                                belonging to an order. From the DDL scripts you can only detect
                                the new column, but you have no clue which data to put in there.

                                When I once had to maintain a very rapidly evolving database
                                schema (a couple of changes every week), I wrote the diff scripts
                                by hand at a slightly higher level than pure SQL and used a code
                                generator to compile these scripts to SQL.

                                In the example above, I'd write something like "add a new non-null
                                column of type xxx to table ORDER and populate it using the
                                following SQL commands ...". The code generator then generated
                                the code to add a (null) column to the table, execute the populating
                                SQL commands, and then change the column to have the non-null
                                constraint.

                                I added new commands to the code generator as I needed them,
                                which wasn't too much work. I also introduced a table holding the
                                actual schema version and a web frontend to a couple of scripts,
                                so that each developer and each tester could automatically update
                                her private database schema to newer versions. The generated diff
                                scripts were also used to migrate the production database after
                                approval of the test team.

                                With this infrastructure in place, the amount of work to maintain the
                                database schema was drastically reduced.

                                Regards,
                                Pit
                              • Charlie Poole
                                ... You re right, I haven t thought about data migration - nice solution. I still wouldn t mind seeing the basic tool for schemas though.
                                Message 15 of 24 , Feb 1, 2002
                                • 0 Attachment
                                  Pit wrote:
                                  > On 31 Jan 2002, at 17:57, Charlie Poole wrote:
                                  >
                                  > > Chris,
                                  > >
                                  > > > Know of any tools that will then take two versions and create a diff
                                  > > > script -- a script that could be applied to a database of schema
                                  > > > revision 5 to bring it up to schema revision 12?
                                  > >
                                  > > My first thought was that your SCM does it, but now I see what you
                                  > > mean. So, given two sets of scripts that each generate a database,
                                  > > produce a script that will migrate one database to another.
                                  > >
                                  > > Now that you've thought of it, I definitely want one!
                                  > >
                                  > > Creating such a program - if it doesn't exist already - would be
                                  > > non-trivial but it seems fairly doable. Especially so since you might
                                  > > be able to leverage the database software to parse the scripts and
                                  > > create the internal structures that represent the database.
                                  >
                                  > Charlie, if you only look at the (empty) database schema, such a
                                  > tool is possible, indeed. However, if you also consider the migration
                                  > of existing data, you don't get enough information from the two
                                  > scripts generating the database versions.

                                  <snip>

                                  You're right, I haven't thought about data migration - nice solution.

                                  I still wouldn't mind seeing the basic tool for schemas though.
                                • Blum, Robert
                                  ... Unless I m totally off my rocker, it looks like this: http://www.quest.com/schema_manager/ does what you want? Robert
                                  Message 16 of 24 , Feb 1, 2002
                                  • 0 Attachment
                                    > From: Charlie Poole [mailto:cpoole@...]
                                    > You're right, I haven't thought about data migration - nice solution.
                                    >
                                    > I still wouldn't mind seeing the basic tool for schemas though.

                                    Unless I'm totally off my rocker, it looks like this:
                                    http://www.quest.com/schema_manager/ does what you want?

                                    Robert
                                  • Charlie Poole
                                    Robert, ... Sounds good - maybe more than I need - but also Oracle-specific. Charlie Poole cpoole@pooleconsulting.com
                                    Message 17 of 24 , Feb 1, 2002
                                    • 0 Attachment
                                      Robert,

                                      > > From: Charlie Poole [mailto:cpoole@...]
                                      > > You're right, I haven't thought about data migration - nice solution.
                                      > >
                                      > > I still wouldn't mind seeing the basic tool for schemas though.
                                      >
                                      > Unless I'm totally off my rocker, it looks like this:
                                      > http://www.quest.com/schema_manager/ does what you want?
                                      >

                                      Sounds good - maybe more than I need - but also Oracle-specific.

                                      Charlie Poole
                                      cpoole@...
                                    • Blum, Robert
                                      ... You _REALLY_ insist on making it difficult, do ya? :) OK, let us assume we really need something like that - what would be your stories? (I m itching to do
                                      Message 18 of 24 , Feb 4, 2002
                                      • 0 Attachment
                                        > From: Charlie Poole [mailto:cpoole@...]
                                        > Sounds good - maybe more than I need - but also Oracle-specific.

                                        You _REALLY_ insist on making it difficult, do ya? :)

                                        OK, let us assume we really need something like that - what would be your
                                        stories? (I'm itching to do some XP - if only XpForOne [or is that xp41?])

                                        Bye,
                                        Robert
                                      • Charlie Poole
                                        I was thinking about doing the same thing but I m too tied up right now. Here are a few thoughts. All of them assume input of two scripts that generate a
                                        Message 19 of 24 , Feb 4, 2002
                                        • 0 Attachment
                                          I was thinking about doing the same thing but I'm too tied up right now.

                                          Here are a few thoughts. All of them assume input of two scripts that
                                          generate a database, with one of them being the earlier form and the
                                          other a newer revised form. Output is to be a script which will
                                          update the earlier form to the later form.

                                          1. Recognize that no changes have been made and indicate by a message.
                                          2. Recognize that a table has been added (and generate the script)
                                          3. Recognize that a table has been deleted
                                          4. Recognize that a table definition has been altered

                                          Of course it gets much more complicated eventually, as multiple changes occur,
                                          dependencies are taken into account, etc.

                                          Charlie Poole
                                          cpoole@...


                                          > -----Original Message-----
                                          > From: Blum, Robert [mailto:rblum@...]
                                          > Sent: Monday, February 04, 2002 11:00 AM
                                          > To: 'extremeprogramming@yahoogroups.com'
                                          > Subject: RE: [XP] XP, database design and cost of change
                                          >
                                          >
                                          > > From: Charlie Poole [mailto:cpoole@...]
                                          > > Sounds good - maybe more than I need - but also Oracle-specific.
                                          >
                                          > You _REALLY_ insist on making it difficult, do ya? :)
                                          >
                                          > OK, let us assume we really need something like that - what would be your
                                          > stories? (I'm itching to do some XP - if only XpForOne [or is that xp41?])
                                          >
                                          > Bye,
                                          > Robert
                                          >
                                          > To Post a message, send it to: extremeprogramming@...
                                          >
                                          > To Unsubscribe, send a blank message to:
                                          > extremeprogramming-unsubscribe@...
                                          >
                                          > ad-free courtesy of objectmentor.com
                                          >
                                          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                          >
                                          >
                                          >
                                        • Blum, Robert
                                          ... Can we stipulate that the input scripts do not necessarily generate a database, but only contain a DB description? (Just for now) It s quite easy to
                                          Message 20 of 24 , Feb 4, 2002
                                          • 0 Attachment
                                            > From: Charlie Poole [mailto:cpoole@...]

                                            > I was thinking about doing the same thing but I'm too tied up
                                            > right now.
                                            >
                                            > Here are a few thoughts. All of them assume input of two scripts that
                                            > generate a database, with one of them being the earlier form and the
                                            > other a newer revised form. Output is to be a script which will
                                            > update the earlier form to the later form.

                                            Can we stipulate that the input scripts do not necessarily generate a
                                            database, but only contain a DB description? (Just for now)

                                            It's quite easy to actually dump a DB schema in XML notation, and that would
                                            make it much easier for me to create a working prototype - hence more value
                                            earlier on :)

                                            > 1. Recognize that no changes have been made and indicate by a message.
                                            > 2. Recognize that a table has been added (and generate the script)
                                            > 3. Recognize that a table has been deleted
                                            > 4. Recognize that a table definition has been altered

                                            I assume 3 and 4 generate a script, too?

                                            Bye,
                                            Robert
                                          • Charlie Poole
                                            Good point.
                                            Message 21 of 24 , Feb 4, 2002
                                            • 0 Attachment
                                              Good point.

                                              > -----Original Message-----
                                              > From: Blum, Robert [mailto:rblum@...]
                                              > Sent: Monday, February 04, 2002 12:25 PM
                                              > To: 'extremeprogramming@yahoogroups.com'
                                              > Subject: RE: [XP] XP, database design and cost of change
                                              >
                                              >
                                              > > From: Charlie Poole [mailto:cpoole@...]
                                              >
                                              > > I was thinking about doing the same thing but I'm too tied up
                                              > > right now.
                                              > >
                                              > > Here are a few thoughts. All of them assume input of two scripts that
                                              > > generate a database, with one of them being the earlier form and the
                                              > > other a newer revised form. Output is to be a script which will
                                              > > update the earlier form to the later form.
                                              >
                                              > Can we stipulate that the input scripts do not necessarily generate a
                                              > database, but only contain a DB description? (Just for now)
                                              >
                                              > It's quite easy to actually dump a DB schema in XML notation, and that would
                                              > make it much easier for me to create a working prototype - hence more value
                                              > earlier on :)
                                              >
                                              > > 1. Recognize that no changes have been made and indicate by a message.
                                              > > 2. Recognize that a table has been added (and generate the script)
                                              > > 3. Recognize that a table has been deleted
                                              > > 4. Recognize that a table definition has been altered
                                              >
                                              > I assume 3 and 4 generate a script, too?
                                              >
                                              > Bye,
                                              > Robert
                                              >
                                              > To Post a message, send it to: extremeprogramming@...
                                              >
                                              > To Unsubscribe, send a blank message to:
                                              > extremeprogramming-unsubscribe@...
                                              >
                                              > ad-free courtesy of objectmentor.com
                                              >
                                              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                              >
                                              >
                                              >
                                            • David Corbin
                                              And I can throw some perl code at you if you want, which generates such a script (for oracle) if it is wanted (I ve started done this path, but got
                                              Message 22 of 24 , Feb 4, 2002
                                              • 0 Attachment
                                                And I can throw some perl code at you if you want, which generates such
                                                a script (for oracle) if it is wanted (I've started done this path, but
                                                got distracted...)

                                                Charlie Poole wrote:

                                                >Good point.
                                                >
                                                >>-----Original Message-----
                                                >>From: Blum, Robert [mailto:rblum@...]
                                                >>Sent: Monday, February 04, 2002 12:25 PM
                                                >>To: 'extremeprogramming@yahoogroups.com'
                                                >>Subject: RE: [XP] XP, database design and cost of change
                                                >>
                                                >>
                                                >>>From: Charlie Poole [mailto:cpoole@...]
                                                >>>
                                                >>>I was thinking about doing the same thing but I'm too tied up
                                                >>>right now.
                                                >>>
                                                >>>Here are a few thoughts. All of them assume input of two scripts that
                                                >>>generate a database, with one of them being the earlier form and the
                                                >>>other a newer revised form. Output is to be a script which will
                                                >>>update the earlier form to the later form.
                                                >>>
                                                >>Can we stipulate that the input scripts do not necessarily generate a
                                                >>database, but only contain a DB description? (Just for now)
                                                >>
                                                >>It's quite easy to actually dump a DB schema in XML notation, and that would
                                                >>make it much easier for me to create a working prototype - hence more value
                                                >>earlier on :)
                                                >>
                                                >>>1. Recognize that no changes have been made and indicate by a message.
                                                >>>2. Recognize that a table has been added (and generate the script)
                                                >>>3. Recognize that a table has been deleted
                                                >>>4. Recognize that a table definition has been altered
                                                >>>
                                                >>I assume 3 and 4 generate a script, too?
                                                >>
                                                >>Bye,
                                                >> Robert
                                                >>
                                                >>To Post a message, send it to: extremeprogramming@...
                                                >>
                                                >>To Unsubscribe, send a blank message to:
                                                >>extremeprogramming-unsubscribe@...
                                                >>
                                                >>ad-free courtesy of objectmentor.com
                                                >>
                                                >>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                                >>
                                                >>
                                                >>
                                                >
                                                >To Post a message, send it to: extremeprogramming@...
                                                >
                                                >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                                >
                                                >ad-free courtesy of objectmentor.com
                                                >
                                                >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                                >
                                                >
                                                >
                                              • Blum, Robert
                                                I apologize I ve been silent on this front for a while - things have a tendency to get hectic whenever I volunteer my spare time for anything :) No, seriously
                                                Message 23 of 24 , Feb 6, 2002
                                                • 0 Attachment
                                                  I apologize I've been silent on this front for a while - things have a
                                                  tendency to get hectic whenever I volunteer my spare time for anything :)

                                                  No, seriously - I am setting up the infrastructure (dev machine, dev
                                                  environment, DB) at the moment. I'll report before the end of the week, with
                                                  a list of what I consider customer stories, and their estimates. This way,
                                                  I'll be ready to take on iteration one on a monday.

                                                  David, thanks for your kind offer of some code to get me started. I feel
                                                  inclined to decline, though - I would really like to tackle this one from
                                                  the ground up, test first. Just to see what happens. Plus, I always was
                                                  looking for a complete (tiny) XP project, documented completely on the web.
                                                  Since I never found one, I probably have to provide it myself.


                                                  Bye,
                                                  Robert
                                                • David Corbin
                                                  ... No problem. There are a dozen reasons not to accept. If I had kept working on it to some degree, it would be a nice handy open source tool by now, but I
                                                  Message 24 of 24 , Feb 6, 2002
                                                  • 0 Attachment
                                                    Blum, Robert wrote:

                                                    >David, thanks for your kind offer of some code to get me started. I feel
                                                    >inclined to decline, though - I would really like to tackle this one from
                                                    >the ground up, test first. Just to see what happens. Plus, I always was
                                                    >looking for a complete (tiny) XP project, documented completely on the web.
                                                    >Since I never found one, I probably have to provide it myself.
                                                    >
                                                    No problem. There are a dozen reasons not to accept. If I had kept
                                                    working on it to some degree, it would be a nice handy open source tool
                                                    by now, but I didn't. I just felt I should offer.

                                                    >
                                                    >Bye,
                                                    > Robert
                                                    >
                                                    >To Post a message, send it to: extremeprogramming@...
                                                    >
                                                    >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                                    >
                                                    >ad-free courtesy of objectmentor.com
                                                    >
                                                    >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                                    >
                                                    >
                                                    >
                                                  Your message has been successfully submitted and would be delivered to recipients shortly.