I'm using MySQL Workbench to create a user table. I would like to make name and surname unique. On their own, name or surname are not unique as long as both are not duplicated simultaneously by a separate record.
Can I do this using MySQL Workbench or do I have to execute a a SQL statement manually? If so, what is the syntax?
So, there can be many name=John and surname=Doe but only 1 John Doe
In the tabs underneath the table design window, you'll see "Indexes". Click that tab, create a new unique index, tick the boxes for the columns you want to include in the unique index.
(The view you're looking at in your question is the "Columns" view, which lets you change details of individual columns, each of which can include a "unique" property, but for multi-column uniqueness you need to create an index.)
Related
I'm using Access 2007. I have two tables, first one has a PK (primary key), but the second has not.
When using a query linking the two tables on the PK, I need the rows have the same sort as it is in the second table (means as records has been entered), but this doesn't happen by default, I don't know why!
Tables are just a big bucket that holds data. There is no order to them unless you supply it. Therefore, in order for the items in your query/table to appear in the order that they were entered you will have to supply something that allows Access to apply this sorting for you.
You should add an AutoNumber Primary Key to the DataSub table. This will automatically increase every time that you add new data to this table, and so you can then use this in any queries to sort by.
Regards,
We'd like to prevent record duplication in our MS access database using a multicolumn unique index. Because of how the data is sent (via network), duplicate data is sometimes received. The data source does not send a unique ID, so the simplest option is to prevent duplicate records being inserted.
According to Unique Index Design Guidelines:
With multicolumn unique indexes, the
index guarantees that each combination
of values in the index key is unique.
For example, if a unique index is
created on a combination of LastName,
FirstName, and MiddleName columns, no
two rows in the table could have the
same combination of values for these
columns.
This is for SQL 2005 however, so I'm not sure it's possible using MS access.
I guess an alternative is to perhaps use the query (pseudo code):
insert into foobar (a, b, c) values ('x', 'y', 'z')
where (a <> 'x') and (b <> 'y') and (c <> 'z')
... but I feel like an index would be better.
Turns out you can create a multi-column unique index on an MS access database, but it's a little crazy if you want to do this via the GUI. There's also a limitation; you can only use 10 columns per index.
Anyway, here's how you create a multi-column unique index on an MS access database.
Open the table in design mode, and Design, select Indexes.
Create a new row and enter a value in the Index Name cell,
Choose the first column from the drop down menu.
Add a new row and leave the Index Name cell blank.
Choose the second column, and so on.
Here's what it should look like:
Open the table in design view in MS Access, select the three columns that you want to make into the unique index, and then click the little key on the toolbar. You cannot have null values in a primary key (set).
We can make multi data to be unique data without set them as primary key.
(Note: only 1 data in the table can be primary key)
Step to set the data value as unique data (for MS ACCESS 2007 - 2010)
Open selected table in Design View
Click (Highlight) the specific column/attribute that you wish to set as unique
At the bottom of the table you will see "Index Properties" for that specific column
Find "Indexed" column, currently the data in Indexed text box is "No", change the data by click at the end of text box, choose "Yes(No Duplicates)"
Really hopes this methods can helps all of you! :)
I had the problem Nick Bolton reported above. Setting 2 fields (Foo, Bar) as PK set Foo to unique, when I wanted only the combination of Foo + Bar to be unique.
The problem turned out to be that I had created a 1:1 relationship to another table, linking on Foo. I deleted the relationship, set up the 2-field PK the way I wanted, and then reinstated the relationship, and it works as desired.
A trick I found is that in order to get a 2 column primary key (in the parent table) to be a child table´s 2(FK)+n primary key is to FIRST CHOOSE the indexed attribute as FISRT key attribute and THEN the not indexed attribute as a SECOND key attribute in the "Modify Relations Dialog Box" #Relations Window.
It will serve as Unique key in Ms Access 2007/2010
My MainTable contains tasks, one of the colums speciefies the TaskType as a string. The TaskType must be selected from the ValidTasks table, which contains different task types.
The ValidTasks table also contains a column called Priority which is an integer.
Now I want my MainTable to include the priority of the selected task. So that when I select as task from ValidTasks the corresponding Priority is added to another column in MainTable.
In the following step I will create a query showing the highest priority figure for each Person (also in the MainTable), so if it is easier to approach though a query then that would work for me too.
There are two ways you can go about this. The one I would go for unless there are overriding factors would be to use a SELECT query that links the two tables and has the fields I want as my "Main Table".
That is by far the best way. The alternative is to use the trigger of the user making a selection for a TaskType to look up and populate a field in your main table. I would not recommend that as it will come back to bite you as your database gets more complicated.
Also, I would not use a text field for TaskType. Your tables should have an AutoNumber as primary key and that is the field you should always use to link data from one table to another.
I'm new to MS Access and hopefully my question is simple, but I haven't been able to find a clear answer through googling.
I have a simple database with a table it, and there is a subset of fields that must have unique contents. I understand how to set that up so that a specific field across all the records must be unique, but I need several fields across all records to have unique contents.
For example only one field, in one record, across fields 4 - 10, in all records, can have the number '1' in it. If '1' is in field 5 of record A, it cannot also be in field 8 of record F.
As an analogy, imagine we are building computers, each with 1 or 2 video cards. In the database some of the fields are storing the serial number of the video card installed in that slot. Obviously, serial numbers are unique, and the same card can't be installed in two slots, whether in the same computer, or in two different computers. I need the database to prevent the user from entering duplicate serial numbers. In the example image there are duplicates of the same serial number in different fields of different records. This should NOT be allowed. example
Is there a built-in way to implement this sort of user entry check? If not, how can I implement it?
You want a unique composite index. To make this
Go to design view on the table
Open the Indexes editor window
Go to a new line, enter the name of your new index, select the Field Name
In Index Properties pane change the Unique property to Yes
Go to a new line, do not enter an index name, select another Field Name
Done
Edit:
The real issue is that you need to normalize your data. Slot #1 and Slot #2 are not really columns. You need to set up your table like this
Not that I made all three columns a composite primary key AND I made the VideoCard column indexed to not allow duplicates
Then when you go to enter your bad data you get this message
and it's won't let you commit until you enter good data.
If you need to present your data pivoted like your original example then you can do this in a cross tab query
which will make results like this
So imagine you have multiple tables in your database each with it's own structure and each with a PRIMARY KEY of it's own.
Now you want to have a Favorites table so that users can add items as favorites. Since there are multiple tables the first thing that comes in mind is to create one Favorites table per table:
Say you have a table called Posts with PRIMARY KEY (post_id) and you create a Post_Favorites with PRIMARY KEY (user_id, post_id)
This would probably be the simplest solution, but could it be possible to have one Favorites table joining across multiple tables?
I've though of the following as a possible solution:
Create a new table called Master with primary key (master_id). Add triggers on all tables in your database on insert, to generate a new master_id and write it along the row in your table. Also let's consider that we also write in the Master table, where the master_id has been used (on which table)
Now you can have one Favorites table with PRIMARY KEY (user_id, master_id)
You can select the Favorites table and join with each individual table on the master_id and get the the favorites per table. But would it be possible to get all the favorites with one query (maybe not a query, but a stored procedure?)
Do you think that this is a stupid approach? Since you will perform one query per table what are you gaining by having a single table?
What are your thoughts on the matter?
One way wold be to sub-type all possible tables to a generic super-type (Entity) and than link user preferences to that super-type. For example:
I think you're on the right track, but a table-based inheritance approach would be great here:
Create a table master_ids, with just one column: an int-identity primary key field called master_id.
On your other tables, (users as an example), change the user_id column from being an int-identity primary key to being just an int primary key. Next, make user_id a foreign key to master_ids.master_id.
This largely preserves data integrity. The only place you can trip up is if you have a master_id = 1, and with a user_id = 1 and a post_id = 1. For a given master_id, you should have only one entry across all tables. In this scenario you have no way of knowing whether master_id 1 refers to the user or to the post. A way to make sure this doesn't happen is to add a second column to the master_ids table, a type_id column. Type_id 1 can refer to users, type_id 2 can refer to posts, etc.. Then you are pretty much good.
Code "gymnastics" may be a bit necessary for inserts. If you're using a good ORM, it shouldn't be a problem. If not, stored procs for inserts are the way to go. But you're having your cake and eating it too.
I'm not sure I really understand the alternative you propose.
But in general, when given the choice of 1) "more tables" or 2) "a mega-table supported by a bunch of fancy code work" ..your interests are best served by more tables without the code gymnastics.
A Red Flag was "Add triggers on all tables in your database" each trigger fire is a performance hit of it's own.
The database designers have built in all kinds of technology to optimize tables/indexes, much of it behind the scenes without you knowing it. Just sit back and enjoy the ride.
Try these for inspiration Database Answers ..no affiliation to me.
An alternative to your approach might be to have the favorites table as user_id, object_id, object_type. When inserting in the favorites table just insert the type of the favorite. However i dont see a simple query being able to work with your approach or mine. One way to go about it might be to use UNION and get one combined resultset and then identify what type of record it is based on the type. Another thing you can do is, turn the UNION query into a MySQL VIEW and simply query that VIEW.
The benefit of using a single table for favorites is a simplicity, which some might consider as against the database normalization rules. But on the upside, you dont have to create so many favorites table and you can add anything to favorites easily by just coming up with a new object_type identifier.
It sounds like you have an is-a type relationship that needs to be modeled. All of the items that can be favourited are a type of "item". It sounds like you are on the right track, but I wouldn't use triggers. What could be the right answer if I have understood correctly, is to pull all the common fields into a single table called items (master is a poor name, master of what?), this should include all the common data that would be needed when you need a users favourite items, I'd expect this to include fields like item_id (primary key), item_type and human_readable_name and maybe some metadata about when the item was created, modified etc. Each of your specific item types would have its own table containing data specific to that item type with an item_id field that has a foreign key relationship to the item table. Then you'd wrap each item type in its own insertion, update and selection SPs (i.e. InsertItemCheese, UpdateItemMonkey, SelectItemCarKeys). The favourites table would then work as you describe, but you only need to select from the item table. If your app needs the specific data for each item type, it would have to be queried for each item (caching is your friend here).
If MySQL supports SPs with multiple result sets you could write one that outputs all the items as a result set, then a result set for each item type if you need all the specific item data in one go. For most cases I would not expect you to need all the data all the time.
Keep in mind that not EVERY use of a PK column needs a constraint. For example a logging table. Even though a logging table has a copy of the PK column from the table being logged, you can't build a constraint.
What would be the worst possible case. You insert a record for Oprah's TV show into the favorites table and then next year you delete the Oprah Show from the list of TV shows but don't delete that ID from the Favorites table? Will that break anything? Probably not. When you join favorites to TV shows that record will fall out of the result set.
There are a couple of ways to share values for PK's. Oracle has the advantage of sequences. If you don't have those you can add a "Step" to your Autonumber fields. There's always a risk though.
Say you think you'll never have more than 10 tables of "things which could be favored" Then start your PK's at 0 for the first table increment by 10, 1 for the second table increment by 10, 2 for the third... and so on. That will guarantee that all the values will be unique across those 10 tables. The risk is that a future requirement will add table 11. You can always 'pad' your guestimate