Application Group update

[Michel de Kraker]

Hi All

I want to add an field to an existing AG. This AG has already a lot of documents. What would be the best way to add the Field.
Update the existing AG or make a copy of the AG definition and update the field in that copy? What about the corresponding Application.? Any thoughts and experience?

Kind regards,

Michel.

[Justin Derrick]

The biggest problem that I can think of is that the old data doesn't get a value for the new field.  I've never spent the time to figure it out, but my question would be -- how does the new field affect searches?  (If I enter a search using the new field, and the old data doesn't have a value for that field, but would match otherwise, what gets returned?)

As for the best way forward, adding a second AG may hurt your query performance (especially in large/heavily used systems) because DB2 needs to execute the query on TWO groups of tables instead of one. 

If I had to make a rule, I'd say that if the Application Group is very large (more than 10 million documents a month) or gets a lot of queries (more than 100,000 a day) then I'd modify the existing Application Group.  If that AG is small, or gets little activity, there's very little impact, and creating a second AG would be fine.

I'd be curious to know if anyone have any other criteria for making the decision...

-JD.

[Michel de Kraker]

Thank you Justin.

What about the application? When i create a new AG should i also create a new APP?

Thx

Michel.

[Justin Derrick]

Yeah, I try to create new Applications every time a report changes -- so I can keep previous versions of the Application, unaltered.  It's like versioning -- I use the AppID field to store version numbers -- a smallint field is efficient, and a three character string field lets me store values like "v1", "v2a", "v99", etc.

-JD.

[jeffs42885]

Yeah, I try to create new Applications every time a report changes -- so I can keep previous versions of the Application, unaltered.  It's like versioning -- I use the AppID field to store version numbers -- a smallint field is efficient, and a three character string field lets me store values like "v1", "v2a", "v99", etc.

-JD.

Had to read this once or twice but i get the jist of it compared to my "version of versioning" which is just making a new AG JeffsReportNew, actually using a field..since all my reports have the report id string(8)