JavaProjects & Management

Refactoring PL/SQL

Andrej discovered utPLsql as I found utPLsql some time ago… he thinks – and I guess I can agree absolutely – that refactoring pl/sql is harder than refactoring java:

1) refactoring java usually doesn't impact production data, but when refactoring sql you have to think about migrating data, which usually means creating a lot of migration scripts. {except you have some wonderful tools I am still looking for}

2) there's no tool support for pl/sql refactoring as in Java…

well… his thread has a nice discussion where even creator Steven Feuerstein put his 2 cents into it, so that's definately worth a read…

another link

Average rating
(0 votes)

Comments

Refactoring PL/SQL

"refactoring java does'nt inpact production...but when refactoring sql you have to think about migrating data.."
i think the statement is completely misleading.
sql: we refactor our sql alot with the sole impact of having better performance. this sql may be embedded in jdbc call's or in pl/sql ... does'nt really matter.
where as when we start refactoring Compoment Managed Beans (J2EE) , we really have to start thinking about migrating data and backwards compatability.
so what you really mean, is that, when you start refactoring your ddl, you may have migration issues: but this is certainly not programming language inherent.
yes we would love to be able to refactor our pl/sql code more easily, we simply would have better code --- no impact on the database there.
refactoring pl/sql is "difficult" simply because the tool support is missing and not because of the potential impact on the database structure.
there java and pl/sql are more or less equal: simply a host language for sql. the pl/sql guys will say: a more efficient host language.... that again is another discussion.

Similar entries