RE: [AM] Unfounded assertion

(responding to Dagna)

> Are both of these refactoring?
>
> 1. Split a field into two others (typically, Name into Forename
> and Surname.)

We're dealing with this in another thread.  Names are horrendously
complicated things, with different conventions in different
cultures, then individuals who deliberately try to flout the
conventions, etc., etc., etc.   In such an environment it may
be reasonable to expect people to put up with the oddities that
come out of the computer system.  If enough people
complain, we could devise a standard name format and
issue them at birth.  No, you're right, it will never happen.

The basic problem is that to split an existing name into
Forename/s and Surname, both parts must be there,
and we must know where one part starts and ends.  At
present, that information is not held in the database.
Thus while splitting the fields may be a standard
refactoring, dealing with the data is not.

> 2. The warehouse has an internal customer number, and looks
> up the original system customer id on a cross reference table.
> But every report we produce uses the original id (and a system
> id). So add the system of origin and the original id to the customer
> table on the warehouse.
>
> I wonder if 1 is a design change, and 2 is a refactoring (to save
> hammering the cross-reference table, which is narrow, very deep
> and used in every update and extract).

1. is new functionality, not merely a design change; and new
data to support that new functionality.  2. I would class as a
refactoring; the functionality is the same, but the performance
is improved over some of that functionality (probably at the cost
of performance elsewhere?).  Don't take that as gospel, that's
an opinion I may be persuaded to change.

> (BTW - jargon alert - if anyone wonders what I mean by 'narrow'
> and 'deep', 'narrow' is the width of a row, 'deep' is the number of
> rows - this type of table can be the Marianas Trench of your
> database.)

Thanks.

> But if the users want the name field split, don't waste time wondering
> what to call it - that time would be better spent explaining to the
> person who designed the database that they messed up and should
> have thought of this one, and then finding out that they did, but the
> contents of Name are in no clear format - surname + initials, forename
> + surname, initials + surname, all in one field in the source system
> (which isn't this one)... 

Whatever you do with names, there's going to be the odd few
that just don't fit your assumptions.  Your data is *always* going
to be slightly dirty.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------