From: 'Hog on
72degrees wrote:
> On 10 Feb, 09:20, darsy <dar...(a)gmail.com> wrote:
>> On Feb 10, 9:14 am, Pete Fisher <Pe...(a)ps-fisher.demon.co.uk> wrote:
>>
>>> Naturally, the column add is going to be impossible to do if you
>>> can't exclusively lock the table, or prepare a new table and swap
>>> it in during a brief system downtime window.
>>
>> I would massively recommend preparing a new table and swapping the
>> datasource - making live modifications to production DBs is a fool's
>> game.
>>
>
> Agreed. I'd even do that if just playing about with a mySQL database
> on one of my web domains.

I will 3rd that, unless you like going paper based for a while

--
Hog


From: Switters on
On Wed, 10 Feb 2010 09:14:54 GMT, Pete Fisher wrote:

> Naturally, the column add is going to be impossible to do if you can't
> exclusively lock the table, or prepare a new table and swap it in during
> a brief system downtime window.

Pfft, it's MySQL, it's bound to be down at some point soon.
From: antonye on
R C Nesbit wrote:
>
> Adding a column might be a sensible solution, but you would have to be
> careful with default/null values, or it could impact on existing
> queries.

Anyone that writes code with "SELECT * FROM ..." and then uses
ordinal values to retrieve column data deserves all they get.

In any other situation, adding a column would not make any difference.

--
Antony


From: darsy on
On Feb 10, 3:13 pm, antonye <anto...(a)ukrm.net> wrote:
> R C Nesbit wrote:
>
> > Adding a column might be a sensible solution, but you would have to be
> > careful with default/null values, or it could impact on existing
> > queries.
>
> Anyone that writes code with "SELECT * FROM ..." and then uses
> ordinal values to retrieve column data

would be be out of a job, as far as I'm concerned. Well, you know, if
I actually had an actual job were I employed actual people I could
"downsize".

--
d.
From: Pip Luscher on
On Wed, 10 Feb 2010 09:14:54 +0000, Pete Fisher
<Peter(a)ps-fisher.demon.co.uk> wrote:

>As others have said, if it is effectively a one to one relationship add
>a new column (after backing up naturally). Obviously, if you then later
>find that other packages with serial numbers that need to be linked to
>the same box, then will wish you had created a new table, so this could
>be the future-proofed approach.

The serial numbers are one-to-one and there should be no need for
future-proofing WRT multiple software serial numbers - the software
serial number is used because this particular product's SW stack is
from a bought-up company and needs the number to be valid and
traceable in the field, but we manufacture using our own serial number
system.

The databases are local to each production line, not a full-on company
wide production system, so a failure woud be a headache rather than a
heart-attack.

So, I've knocked up a script that checks whether the upgrade has been
carried out, then (if not, obviously) makes a copy of the important
table and adds a column offline, then swaps the names around. I will,
as you say, back up first.

Thanks all.

--
-Pip