It is possible to maintain a table of a database organized alphabetically
through triggers whenever you insert a new row like this:
INSERT INTO Software (name_software) VALUES ('linux');
name_software
1 windows
2 CAD
name_software
1 CAD
2 linux
3 windows
I am using the sybase central. I apologize if my post seems very inconsistent tried to explain in the simplest way.
Thank you.
The order of rows in a table (physically in the database) is decided by a clustered index. Put one on the name_software column and that's it.
But
1) you really don't "need" to sort the data in the table physically like this. It is a database... :) You can sort it by a query.
2) clustered index is most often on primary key and there can of course be only one on a table...
You want to re-order the entire table (and re-seed the identity column for that table) each time you insert (or update) a record?
Why can't you include ORDER BY ASC in your query when retrieving data instead?
Related
just wondering how to reorder rows in this table? I want to have 2015 through 2019 ASCENDING as happiness_rank increases, but 2015 automatically goes to the bottom of the table.
I have tried using
UPDATE table_name ORDER BY happiness_rank;
but that doesn't work, and similarly ALTER TABLE doesn't seem to work either. I know I can do it with SELECT but that doesn't save the table, and when I try to do UPDATE with SELECT and ORDER BY it doesn't work.
h_score
happiness_rank
economy_gdp_per_capita
2
1.52733
4
1.56497955322266
5
1.420
6
1.452
2015
1
1.39651
SELECT query is always used while reading table, so the info about how your tables is stored in SQL is pointless to you. If I am missing something, please tell me as even during export - you will use SELECT query.
You can do one of the following according to your needs:
If your table does not have any Indexes or Foreign Keys then simply use ALTER
ALTER TABLE tablename ORDER BY happiness_rank ASC;
However, it does not make sense to order them on insert. I wouldn't do this. (Not Recommended)
Add a new column with datatype integer which is sorted ASC and set it as the primary key. Usually, this is the column that has some unique ID and is an auto-generated sequence. (Recommended)
My scenario is like I have thousands of row in a table. And the table has 8 columns. I would like to check whether the exact same row exists in the table. My requirement I shouldn't insert the same row in the table twice. Obviously, to do so I have to compare every row before any new insertion. I don't have much SQL expertise, so I don't know what is the best way to so that I can gain maximum efficiency. Please advice me.
A simple option is to create unique index that contains all those columns, e.g.
create unique index ui1_your_table on your_table (col1, col2,..., col8);
Database would take care about the rest.
I am planning for an incremental load into warehouse (especially for updates of source tables in RDBMS).
Capturing the updated rows in staging tables from RDBMS based the updates datetime. But how do I determine which column of a particular row needs to be updated in the target warehouse tables?
Or do I just delete a particular row in the warehouse table (based on the primary key of the row in staging table) and insert the new updated row?
Which is the best way to implement the incremental load between the RDBMS and Warehouse using PL/SQL and SQL coding?
In my opinion, the easiest way to accomplish this is as follows:
Create a stage table identical to your host table. When you do your incremental/net-change load, load all changed records into this table (based on whatever your "last updated" field is)
Delete the records from your actual table based on the primary key. For example, if your primary key is customer, part, the query might look like this:
delete from main_table m
where exists (
select null
from stage_table s
where
m.customer = s.customer and
m.part = s.part
);
Insert the records from the stage to the main table.
You could also do an update existing records / insert new records, but either way that's two steps. The advantage of the method I listed is that it will work even if your tables have partitions and the newly updated data violates one of the original partition rules, whereas an update would not accomplish that. Also, the syntax is much simpler as your update would have to list every single field, whereas the delete from / insert into allows you list only the primary key fields.
Oracle also has a merge clause that will update if it exists or insert if it does not. I honestly don't know how that would be impacted if you had partitions.
One major caveat. If your updates include deletes -- records that need to be deleted from the main table, none of these will resolve that and you will need some other way to handle that. It may not be necessary, depending on your circumstances, but it's something to consider.
I have a table people with less than 100,000 records and I have taken a backup of this table using the following:
create table people_backup as select * from people
I add some new records to my people table over time, but eventually I want to merge the records from my backup table into people. Unfortunately I cannot simply DROP my table as my new records will be lost!
So I want to update the records in my people table using the records from people_backup, based on their primary key id and I have found 2 ways to do this:
MERGE the tables together
use some sort of fancy correlated update
Great! However, both of these methods use SET and make me specify what columns I want to update. Unfortunately I am lazy and the structure of people may change over time and while my CTAS statement doesn't need to be updated, my update/merge script will need changes, which feels like unnecessary work for me.
Is there a way merge entire rows without having to specify columns? I see here that not specifying columns during an INSERT will direct SQL to insert values by order, can the same methodology be applied here, is this safe?
NB: The structure of the table will not change between backups
Given that your table is small, you could simply
DELETE FROM table t
WHERE EXISTS( SELECT 1
FROM backup b
WHERE t.key = b.key );
INSERT INTO table
SELECT *
FROM backup;
That is slow and not particularly elegant (particularly if most of the data from the backup hasn't changed) but assuming the columns in the two tables match, it does allow you to not list out the columns. Personally, I'd much prefer writing out the column names (presumably those don't change all that often) so that I could do an update.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
select bottom rows in natural order
People imagine that i have this table :
persons
columns of the table are NAME and ID
and i insert this
insert into persons values ('name','id');
insert into persons values ('John','1');
insert into persons values ('Jack','3');
insert into persons values ('Alice','2');
How can i select this information order by the insertion? My query would like :
NAME ID
name id
John 1
Jack 3
Alice 2
Without indexs (autoincrements), it's possible?
I'm pretty sure its not. From my knowldege sql data order is not sequetional with respect to insertion. The only idea I have is along with each insertion have a timestamp and sort by that time stamp
This is not possible without adding a column or table containing a timestamp. You could add a timestamp column or create another table containing IDs and a timestamp and insert in to that at the same time.
You cannot have any assumptions about how the DBMS will store data and retrieve them without specifying order by clause. I.e. PostgreSQL uses MVCC and if you update any row, physically a new copy of a row will be created at the end of a table datafile. Using a plain select causes pg to use sequence scan scenario - it means that the last updated row will be returned as the last one.
I have to agree with the other answers, Without a specific field/column todo this... well its a unreliable way... While i have not actually ever had a table without an index before i think..
you will need something to index it by, You can go with many other approaches and methods... For example, you use some form of concat/join of strings and then split/separate the query results later.
--EDIT--
For what reason do you wish not to use these methods? time/autoinc
Without storing some sort of order information during insert, the database does not automatically keep track of every record ever inserted and their order (this is probably a good thing ;) ). Autoincrement cannot be avoided... even with timestamp, they can hold same value.