On 09/22/2014 09:40 AM, John McKown wrote:
On Mon, Sep 22, 2014 at 10:31 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
On Fri, Sep 19, 2014 at 7:16 AM, Bill Moran <wmoran@potentialtech.com> wrote:
On Fri, 19 Sep 2014 09:32:09 +0200
Marius Grama <mariusneo@gmail.com> wrote:
Can anybody explain me what happens in the background when the alter
statement is executed? I've tried it out on a small copy of the table (70K)
and the operation completed in 0.2 seconds.
Will the table be completely locked during the execution of the ALTER
statement?
I share Gavin's concern that you're fixing this in the wrong place. I expect
that you'll be better served by configuring the middleware to do the right thing.
I'll pile on here: in almost 20 years of professional database
development I've never had an actual problem that was solved by
introducing or shortening a length constraint to text columns except
in cases where overlong strings violate the data model (like a two
character state code for example). It's a database equivalent of "C
programmer's disease". Input checks from untrusted actors should
happen in the application.
merlin
I do not have your experience level with data bases, but if I may, I
will make an addition. Input checks should also happen in the RDBMS
server. I have learned you cannot trust end users _or_ programmers.
Most are good and conscientious. But there are a few who just aren't.
And those few seem to be very prolific in making _subtle_ errors. Had
one person who was really good at replacing every p with a [ and P
with {
You don't want that string to get all the way to the server and fail, blow out a transaction and carry that joyous news back to the user who now has to start over completely. Further no mear length constraint is going to fix p<=>[. Not say the db cannot have the constraint (no [ allowed?) but a good app checks input on the fly.