I am writing an app that controls many tables in a database. I am using the AUTOINCREMENT method of sqlite. The items corresponding to the AUTOINCREMENT '_id' collumn will be having their unique ids as the values in the '_id column'
Is it advisable to use this method to assign unique ids to every item. Because i donot know what will happen to the numbering system if I write a method to remove certain rows from the table.
I mean that if once the table is created with certain entries and then the user decides to remove certain rows, will the autoincrement column re-number itself (which will lead to wrong ids being assigned to the corresponding items) or not.
Deleting rows from a table will not reset the auto increment ID. That is, suppose you have created rows 1, 2 and 3. If you delete 2, the next row you insert will still have an ID of 4, i.e, you would now have rows 1, 3, 4 in the database.
Related
Suppose I have a table contacts
id Name Contact_No
-----------------------------------------
1 abc 12345
2 lmn 56784
3 pqr 83654
4 uvw 17637
5 xyz 98345
If I delete row 3 from database, what would be the id of rows following the deleted row?
And if I update row 4, will it be given a new id or the id of row 4 will remain same after updating database?
What is the difference between autoincrement and autoincrement not null? Official documentation says that it will degrade the performance and database will work slow. Is it mandatory to write it along with integer primary key?
I have read many stackoverflow answers and also read SQLite Official Documentation but I couldn't get it.
Assuming id is the name of your INTEGER PRIMARY KEY column.
If you update a row, it will never change its id, since it is still the same row. (that's the whole point of update).
Regarding the creation of new ids, everything is in the doc your linked:
Relevant sections :
Without AUTOINCREMENT
On an INSERT, if the ROWID or INTEGER PRIMARY KEY column is not explicitly given a value, then it will be filled automatically with an unused integer, usually the one more than the largest ROWID currently in use.
There is no strict rule, it can be implementation dependent. Usually it will be equal to select max(id)+1. In you case 6, but if you delete row 5, the id 5 can be reused. (But don't rely on this).
With AUTOINCREMENT
If a column has the type INTEGER PRIMARY KEY AUTOINCREMENT (...) the ROWID chosen for the new row is at least one larger than the largest ROWID that has ever before existed in that same table. If the table has never before contained any data, then a ROWID of 1 is used.
Adding NOT NULL to AUTOINCREMENT is therefore pointless.
In your case, the next id is 6, no matter how many rows you delete before that.
If you just use integer primary key then any insert will use the current maximum ROWID (for which id is effectively an alias) plus one. Thus deleting row 3 and inserting a new row will use 6. However, if you were to delete row 5 (leaving the maximum ROWID at 4) a newly-inserted row would get an id of 5.
If you care about id's not being reused, then you need autoincrement. The reason this is slower (and advised against unless you need it) is that the largest ever value is kept in an internal table. Inserts then have to read/update this internal table as part of their operation. If autoincrement was used, then an insert after deleting either 3 or 5 would create a row with id 6.
A normal update of row 4 would leave the id the same, unless you used insert or replace which effectively deletes the row and inserts a new one. Such an insert would follow the same rules as above.
I insert 2 records in the table at the same time, which has the ID field AUTOINCREMENT. can be assigned to the second record id before? so that when I delete a record using the id are deleted both?
If want two different rows with the same ID and the ID field has AUTOINCREMENT enabled you cannot give them the same ID. That'd be a bad idea for several reasons.
I think what you should rather do is rethink your database and/or table structure. I'd propose you put the rows in different tables and make one of the rows depend on the other. Then you can make them have the same ID in their tables and have one ID to delete both rows in the different tables.
If I have a SQLite table where I delete one row in the middle of it, it removes that row, but the numbering is off. example, removed row 4
id name
1 A
2 B
3 C
5 E
6 F
How can I reset the numbering so that it the key auto incremented key ID is continuous with out the missing 4 like in the table above?
one idea is to delete all the key row ids and re insert them in a for loop. not sure if I should try that as it is auto increment. the other possibility is to make it not auto increment, and use loops to put the numbers in when the table is crated.
You already answered your own question: It's an AUTOINCREMENT field, so you can't do that. Furthermore, this is not how ids should be used in SQL anyway. They are to uniquely identify a row, and if you change the id, then you're breaking that, as well as any references there might possibly be to that id.
Say my SQLite Databate has 2 columns, the first being an auto-incrementing ID and the 2nd being some string. Say right now it's
1 random
2 jellybean
3 ImTired
if I were to delete entry 2, it would then be
1 random
3 ImTired
What I want is a way to make it so when you delete entry 2, it turns it into
1 random
2 ImTired
I thought about updating the entries to shift them all down one and delete the last one, but even if it worked(in my case, it deleted all of my entries, but whatever...), and even if I did get it to
1 random
2 ImTired
the next time I create a new entry, it'll be entry 4. I don't think this necessary to my app, but it seriously bugs me.
The ID column on your DB is working as a Primary Key, which is a column or group of columns used to uniquely identify a row. Once you set a Primary Key on a row you shouldn't change it, else you risk losing the consistency of the DB. For instance, suppose you later create another table that references the rows in your first table. That reference will be made using the Primary Key, and if you later change it your data won't make sense anymore.
If you wanted the ID column to keep changing just to reflect the number of rows in your table you can solve that problem with other methods. For instance. SQL offers a COUNT operator that will return the number of rows in your table:
SELECT COUNT(*) FROM Table_name;
I'm trying to create a database file with objects and sub-objects. For example,
The first table would be of jars for storing change. Each jar entry would have a autoincrement primary ID key and data about the jar, like height, diameter or whatever.
The second table would contain the coins. Each coin would have an ID (needed?) and would also have the ID of the jar that it is contained in and it's data (like value, year, etc.).
My question is what happens to the autoincrement keys when one is deleted? Say you had 4 jars:
1
2
3
4
and you deleted number 2. Would the remaining jars be renumbered 123? or would there be a gap? If there is a gap, is it filled so the next jar created would have an ID of 2? or would the next one still be 5?
Thanks
You can read about that in the sqlite AUTOINCREMENT docs:
The usual algorithm is to give the
newly created row a ROWID that is one
larger than the largest ROWID in the
table prior to the insert. If the
table is initially empty, then a ROWID
of 1 is used. If the largest ROWID is
equal to the largest possible integer
(9223372036854775807) then the
database engine starts picking
positive candidate ROWIDs at random
until it finds one that is not
previously used. If no unused ROWID
can be found after a reasonable number
of attempts, the insert operation
fails with an SQLITE_FULL error.
In short, the after inserting 4 rows, deleting the second, and then inserting another one on the end, the ids would be:
1 3 4 5
It depends on the database implementation. For instance, MySQL inititializes the autoincrement counter at server startup and then keeps the autoincrement number in memory. So if you add 10 rows to an empty table and then delete them all the next autoincrement number would be 11 not 1.