Re: Refactoring

"Juan Pardillos" <sicotom_at_eresmas.com> wrote in message news:6278687.0306301503.9fe330c_at_posting.google.com...
> Hi everybody,
>
> can anybody tell me what's the meaning of "refactoring" applied to the
> field of databases? Is it maybe to apply old strategies to solve new
> needs?

Refactoring is just a new buzzword to describe design changes and design evolution. If you look at the refactoring examples at http://www.refactoring.com/catalog/index.html you will see a lot of them have to do with meaningless complexity in the first place. eg. If you use a logical data model that does not use pointers, you won't care whether pointers are unidirectional or bidirectional. Of course, pointer refactoring could still apply when rearranging the physical schema, but physical independence makes it a much less pressing issue.

If we are talking about relations in relational databases, refactoring mostly boils down to extending an existing design or using relational operations to compose or decompose a design. So for instance, taking a 1NF design and further normalizing it to 5NF involves lossless decomposition using the project operation. One can compose the original 1NF design from the 5NF design using join.

Of course, because refactoring mostly refers to changing user-defined data types and method algorithms, even in a relational database one can refactor user-defined data types and their operations, but again many of the examples at the above link relate more to object variables than to object values.

In any case, I prefer a principled approach to design over a recipe book approach. So for instance, one might have a principle that minimizing the locus of action reduces the probability of bugs and eases their detection instead of a recipe like "Reduce Scope of Variable", which is one application of the principle. Received on Tue Jul 01 2003 - 02:47:17 CEST