I am very new to database concepts and currently learning how to design a database. I have a table with below columns...
this is in mysql:
1. Names - text - unique but might change in future
2. Result - varchar - not unique
3. issues_id - int - not unique
4. comments - text - not unique
5. level - varchar - not unique
6. functionality - varchar - not unique
I cannot choose any of the above columns as primary keys as they might change in future. So i created a Auto-Increment id as names_id. I also have a GUI( a JTable) that shows this table and user updates Result,issues_id and comments based on the Names.Names here is a big text column. I cannot display names_id in the GUI as it does not make any sense in the GUI. Now when the user updates the database after giving inputs for column2,3,4 in the GUI i used the below query to update the database, i couldnt use names_id in where clause as the Jtable's row_id does not match with the names_id because not all the rows are loaded onto JTable.
update <tablename> set Result=<value>,issues_id=<value>,comments=<value>
where Names=<value>;
I could get the database updated but i want to know if its ok to update the database without even using the PK. how efficient is this? what purpose does the surrogate key serve here?
It is perfectly acceptable to update the database using a where condition that doesn't reference the primary key.
You may want to learn about indexes and constraints, though. You query could end up updating more than one row, if multiple rows have the same name. If you want to ensure that they are unique, then you can create a unique constraint on the column.
A primary key always creates an index on that column. This index makes access fast. If there is no index on name, then the update will need to scan the entire table to look at all names. You can make this faster by building an index on the field.
Related
During the creation of tables using mysql on phpmyadmin, I always find an issue when it comes to primary keys and their auto-increments. When I insert lines into my table. The auto_increment works perfectly adding a value of 1 to each primary key on each new line. But when I delete a line for example a line where the primary key is 'id = 4' and I add a new line to the table. The primary key in the new line gets a value of 'id = 5' instead of 'id = 4'. It acts like the old line was never deleted.
Here is an example of the SQL statement:
CREATE TABLE employe(
id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(30) NOT NULL
)
ENGINE = INNODB;
How do I find a solution to this problem ?
Thank you.
I'm pretty sure this is by design. If you had IDs up to 6 in your table and you deleted ID 2, would you want the next input to be an ID of 2? That doesn't seem to follow the ACID properties. Also, if there was a dependence on that data, for example, if it was user data, and the ID determined user IDs, it would invalidate pre-existing information, since if user X was deleted and the same ID was assigned to user Y, that could cause integrity issues in dependent systems.
Also, imagine a table with 50 billion rows. Should the table run an O(n) search for the smallest missing ID every time you're trying to insert a new record? I can see that getting out of hand really quickly.
Some links you might like to read:
Principles of Transaction-Oriented Database Recovery (1983)
How can we re-use the deleted id from any MySQL-DB table?
Why do you care?
Primary keys are internal row identifiers that are not supposed to be sexy or good looking. As long as they are able identify each row uniquely, they serve their purpose.
Now, if you care about its value, then you probably want to expose the primary key value somewhere, and that's a big red flag. If you need an external, visible identifier, you can create a secondary column with any formatting sequence and values you want.
As a side note, the term AUTO_INCREMENT is a bit misleading. It doesn't really mean they increase one by one all the time. It just mean it will try to produce sequential numbers, as long as it is possible. In multi-threaded apps that's usually not possible since batches or numbers are reserved per thread so the row insertion sequence may end actually not following the natural numbering. Row deletions have a similar effect, as well as INSERT with roll backs.
Primary keys are meant to be used for joining tables together and
indexing, they are not meant to be used for human usage. Reordering
primary key columns could orphan data and wreck havoc to your queries.
Tips: Add another column to your table and reorder that column to your will if needed (show that column to your user instead of the primary key).
There is a table. No PK, 2 FK, with some arbitrary number of columns.
Unfortunately FK are not unique in any way.
Adding new data is easy.
Deleting data (finding a row) is ok if I put unique constraint to some other col.
(DELETE ... WHERE fk1=:fk1 AND fk2=:fk2 AND ucol=:ucol)
What to do with UPDATE?
I cant use that ucol because that same ucol might be subject of change. I have several solutions, but none of them seem ok.
Solution1:
Put PK in table. Use it for DELETE and UPDATE. Deleting will make lot of holes in it but that's no problem. In theory, it can run out of PK numbers (int, unsigned int) if there's some heavy deleting going on.
Solution1a
Make CK of (fk1, fk2, some new col) use that to locate the row. It's the same as just using the PK.
Solution2
Use timestamp with microtime/ hash/ unique key generator/ something to populate new unique col. That col is used as PK to locate the row for UPDATE and DELETE. Excellent only if unique algo does it's job perfectly.
My question:
Is there something better? That doesn't require fancy algorithms and have no risk of overflowing auto-incremented PK...
----------------- edit----------------
Solution2a
Use mysql UUID! It's far better (and easier to use) than, creating custom timestamp / hash / something_unique.
As per my suggestion , it will be better to add a PK to the table because of following reasons:
1. It will give unique id to each row , which will help in DELETE and UPDATE script.
2. PK will create a cluster index on the column which will improve performace of the table while retriving data.
3. Its always adviced to provide a PK in each table.
4. In future you can use the PK as a FK in any table if required.
I am trying to add a row in existing table I want to make it unique when I am trying to alter in phpmyadmin it says #1062 - Duplicate entry '0' for key 'mobile'
What code will help me suggest
This indicates that you have two entries which both have '0' in the mobile column. You can't force the column to be UNIQUE because there's non-unique data in their now. The solution is to resolve the conflict, but whether that's a good idea and how exactly to do so depends on your database design. The act of doing it is rather simple (just edit that row and assign a new value for 'mobile'), but depending on your design that could damage some data.
So without knowing the details, I can only caution you to not destroy any data or relations.
If you don't have a primary or unique key in that table, phpMyAdmin doesn't show the '"grid edit" feature, so if that's the case you can either write a little SQL to update the row directly, or temporarily add a new column, make it an autoincrementing primary key, do the edit through the phpMyAdmin interface, then remove the temporary autoincrement column (that's what I'd do; I just tested it and it took me about 30 seconds to add the column and key, edit a row, and delete the temporary column).
How to rearrange primary key column values after deleting some rows from a table in MySQL?
Foe example; a table with 4 row of data with primary key values 1,2,3,4. When delete 2nd and 3rd rows, then the key value of 4th row change to 2.
Please help me to find solution.
Why do this? You don't need to rearrange your key since it's only number, identifier for record. It has no actual meaning - so let DBMS handle that. This is a very common mistake - trying to take DBMS role.
However, I'll answer your question for common case. In MySQL you can rearrange column with:
update t cross join (select #cur:=0) as init set t.col=#cur:=#cur+1
-this, however, can't be used with column under UNIQUE (so primary key as well) restriction since during update you'll possibly get duplicate records. You should drop restriction first before do that (and create it again after update).
One method is THIS ONE.
Other then that, you can simply drop the table which is primary and then again create it. This will do the job
Why do you want to change primary keys for your data? In general this is bad idea to do that, especially when integrity contstraints comes into the game. If you need to do such thing, I would say you have bad DB desing and you should take closer look on that aspect.
I've got the following situation: I want to store data, which represents, if a user is following another user. Another table, which I cannot touch, stores the users, where the username is the primary key (unfortunatly no id...).
The fact is, if one user follows another one, it doesn't mean, that the other one is following the first one.
Right now, I designed the table with two varchar's (128) and a UNIQUE INDEX on these two varchar's which represent the usernames.
The problem is, that I need to parse some old-styled system now, and I finished like 15% and I've got 550k entries on this table already.
The index is bigger then 16MB, and the data just 14MB.
What could I do, to save this data in a better way? As said, I cannot use id's instead of the usernames, because the user-table uses the username as primary key.
As you have noticed, creating a seperate index on all columns essentially forces MySQL to duplicate all data in the index.
Instead of creating a seperate unique index, you can create a primary key consisting of both of your fields. MySQL uses the primary key as a clustered index making sure your uniqueness constraint is still satisfied without increasing the size of your database.
You might consider building your own index table that contains ID > username.
You could then use the ID's to map the followers.
This will cause for some extra overhead if you want to retrieve all the data.