Re^4: Perl to protect database field name info

[dragonchild]

In your case where you have a firstname field that is going to be stored completely within the firstname column, the abstraction doesn't make any sense. And, if you never get any more complicated than that, then the abstraction layer I'm talking about is counter-productive. Seeing as about 50% of all programmers never work on applications that need this kind of abstraction, 50% of all programmers would be ill-served in using it.

Let's say, however, that you're in the other 50% - the one that does need the abstraction. But, you don't understand why. The reason why is very simple - because your requirements will change. When requirements change, you will receive requirements that are from the user's perspective and within the user's domain of understanding. If you have designed your application correctly, you will be able to change the user-visible form WITHOUT touching the underlying database tables. This is not possible if your database table is used to generate your form.

For example, let's say that your company is so successful that you expand into Indonesia. Your application was a big part of that success, so you're leading the charge. And you run into someone without a first-name (many Indonesians only have one name instead of the two that we have in the US or Europe). Now, because your database table generates your form, you cannot abstract away the lack of a firstname within your code - your users have to do it for you.

Rule #1: Users will always make mistakes. Your application should make it hard for them to make common mistakes. It should never require the user to account for your mistakes.

Let's say that you've managed to account for the issues in Indonesia. Now, you're moving along and your application is being sold to the Australian aborigines. You recently had space issues, so you contracted all those VARCHAR(255)'s down to MAX(colname) + 10. In the case of firstname, that was 43, rounded up to 50. Whoops! Aborigines can have extremely long firstnames. Now, while this would require a database change anyways to account for them, instead of having constraints in the application as well as the database, the users see the database error.

Rule #2: Users should always be presented with useful errors that they understand. You should never present a user with an error from anywhere other than the immediate layer that they are interacting with. An error from the database is good only if the user is knowingly interacting with the database. Otherwise, you should be providing the error they see.

Rule #3: Processing should stop as soon as possible. Errors should be detected as soon as possible and handled as close to the source as possible. So, if there is a length problem with a field, that length should be encoded in the user interface. If the UI is a web browser, the length should be checked in Javascript, Perl, and the database.

Let's talk about #3 some more. Once you have separated out what's acceptable for the UI from what's acceptable for the database, you have some really neat possibilities. For example, you can have different restrictions based on different requirements, all going to the same database. So, if firstnames can only be 30 characters in Finland, but they have to be 45 characters in Denmark, you can easily handle that. Alternately, your database can now be used for an application you write and a completely separate application that your friend writes. Both of these situations are very common in large businesses. (I have maintained more of these than I can count.)

Does this help or would you like more discussion on the topic? It might help if you looked up MVC on the wikipedia.

[punch_card_don]

OK, we're getting to the nub of the matter. Sometimes, some fields are best abstracted, either so that the user interface can be optimized for users, or in case the use of the site changes.

That sounds very reasonable.

Thanks for the discussion.

[dragonchild]

Close. The nub is that software is the only thing humans make that is going to change repeatedly and radically over its expected lifecycle. The only way to properly design software is to build into the very core a capability to change safely.

Every change will always bring a risk that a bug has been introduced. (I once fixed a bug in an application and another bug appeared. After I traced down the second bug, it turned out that the first bug had been compensating for it and my correct fix for it broke the application.) So, the proper discussion to have about bug-minimization is minimizing the chance of introducing bugs when making the inevitable changes.

When we discuss this in terms of structuring subroutines, we end up discussing the promotion of internal cohesion and avoidance of external coupling. Internal cohesion is summed up as "A subroutine should do one thing, one thing only, and that one thing well." External coupling is summed up as "A subroutine should only depend on the parameters it was passed in and the values that it and it alone controls." If you think about it in terms of your subroutines, those two things make perfect sense for improving maintainability.

Now, take the external coupling concept and extend it to the components of your application. We have, at a minimum, the user interface (UI), data storage (DS), and the stuff in the middle (APP). Your proposal would couple the UI to the DS. That's about as large an external coupling as you can get. It's not something you would do with your subroutines. Why would you do it with the basic chunks of your application? That is only guaranteeing that you will run into maintainability issues, as ptum has already discovered.