Tuesday, April 10, 2007

Hooray...

I really liked this tongue in cheek article.

And I have a feeling it will generate some level of debate...  I mostly agree with it (sort of like a diatribe about generic coding in general would get a thumbs up from me).

POST A COMMENT

14 Comments:

Anonymous Anonymous said....

This comment resonated with me.
"I have worked on programs where everything that would be a string literal or number in a formula is turned into a constant. "
I can see code here with....
"cv_num_0 CONSTANT NUMBER(1) := 0;"
Presumably in case the number 0 ever changes....

Wed Apr 11, 01:49:00 AM EDT  

Anonymous Matt said....

Its all about getting the balance right, there are people on either side (and extremes!).

I currently work for a software house , where the db design would probably a bit on the 'generic' side for Toms liking. Sure we probably sacrifice on the performance a little (no complaints yet!), but it means we don't have to maintain site by site code, and the costs associated with it.

Wed Apr 11, 05:51:00 AM EDT  

Blogger Jayasankar said....

Tom,
Dying to know what you think of SOA. Have a feeling I already know the answer. :-)

Wed Apr 11, 06:29:00 AM EDT  

Anonymous Anonymous said....

Was the give-away comment the one that said the article was published on April 10?

Or April 01 in big endian format ??

Wed Apr 11, 07:29:00 AM EDT  

Anonymous Anonymous said....

This is a copy from my current project:
public static final int ONE=1;
public static final int TWO=2;
public static final int THREE=3;
public static final int FOUR=4;
public static final int FIVE=5;
...
public static final int TWENTY=20;
Why they stopped on 20? - I don't know.
We also have:
SELECT="SELECT";
COMMA=",";
FROM="FROM";
ORDER_BY="ORDER BY";
and of course:
SPACE=" ";
And the result is - slow, a lot of errors, very expensive (though made mostly offshore).

le

Wed Apr 11, 09:13:00 AM EDT  

Blogger Kevin said....

...
if (stateCode == "AZ" || stateCode == "TX") {
//SR008-04X/I are always required in these states
attachDocument("SR008-04X");
attachDocument("SR008-04XI");
}
...


If I read the article's example correctly, a business rule can be stated as a predicate: "The state [StateCode] requires form [FormName]", and the recommendation is to manage the relationship between [StateCode] and [FormName] in the source code? Why not use some sort of relational database for data and business rule management?

Or is the following "generic", "soft-coding", and "to be avoided":
...
FOR RQ_FORM IN (
SELECT FORM_NAME
FROM REQ_FORMS_BY_STATE
WHERE StateCode = stateCode
UNION
SELECT FORM_NAME
FROM REQ_FORMS_BY_AMOUNT
WHERE ledgerAmnt > FORM_LIMIT
UNION
SELECT FORM_NAME
FROM REQ_COINSURE_FORMS
WHERE coInsuredCount > COINSURED_LIMIT AND orgStatusCode NOT IN (SELECT ORG_STATUS_CODE
FROM EXCLUDED_COINSURE_STATUS) ) LOOP
attachDocument(RQ_FORM.FORM_NAME);
END LOOP;

I mean, the author really wants to modify source code when form "AUTHCNS-1A" is combined with "AUTHCNS-1B" into "AUTHCNS-1C"? When "TN" customers also need the "SR008-04X", or when the "SR008-04XI" is discontinued? When inflation occurs, and the ledger limit of 500000 needs to be bumped to 525000 (and 550000 6 months later)?

Wed Apr 11, 10:36:00 AM EDT  

Blogger Alberto Dell'Era said....

Closest thing to Soft Coding in relational "design" is unnecessary lookup tables - instead of a nice column "status" with NEW, PROCESSING and SHIPPED, a meaningless status_id that maps to status_lookup_table. It may have some useful purpose sometimes, but usually it just makes for yet-another-join or a lot of magic numbers (where status_id=0), so back to Hard Coding again ...

--

I'm also very "fond" of this pearls in JDBC programs

...prepareStatement (CUST_QUERY)

where CUST_QUERY is a constant in an AppConstants class, that you won't find unless you are using a GUI editor (doesn't it tell you something if you need a tool to make sense of a program flow, instead of plain reading the program?) or worse it's in a property file, that of course is accessed by 12 layers of nested classes, and you won't find it unless you execute the program with a debugger (doesnt' you tell something if ...).

To me, this is just another incarnation of the ROT problem - we were told in CS classes that "Hard Coding is bad" and so we apply the ROT blindly, forgetting about common sense.

Wed Apr 11, 05:22:00 PM EDT  

Blogger Jared said....

In Regards to: "Closest thing to Soft Coding in relational "design" is unnecessary lookup tables - instead of a nice column "status" with NEW, PROCESSING and SHIPPED, a meaningless status_id that maps to status_lookup_table."

That isn't really a reason not to use a lookup table. Your status column can still have NEW, PROCESSING or SHIPPED, but now these values are in a column that is a foreign key to the lookup table.

No extra joins, no re-coding when the customer adds 'RETURNED' or 'LOST IN SHIPMENT' as status values.

Wed Apr 11, 07:19:00 PM EDT  

Anonymous Anonymous said....

(on having al lookup table for status values)

Yes, you can insert status directly into table.
But..
what if you need to ensure that status belongs to list of valid values? Do you really want to have a check constraint with eleventy-one hardcoded values instead of a foreign key?
what if there is a state model describing valid status changes? should I really have to code a trigger checking every possible valid combination of :old and :new values and throwing an exception if there is no match?
No, I am still convinced that having a lookup table is the right way to go.

Wed Apr 11, 11:55:00 PM EDT  

Blogger Alberto Dell'Era said....

What about

check (status in ('NEW','PROCESSING','SHIPPED') )

I haven't said "lookup tables are evil" by the way - only that it is evil to use them everywhere without thinking at pros and cons (common sense rules).

Thu Apr 12, 04:50:00 AM EDT  

Blogger Q u a d r o said....

The status can also be a natural key - that way you can do a foreign key checks without the need to lookup/join anything.

Thu Apr 12, 09:10:00 AM EDT  

Anonymous Mark Brady said....

Is there a compromise? Couldn't your lookup table have one column with the entries:

'NEW','PROCESSING','SHIPPED'

Your list enforcement is no longer a check constraint but a FK and adding new entries is DML not DDL and the other camp also gets the convenience of avoiding the join?

Thu Apr 12, 10:20:00 AM EDT  

Blogger Alberto Dell'Era said....

Why not - as far as it simplifies the life for everyone and the schema complexity, everything is welcomed.

I'm simply against canned rules such as "you should always have a number something_id and a lookup_table for everything".

Thu Apr 12, 11:49:00 AM EDT  

Anonymous doug c said....

I also would be sort of curious what you thought of SOA - to second a previous comment.

Fri Apr 13, 02:18:00 AM EDT  

POST A COMMENT

<< Home