Will it not be right to create a field of unique values ​​in a SQL table? Will the table below work normally? Relational DB

Here is:

CREATE TABLE `dev_users` ( `user_id` int(10) unsigned NOT NULL, `part_id` int(10) unsigned NOT NULL, `status` enum('1','2','3','0') NOT NULL DEFAULT '0' , `order` int(11) unsigned NOT NULL, PRIMARY KEY (`user_id`,`part_id`,`order`), KEY `user_id` (`user_id`) USING BTREE, KEY `part_id` (`part_id`) USING BTREE, CONSTRAINT `part_id` FOREIGN KEY (`part_id`) REFERENCES `part_develop` (`part_id`), CONSTRAINT `user_id` FOREIGN KEY (`user_id`) REFERENCES `account` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
  • if you don’t need it why not - Naumov
  • @Naumov I am afraid, whether it will work more slowly or with glitches. Thank. - gilo1212
  • It all depends on the architecture. If you need a certain table for a coordinate, and a certain indexer will never be used, then why is it necessary? - Naumov
  • @Naumov Thanks a lot. - gilo1212
  • 2
    You would write what fields are responsible for, especially order. The question whether or not to do so is solely in the nature of the data. And it is also important whether the need to refer to this one from other tables. Link to 3rd fields is heavy in support. Uniqueness with order looks a bit strange. usually, the links of two tables through this one are unique in themselves, and judging by the fact that there are two entries from two tables that can be connected to each other simultaneously with different orders ... - Mike

1 answer 1

The answer is short: quite normal. Moreover, this is exactly what should be done in your case.

Creating a unique field that will never be used by anyone will be a bigger mistake.