I need to add a new column to at table. I wonder if it is faster to run an alter table query to add the new column and then an update query to insert data in the column. In compare to creating at new table.
I suppose I could just try both to see witch is faster, but maybe someone could explain why?
Point of view speed:
It's more faster create only one column instead of re-creating a table
Point of view data consistence:
A table probabily has a lot of relation with other DB table (it can be a foreign table for others), so if you re-creating a table you must value a script about update other tables reference to your.
I hope, I've answered completely to your question. Have a nice day
Related
Is it good practice to add some placeholder columns when creating a database table with millions of rows, in case the schema gets changed later? More efficient to rename a column than to insert a new one?
There are many problems with adding "placeholder" columns to a table.
These columns may take up useless space, and appear "sloppy".
You may create too many columns now, and have columns that will never be used.
You may not create enough columns now, and will have to end up creating more anyways.
You don't know what the column data types will be at this time.
Always remember that if a column needs added at a later date and will not be used for any of the current rows in the table, you can still keep the table normalized by creating a smaller table that holds this information, then link them by using the primary key.
Let me know if you have any questions about this. I hope this helps!
I went for an interview today where they give me technical test on sql. One of them was how to delete duplicate records without a primary key.
For one I can't imagine a table without a primary key. Yes I have read the existing threads on this. Say this happened and needed to be fixed Now. Couldn't I just add to the end of the table a automatically incrementing id then use that to delete the duplicate record?
Can anyone think of a reason why that won't work? I tried it on a simple database I created and I can't see any problems
You've got a couple of options here.
If they don't mind you dropping the table you could SELECT DISTINCT * from the table in question and then INSERT this into a new table, DROPping the old table as you go. This obviously won't be usable in a Production database but can be useful for where someone has mucked up a routine that's populating a data warehouse for example.
Alternatively you could effectively create a temporary index by using the row number as per this answer. That answer shows you how to use the built in row_number() function in SQL server but could be replicated in other RDBMS' (not sure which but MySQL certainly) by declaring a variable called #row_num or equivalent and then using it in your SELECT statement as:
SET #row_num=0;
SELECT #row_num:=#row_num+1 AS row_num, [REMAINING COLUMNS GO HERE]
One of possible options how to do this:
select distinct rows from your table(you can achieve this using group by all columns)
insert result into new table
drop first table
alter second table to name of first one
But this is not always possible in production
I'm trying to create an access table (with a Primary key) that loads in the data from a Union SQL view.
Im hoping there is a way of achieving this? Ive tried an append and create table queries which copies the data but still no primary key.
I've created a blank table with the fields i want but cant think how to import the fields from the view into it?
Am i better off loading the view into excel?
Any tips would be great!
thanks
I assume you are trying to turn this query into a table because the query takes a long time to run and the data don't change often. In which case this is fine. Otherwise you should really be using your query. And if having a PK is a problem (which it shouldn't be because you can't edit a union query) then you should explain more about what you are trying to do.
Anyway, to turn your query into a table you need to make a table with the columns in your query and add one more column which is an AutoNumber column. This is your PK. Then create your append query like normal. Don't append anything to the AutoNumber column, it will automatically populate itself when a new row is added.
I have one staging table and want to insert data to Main table, so i want to check while inserting data from staging to Main table, if exists then update the records else insert as new records. Here the issue is both the staging as well as Main table does not have any key column based on which i can compare values.
Is it possible to do without having key columns i.e. primary key on both the tables? if yes, please, suggest me how.
Thanks in advance.
If there is no unique key or set of data within a row to define uniqueness, then no.
The set of data can be a combination of the data in each column, creating a sum of parts which will provide uniqueness; however without exposure to your data you would need to make that decision.
You write the WHERE-clause to include all the fields that make your record unique (ie. the fields that decide whether the record is new or should be updated.)
Take a look at this article (http://blogs.msdn.com/b/miah/archive/2008/02/17/sql-if-exists-update-else-insert.aspx) for hints on how to construct it.
If you are using SQL Server 2008r2, you could also use the MERGE statement - I haven't tried it on tables without keys, so I don't know whether it would work for you.
I am working on "cleaning up" a database and need to synchronize the IDENTITY columns. I am using stored procedures to handle the data and mirror it from one table to the next (after cleaning it and correcting the datatypes). At some point in the future I will want to cut off the old table and use only the new table, my question is how to have the IDENTITY field stay in sync while they are both in use... Once the old table is removed the new one will need to continue auto-incrementing and rebuilding/altering it to change the IDENTITY field is not an option. Is this possible or is there a better way to go about this?
My other thought was to create a lookup table to store the ID columns of both tables and anytime there is an insert in the new table take the old ID and new ID and insert them into the lookup table. This is kind of messy once the old table is out of the way tho.
Been there, done that. Put the old id in the new table as an FK. Drop that column just before you drop the old table.
Set the new table's identity to be a non-identity field.
Modify either your data population procedures to populate the non-identity field on your new table with the old table's identity value.
At cutover, switch your new field to auto-increment and set the seed number accordingly.