On Thu, Dec 24, 2015 at 3:10 PM, Richard Damon <Richard at damon-family.org> wrote: > On 12/24/15 10:26 AM, Bernardo Sulzbach wrote: >> >> I think you focused too much on the ordering issue. He or she may > just >> want a more versatile alter table for convenience. However, I > > > don't know if alter table is used at all in production anywhere (why > would > it be? the column names and ordering should not be part of the > data). They > are useful for prototyping because by having a stronger > alter table > command you don't need to drop and create so many times. > In the end, if > you spent enough time in the design phase to prepare > all your schemas, you > should not have to drop (or alter) any of the > tables at all. It is a > feature, a nice one, but too far from > necessary (from my standpoint) to be > worthy of the developers' time. > > > I am in the process of building an application that has the need to be able > to add columns to tables in response to user actions. It is primarily in the > stage where the user is customizing the program to their needs, but such > customizations might happen after the program has been in use for awhile. > The main case is to be able to add a 'Flag' to records to allow the filter > records or save the set of records found in a search. For now, the current > method of create new, drop and rename, isn't unworkable (and mostly hidden > in an abstraction layer), but being able to directly add a field would be > nice. > > -- > Richard Damon > >
Interesting. I suppose that most of this "table editing" should rely on an abstraction layer anyway: think about supporting other RDBMS in the future. However, I recognize that in your case a more capable alter table may simplify things a lot. -- Bernardo Sulzbach
