Fixing CREATE TABLE

  • IMHO, it’s all about the roots of where relational database designs come from: set theory and relational algebra.

    In the case of CREATE TABLE or ALTER TABLE, you are defining the set. The set definition (DDL) is probably so different from the other things we think about doing, that we forget just how strict the rules are for stating “what is the set?”

    Beer's Law: Absolutum obsoletum
    "if it works it's out-of-date"

  • I think the difference is really simple.

    ALTER TABLE: you can specify whether you are adding a column or changing a column. If adding one, it adds it to the end of the table, if changing a column it finds the column and changes it.

    ALTER PROCEDURE: if you are just changing part of a procedure, how do you tell it where the change goes?

    CREATE PROCEDURE myproc

    AS

    SELECT lname, fname, mi

    FROM mytable

    WHERE lname = 'smith'

    GO

    now I want to change the order of that select and get the first name, mi, and last name. How do I tell SQL Server to change JUST the select line? The code isn't written with line numbers, so I can't say something like ALTER PROCEDURE ALTER LINE 1 SELECT fname, mi, lname.

    Since I can't tell SQL Server the specific part I need to change, I have to resubmit the entire thing.

    -SQLBill

  • If you could alter tables the way you suggest, it would appear that you could also change the column order and type.

    Accidently changing the column order and type would cause nightmares.

    If you couldn't change the column order and type, altering tables this way would just be a huge pain in the a$$.

  • One of the other RDBMSs has a CREATE OR ALTER statement. Can't remember which. Oracle? MySQL?

  • paul.knibbs (2/27/2014)


    I would assume it's because of memory issues (human ones, not SQL ones)--for instance, if I have a 60-column table that I want to add a single column to, what are the chances I'm going to retype all those column names and definitions correctly? Not so much of an issue these days with all the automated tools available to help with this, of course, but SQL as a language came into existence 40 years ago and it definitely would have been more of an issue back then!

    Not if you're used VCS, which was around early.

    This has never been a problem for me because we have generally put structure changes to databases in scripts which we retain for configuration control purposes, and which can contain comments.

  • GBimberg (2/27/2014)


    If you could alter tables the way you suggest, it would appear that you could also change the column order and type.

    Accidently changing the column order and type would cause nightmares.

    If you couldn't change the column order and type, altering tables this way would just be a huge pain in the a$$.

    I'm not sure this is a good reason. A warning could be used here, and a good IDE would detect this. You might want this, but most likely not. However, are we not saying that programmers should be protected from making mistakes? I would argue that part of what we want to do is get programmers to be careful and confident of what they submit.

    In terms of ordering, does it matter? The physical implementation shouldn't matter. The order of columns in the CREATE TABLE should only be a semantic display issue for results, not impacting the physical storage. Surely we could handle meta data changes in system tables if someone reordered columns.

  • I have used alter table / alter column many times and not thought about it. When I was consulting as a DBA for a state child services agency using DB2 on mainframe, I learned a valuable lesson why you have to think carefully about this when working large data sets.

    Extending a column in the middle of a database can force a reordering of all of the extents in the database. In this case, the data size involved would be on the order of hundreds of millions of rows and terabytes of data. (For the record, the DBA team told the developer who wanted to make this change so that he could store additional notes to go and figure out a better way to do it.)

    Adding an extra column at the end of the table, on the other hand, does not require any re-ordering of data. Many times, I think that individuals are taught the latter method without explaining why. If you're creating the table and fixing it right away, go for the alter. If you have 10M rows, you might think about it differently.

  • That's a great illustration of one of the reasons SELECT * FROM is such a bad practice!!!

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

Viewing 8 posts - 16 through 22 (of 22 total)

You must be logged in to reply to this topic. Login to reply