i have a table in which i have started the auto increment id at 10000 so that i have 10000 values reserved for manual insertion of values from admins. However when doing an insert into MyTable(ID,Name,Value) VALUES(500,"Test","Test") i do a select and it ignored my ID i gave it and pushes in into the next 10,000 range. Any suggestions on fixing this or what may be wrong? The code above is of course pseudo but i can give a real code example if it doesnt make sense.
Ok, before you get the answer to your question I have to warn you about extremely bad practice you're trying to do there. Don't get me wrong, many have tried to do what you're doing and it's simply not the way things should work.
Your auto_incremented ID is a primary key. Primary key is used to uniquely identify a row in a table. That's it. It has no other special meaning besides that.
So what does that mean for you? It means that your idea that you will "reserve" 1 - 10k for admins is bad. Why is it bad? Because you're tampering with the primary key. You should never decide what the value of primary key should be, that's databases' job for many reasons (consistency for example).
The other thing why it's bad is that you have limited someone to only 10k possible entries.
On the other hand, how will you calculate what the next entry for admins is? What if you have entered 1, 2, 3, 4 and then you delete entry with ID = 3? What happens then? What's your next in sequence value? 3 or 5?
Having said that, you should probably rethink your strategy. Why not add a field "isAdmin" that will tell you whether an admin posted something or not?
Related
I am creating two tables in a database in MySQL just so I can play around with SQL and learn more, as I am a novice. I have read several questions on Stack relating to inserting a new row, and updating an existing row. My question is a little different, hopefully it won't be considered a dupe as none of the other answers I read gave me the full explanation I need because I think it's the auto-increment part that's confusing me. I don't think I can just go in and assign a new value for the primary keys in one of the tables with auto-increment set up, can I?
I have two tables: english_words and spanish_words. Their primary keys are respectively eng_id and span_id, and are set up to auto-increment. My hope had been to practice SQL and eventually get things set up enough so that I can practice my joins later on. For now, in english_words, I entered a duplicate row by mistake, with the ID 7. I deleted that row, and of course it now goes "6...8..." ..... and when I created my spanish_words table, I forgot all about the missing row 7. I'd hoped to keep everything very simple and aligned between the two tables until I'm ready for more complex endeavors later. Is there a way I can either:
Bump row 7 (and all subsequent rows) down by one in my spanish_words (so 7 becomes 8, 8 becomes 9, etc)
OR
Pull up everything after row 6 in english_words?
OR
Is there a better solution than either of those that you could suggest?
It's possible there's not a way. Originally I'd thought of trying to UPDATE the row 7 data in english_words or maybe insert a new row, but in my research I found an answer on Stack that said you can't insert data into a specific row in the table...and then I realized that's not going to fix anything anyway.
Do those of you more experienced with SQL have any ideas? (Aside from not making such silly mistakes anyway).
Additionally, I'm open to scrapping my tables and starting again, if there's a best-practice that I'm missing. Would setting up a foreign key to correspond between the two tables be a way to fix this? I'm pretty sure you have to do that anyway to perform the joins, but I was going to cross that bridge when I get there. What is best practice amongst database admins - set up foreign keys early on, or later when you need them?
Thanks in advance for your guidance.
A better way to set this up is to create a relation table:
CREATE TABLE translation (
eng_id int,
span_id int,
FOREIGN KEY (eng_id) REFERENCES english_words (eng_id),
FOREIGN KEY (span_id) REFERENCES spanish_words (span_id)
)
This is better than using a foreign key in the original tables, because you can't have bidirection foreign keys (you have to create the referenced row before the referencing row, so whichever table you insert into first can't have a foreign key pointing to the other one).
I'm working on a database that users enter in various data at different times.
Currently I have a many-to-many relationship between three tables.
tblDog: id, Name
tblOwner: id, Name
tblVet: id, name
tblDog_Owner_Vet: id, Dog_id, Owner_id, Vet_id
In a perfect world one would have all the information at one time that connects all three of these entities together but the user might have a bit of information now and then more later. Therefor I let them enter it has they get the information so entries may look like below. I am aware that usually a dog would have only one owner/vet but for sake of this question please consider it possible that a dog can have more than one owner and vet:
1, 1, 1, 1
2, 2, 2, null
3, 2, null, 3
They then can later go back and either add missing info or merge two rows that turn out to be associated.
Is this ok to do or are all these null values a problem? Is there another solution I may be missing?
As documented under Working with NULL Values:
Conceptually, NULL means “a missing unknown value”
Therefore, it is exactly what you want in this case.
You may however like to read up on the criticisms surrounding the use of NULL, which is an age-old debate in the database world.
I just use 0 (zero) for unset foreign key columns.
It might not make a difference in most cases but I like that it is an int type and always simpler to test against in an application.
I would have just added this as a comment but I don't have enough rep yet.
There is a huge disadvantage to using nulls as you suggest. Many to many relationships, or in your case, many to many to many use composite primary keys to uniquely identify records. As you know, primary key columns must be declared not null.
The workaround is to have records in the owner and vet tables that indicate "Not Applicable" or "none" or something like that. Also, you would need a field also part of the primary key, in your many to many table that indicates whether the record is currently true. For example, if you had a vetless dog in your table, you could assign the "not applicable" value to the vet field. Then, when doggie gets a vet, you add a new record and update this record showing that it is currently false.
Edit starts here
From the comment, "Couldn't I just over write the "none"_id in that record with the new Vet's id?". There is always more than one way to accomplish something. Updating the record is one way to do it. Another is deleting the the "none id" record and adding a new one. To help decide, ask yourself how you intend to handle the situation where owner John decides that Dr Bloggins is no longer welcome as Fido's vet.
Also, you are not getting rid of the null to protect the foreign key constraint. You are doing it because vet_id will be part of the primary key so it can't be null.
I have a auto-increment primary key on one of my tables. If I have 3 rows and, for example, delete the third row I'm left with two. However, if I insert a new row its ID is automatically 4 and the IDs are 1, 2 and 4.
How can I re-use the deleted ID and have the ID of the newly inserted record to be 3 automatically?
Really, you shouldn't. Primary keys should be purely technical, meaningless values. Their value, and the monotony of the generation, shouldn't matter at all.
Moreover, since it's the PK of the row, you'll have potentially dozens (or thousands) of other rows in other tables referencing this ID (foreign keys), so changing it in the table would not be enough: you would have to change it everywhere.
And there's a good chance that this ID is also referenced in other applications (for example, it could be part of a bookmarked URL in a browser), and changing its value would make all these references invalid.
You should never change a primary key. It should be immutable, forever.
EDIT: I misread the question. You actually want to reuse an old ID. This is also a bad idea. Existing references would reference something other than they initially referenced. This is what happens when you change your phone number and it's being reused by someone else, who starts receiving lots of calls from people who still think this phone number is yours. Very annoying. You want to avoid this situation.
I have an invoices table which stores a single record for each invoice, with the id column (int AUTO_INCREMENT) being the primary key, but also the invoice reference number.
Now, unfortunately I've had to manual migrate some invoices generated on an old system which have a five digit id, instead of a four digit one which the current system uses.
However, even when I reset the AUTO_INCREMENT through PhpMyAdmin (Table Operations) back to the next four digit id, it still inserts a five digit one being the higher id currently in the table plus one.
From searching around, it would seem that I actually need to change the insert_id as well as the AUTO_INCREMENT ? I've tried to execute ALTER TABLE invoices SET insert_id=8125 as well as ALTER TABLE invoices insert_id=8125 but neither of these commands seem to be valid.
Can anyone explain the correct way that I can reset the AUTO_INCREMENT so that it will insert records with id's 8125 onwards, and then when it gets to 10962 it will skip over the four records I've manually added and continue sequential id's from 10966 onwards. If it won't skip over 10962 - 10966 then this doesn't really matter, as the company doesn't generate that many invoices each year so this will occur in a subsequent year hence not causing a problem hopefully.
I would really appreciate any help with this sticky situation I've found myself in! Many Thanks
First thing I'll suggest is to ditch PHPMyAdmin because it's one of the worst "applications" ever made to be used to work with MySQL. Get a proper GUI. My favourite is SQLYog.
Now on to the problem. Never, ever tamper with the primary key, don't try to "reset" it as you said or to update columns that have an integer generated by the database. As for why, the topic is broad and can be discussed in another question, just never, ever touch the primary key once you've set it up.
Second thing is that someone was deleting records of invoices hence the autoincrement is now at 10k+ rather than at 8k+. It's not a bad thing, but if you need sequential values for your invoices (such as there can't be a gap between invoices 1 and 5) then use an extra field called sequence_id or invoice_ref and use triggers to calculate that number. Don't rely on auto_increment feature that it'll reuse numbers that have been lost trough DELETE operation.
Alternatively, what you can do is export the database you've been using, find the CREATE TABLE definition for the invoices table, and find the line where it says "AUTO_INCREMENT = [some number]" and delete that statement. Import into your new database and the auto_increment will continue from the latest invoice. You could do the same by using ALTER TABLE however it's safer to re-import.
I have one of my primary key column in my table to auto-increment. However when I delete a row from the table that has the highest primary key id (lets say 11). Then the next time I do an insertion it inserts the key as 12 not 11 (though logically it can use 11 as there is no entry associated with the key 11). How can I make this happen?
Are you really sure you want this? An autoincrement column will guarantee a unique number, and that's enough. You could update the next autoincrement value I guess (i'll have to look it up how that works), but I don't think you should want that.
If you need to control the numbers in a column, you should do so manually.
nevertheless, you can change the autoincrement number like so:
ALTER TABLE tbl AUTO_INCREMENT = 100;
(from: http://dev.mysql.com/doc/refman/5.0/en/example-auto-increment.html )
Another remark: If you have numbers one to ten, and you remove 5, you cannot easily do this. You can hardly make the next auto_increment 5 because 6 is already there.
So again, while you can do something dirty for your example, it's really hard to do this in a real environment. Maybe start a new question with description of your situation, and ask for advice how to approach that problem without the auto_increment tricks :)
Mysql doesn't have that feature out of the box, you'll need to code it in your application. One problem you'll have is that if 2 transactions want to get and id, one of the them will get a duplicate id error. Of couse, this is better to avoid.
All the DB engines lack this "feature", as it not good for concurrency.