I have a table with lots of columns, and I'd like to add two more (date and time) to the front of the existing table.
There is no data in the table right now, but I'm wondering what the best way is get the table in the format I need it.
I could just drop the table and create a new one with the correct configuration, but I'm wondering if there is a better way?
This is currently not possible. You have to drop and recreate the table.
Theoretically you could add the column, drop and re-add all other columns, but that's hardly practical.
It's an ongoing discussion and an open TODO-item of the Postgres project to allow reordering of columns. But a lot of dependencies and related considerations make that hard.
Quoting the Postgres project's ToDo List:
Allow column display reordering by recording a display, storage, and
permanent id for every column?
Contrary to what some believe, the order of columns in a table is not irrelevant, for multiple reasons.
The default order is used for statements like INSERT without column definition lists.
Or SELECT *, which returns columns in the predefined order.
The composite type of the table uses the same order of columns.
The order of columns is relevant for storage optimization (padding and alignment matter). More:
Calculating and saving space in PostgreSQL
People may be confusing this with the order of rows, which in undefined in a table.
In relational databases the order of columns in a table is irrelevant
Create a view that shows you the columns in the order you want
If you still want to, drop the table and recreate it
Related
I was wondering if anyone knows if there is a way to sort the data that already resides in a database. That is, I want to sort what is there but NOT retrieve it in in query.
I am asking because I have a list of things in this database, that I would like to add to in future and would like to order it once I've added them.
So what I mean is, I would like to not have to download all the data; sort it; then put it back onto the database.
Thanks in advance.
If there is only one column in your table then this is fine and you can simply sort the data in that table.
But if there are more than one columns in your table then it would be dependent on the other columns as well(ie, you need to specify which column you are looking to sort.) Also if there is a primary key attached to the table then its not possible as primary key would be in ascending order by default. In that case you can only have it while selecting the data from the table.
(My suggestion is to sort the data while selecting your records from the table as that would be easy and will have less risk)
EDIT:
To make my point straight and clear, the best way to achieve what you are trying to simply use ORDER BY ASC or ORDER BY DESC while you are selecting the data from your table.
If you are creating a new table then you can create index organized table to ensure that the data is stored ordered by index.
I was wondering if anyone knows if there is a way to sort the data that already resides in a database.
Normal relational tables, called as heap-organized tables, store rows in any order i.e. unsorted. You sort the rows if required only when you fetch them, not when you store them. And the only way to guarantee the sorting while retrieving the rows is to use an ORDER BY clause.
If I have a table with columns: a, b, c and later I do a ALTER TABLE command to add a new column "d", is it possible to add it between a and b for example, and not at the end?
I heard that the position of the columns affects performance.
It's not possible to add a column between two existing columns with an ALTER TABLE statement in SQLite. This works as designed.
The new column is always appended to the end of the list of existing
columns.
As far as I know, MySQL is the only SQL (ish) dbms that lets you determine the placement of new columns.
To add a column at a specific position within a table row, use FIRST
or AFTER col_name. The default is to add the column last. You can also
use FIRST and AFTER in CHANGE or MODIFY operations to reorder columns
within a table.
But this isn't a feature I'd use regularly, so "as far as I know" isn't really very far.
With every sql platform I've seen the only way to do this is to drop the table and re-create it.
However, I question if the position of the column affects performance... In what way would it, what operations are you doing that you think it will make a difference?
I will also note that dropping the table and recreating it is often not a heavy lift. Making a backup of a table and restoring that table is easy on all major platforms so scripting a backup - drop - create - restore is an easy task for a competent DBA.
In fact I've done so often when users ask -- but I always find it a little silly. The most often reason given is the tool of choice behaves nicer when the columns are created in a certain order. (This was also #Jarad's reason below) So this is a good lesson for tool makers, make your tool able to reorder columns (and remember it between runs) -- then everyone is happy.
I use the DB.compileStatement:
sql = DB.compileStatement("INSERT INTO tableX VALUES (?,?,?);
sql.bindString(1,"value for column 1");
sql.bindString(2,"value for column 2");
sql.bindString(3,"value for column 3");
sql.executeUpdateDelete();
So there will be a big difference if order of the columns is not correct.
Unfortunately adding columns at a specific position is not possible using ALTER TABLE, at least not in SQLite. (MySQL it is possible). Workaroud is recreating the table.. (and backup and restore data)
I'm converting data from one schema to another. Each table in the source schema has a 'status' column (default NULL). When a record has been converted, I update the status column to 1. Afterwards, I can report on the # of records that are (not) converted.
While the conversion routines are still under development, I'd like to be able to quickly reset all values for status to NULL again.
An UPDATE statement on the tables is too slow (there are too many records). Does anyone know a fast alternative way to accomplish this?
The fastest way to reset a column would be to SET UNUSED the column, then add a column with the same name and datatype.
This will be the fastest way since both operations will not touch the actual table (only dictionary update).
As in Nivas' answer the actual ordering of the columns will be changed (the reset column will be the last column). If your code rely on the ordering of the columns (it should not!) you can create a view that will have the column in the right order (rename table, create view with the same name as old table, revoke grants from base table, add grants to view).
The SET UNUSED method will not reclaim the space used by the column (whereas dropping the column will free space in each block).
If the column is nullable (since default is NULL, I think this is the case), drop and add the column again?
While the conversion routines are still under development, I'd like to be able to quickly reset all values for status to NULL again.
If you are in development why do you need 70 million records? Why not develop against a subset of the data?
Have you tried using flashback table?
For example:
select current_scn from v$database;
-- 5607722
-- do a bunch of work
flashback table TABLE_NAME to scn 5607722;
What this does is ensure that the table you are working on is IDENTICAL each time you run your tests. Of course, you need to ensure you have sufficient UNDO to hold your changes.
hm. maybe add an index to the status column.
or alterately, add a new table with the primary key only in it. then insert to that table when the record is converted, and TRUNC that table to reset...
I like some of the other answers, but I just read in a tuning book that for several reasons it's often quicker to recreate the table than to do massive updates on the table. In this case, it seems ideal, since you would be writing the CREATE TABLE X AS SELECT with hopefully very few columns.
I would like to know if there's a way to add a column to an SQL Server table after it's created and in a specific position??
Thanks.
You can do that in Management-Studio. You can examine the way this is accomplished by generating the SQL-script BEFORE saving the change. Basically it's achieved by:
removing all foreign keys
creating a new table with the added column
copying all data from the old into the new table
dropping the old table
renaming the new table to the old name
recreating all the foreign keys
In addition to all the other responses, remember that you can reorder and rename columns in VIEWs. So, if you find it necessary to store the data in one format but present it in another, you can simply add the column on to the end of the table and create a single table view that reorders and renames the columns you want to show. In almost every circumstance, this view will behave exactly like the original table.
The safest way to do this is.
Create your new table with the correct column order
Copy the data from the old table.
Drop the Old Table.
The only safe way of doing that is creating a new table (with the column where you want it), migrating the data, dropping the original table, and renaming the new table to the original name.
This is what Management Studio does for you when you insert columns.
As others have pointed out you can do this by creating a temp table moving the data and droping the orginal table and then renaming the other table. This is stupid thing to do though. If your table is large, it could be very time-consuming to do this and users will be locked out during the process. This issomething you NEVER want to do to any table in production.
There is absolutely no reason to ever care what order the columns are in a table since you should not be relying on column order anyway (what if someone else did this same stupid thing?). No queries should use select * or ordinal positions to get columns. If you are doing this now, this is broken code and needs to be fixed immediately as the results are not always going to be as expected. For instance if you do insert a column where you want it and someone else is using select * for a report, suddenly the partnumber is showing up in the spot that used to hold the Price.
By doing what you want to do, you may break much more than you fix by putting the column where you personally want it. Column order in tables should always be irrelevant. You should not be doing this every time you want columns to appear in a differnt order.
With Sql Server Management Studio you can open the table in design and drag and drop the column wherever you want
As Kane says, it's not possible in a direct way. You can see how Management Studio does it by adding a column in the design mode and checking out the change script.
If the column is not in the last position, the script basically drops the table and recreates it, with the new column in the desired position.
In databases table columns don't have order.
Write proper select statement and create a view
No.
Basically, SSMS behind the scenes will copy the table, constraints, etc, drop the old table and rename the new.
The reason is simple - columns are not meant to be ordered (nor are rows), so you're always meant to list which columns you want in a result set (select * is a bit of a hack)
Hello I have several databases, such as mytable_2009_11_19_03 where last 2 numbers identify the hour (table for 03:00), now I want to query something from _00 to _23 .
It could be done in such way but it is really clumsy
select * from mytable_2009_11_19_00 where type = 15
UNION
select * from mytable_2009_11_19_01 where type = 15
UNION
...........
select * from mytable_2009_11_19_23 where type = 15
How could I do it easier?
regards
This table structure sounds like it was intended to be part of a data partitioning scheme. This is not bad design. This is a very good thing!
Time based data like this is always being added to in the front and dropped off the back as it expires. Using one huge table would result in large amounts of index fragmentation as the data updates and in very large maintenance times for operations like VACUUM.
If you follow the link I included in the first paragraph and read all about partitioning, you'll be able to use CHECK constraints to make date searches very fast. Any SELECT that includes a WHERE timestamp > x AND timestamp < y will be quick.
Now, if these tables don't include any timestamps then the partitioning with CHECK constraints won't work and you will just have to write scripts to write the clumsy UNION queries for you.
If you know that all the tables generated are always identical in schema, in PostgreSQL you could create a parent table and set the newly created tables to INHERIT from the parent.
CREATE TABLE mytable_2009_11_19 (LIKE mytable_2009_11_19_00);
ALTER TABLE mytable_2009_11_19_00 INHERIT mytable_2009_11_19;
ALTER TABLE mytable_2009_11_19_01 INHERIT mytable_2009_11_19;
.
.
.
ALTER TABLE mytable_2009_11_19_23 INHERIT mytable_2009_11_19;
SELECT * FROM mytable_2009_11_19 where type = 15;
This is similar to using a view, but there are differences (listing the CONs first):
(CON) This method requires you to be able to ALTER the individual tables, which you may not have the rights to do. A VIEW does not require this level of access.
(CON) This method requires the tables to all have the same structure or, at the very least, the parent must have ONLY the common elements between all the children.
(PRO) To add tables to a VIEW, you have to drop and redefine the VIEW (and it's permissions, if necessary). With a parent table, it's easy to add or remove tables by ALTERing each one with INHERIT/NOINHERIT.
(PRO) If your schema contains fields like date and timestamp and the structure rarely changes, you can build a single parent table and use INHERIT/NOINHERIT on a rolling basis to provide a time "window" that you can query against without having to query the entire history.
The easiest solution would likely be to build a view of all of the tables, then you can query them easily. You could easily write a procedure to generate the view. Also, if you use "union all", it will be faster, if the result you want is all of the rows (as opposed to distinct rows) and you can still grab distinct rows by selecting distinct from the view if you need it sometimes.