Excuse me for the title, but I just do not know if this particullary has some name I could have used, just let me know or edit the title with whatever is better.
Now, the question: I have two MySQL tables, one contains a list of items, each item has a unique ID and a title stored. The other table is a list of users. Both tables get more values every day (more users register and more items are added). I would like to save which items each user has already seen, I just need to know if he has or he has not seen a particular item. So, how should I store something like this, what would be the best way? I only thought about having a column on my users table with a string containing coma-separated IDs of the items. But ideally I would need a way that would allow me to do the next things:
Get a list of all the users that checked an item.
Get a list of all the items checked by some user.
Get a list of all the items that an user has not checked.
Get a list of the items that not any user has checked.
Get a list of the items that all the users have checked.
Have a middle table that foreign keys to both tables.
Eg user_items -> useritems_id (PK), user_id (FK), item_id (FK)
comma separated fields are a PITA to search.. better make a third table: (userid, itemid)
Related
Suppose I have a user table that stores the data of single user.
Initially we know nothing about the user, so there is nothing in the table(may be only single column like id which is of no use in this case ).
We do not know what are the details we are going to have about the user and we do not know in which order we are getting the details. Details about user will be obtained gradually in any order.
My question is ,For Example, if I got the name of user, how should I enter it in the table?
I have two options
1) Alter the table structure and add a column called username and store the data there. For all new detail, this process is repeated. So all data will be in one row.
2)Alter the table structure and add to columns key and value. Give name as a key and store the name of user as its value. Thus for each detail about the user,a new row is inserted as key value pairs.
First method makes the table grow horizontally.
Second one make it grow vertically.
which one is good on the basis of good design methods and ease of querying?
If you expect the metadata associated with a user could become arbitrarily large, then adding columns probably isn't the best approach. So this would leave your suggestion to simply add key/value pairs for each new feature associated with a user. There is a third option, which I don't like for so many reasons, which would be to store JSON containing key/value pairs in a single column of the user table. We currently use this approach sporadically, but we handle the JSON manipulation in our Java app layer, which is relatively painless. From a pure database point of view, this isn't so desirable.
So I would vote for your second option of using key/value pairs, because it would scale well. Note that this does not imply that your user table would only have a single column. You might know that a certain number of user attributes will always be there, e.g. username, hashed password, etc., and these columns could be added at the beginning.
Building on what others have already said, you could use a hybrid approach as well. If there are any predefined columns (username, firstname, lastname, password, etc.), you could put those in a table with defined fields, and then link a second table with key/value pairs for additional data.
I am very new to using Access and databasing in general. I need to set up a database to manage car loans. I currently have the following:
A form which displays the information each individual customer
A button at the bottom of the form, titled "View Customer History"
A table with the records of all loans, sorted by car registration number
What I need to do is have access create a custom query which will display all the items from the table containing the loan records that have been rented by the customer that is being displayed in the form. I am aware that creating queries manually is an option but seems impractical due to the number of new customers loaning cars all the time.
I hope that the question made sense and appreciate any help I can get.
I would approach the task in this way:
Create two tables called "Customers" and "Loans"
"Customers" table should have unique records for each customer. One of the fields in this table will be titled "Name" and should obviously contain the names of the customers. Make this field the Primary Key. The other fields will contain other information related to the customer
"Loans" table will have a field called "Customer" which stores the names of the customer loaning out the car. Link this field to the Primary Key of the "Customers" table. The other fields will contain details relating to the loan
Now your form (name of form: "Information") is linked to the "Customers" table and shows all the information stored in the table. Name the field on the form containing the name of the customer as "CustomerName". At the bottom of the form you have a button for viewing customer history
Create the query: SELECT * FROM Loans WHERE Loans.[Customer] = Forms!Information!CustomerName;
Assign this query to the 'On Click' event of the button on the form
There are of course other ways of achieving the desired results, but the way described above is also sufficient.
I'm running on a version of MySQL that does not support foreign key relationships.
Suppose I have two tables, one holds a number of users while the other one holds a number of topics. I want each of the topics to have a field which holds a set of user id's who participated in that topic. I read the type SET's documentation and it says it must be values from predefined values. So how should I go about doing this?
You don't want an extra field, this is a very inefficient way of storing such things. You want a new table.
In your third table (called, say, topicUsers). you would have just two fields: userId and topicId. Then you can look at this table and join data from the others as needed.
This is called normalisation
In a MySQL Database, I have two tables: Users and Items
The idea is that Users can create as many Items as they want, each with unique IDs, and they will be connected so that I can display all of the Items from a particular user.
Which is the better method in terms of performance and clarity? Is there even a real difference?
Each User will contain a column with a list of Item IDs, and the query will retrieve all matching Item rows.
Each Item will contain a column with the User's ID that created it, and the query will call for all Items with a specific User ID.
Let me just clarify why approach 2 is superior...
The approach 1 means you'd be packing several distinct pieces of information within the same database field. That violates the principle of atomicity and therefore the 1NF. As a consequence:
Indexing won't work (bad for performance).
FOREIGN KEYs and type safety won't work (bad for data integrity).
Indeed, the approach 2 is the standard way for representing such "one to many" relationship.
2nd approach is better, because it defines one-to-many relationship on USER to ITEM table.
You can create foreign key on ITEM table on USERID columns which refers to USERID column in USER table.
You can easily join both tables and index also be used for that query.
As long as an item doesn't have multiple owners it's a one to many relationship. This typically gets reduced to the second approach you mention, eg. have a user or created_by column in the Items table.
If a User can have one or more Items but each Item is owned by only a single User, then you have a classic One-To-Many relationship.
The first option, cramming a list of related IDs into a single field, is exactly the wrong way to do it.
Assign a unique identifier field to each table (called the primary key). And add an extra field to the Item table, a foreign key, the id of the User that owns that item.
Like this ERD (entity-relationship diagram)…
You have some learning to do about relational database design and normalization.
I am creating a website that will allow people to make lists, but I'm not sure on the best way to store these lists. Should I make a new table for each user, or is that a bad idea? There will be a few columns to each list.
Thanks in advance
Edit: It will be one list per user, although if it's pretty much the same, I may make it multiple lists to give more options in future. Each list will contain the item, a priority, and possibly another column or two. Users will be able to add, edit, and delete items from their list, and make it private or public.
As Red Filter noted, you should split your info across multiple tables. Your structure depends on what you wish to store in the list, and how users should interact with the lists.. Should one user get to see other users lists? Have multiple lists?
This structure for example lets users have multiple lists, and each list have multiple items:
list
list_id
list_name
creator (user_id)
list_items
list_id
item
user_list
user_id
list_id
Yes, it's a bad idea to create a new table for each user. Instead, add a UserID column to your List table.
Then you can get a given user's lists like this:
select ListID, Name
from List
where UserID = 42 --example UserID
If the lists have the same schema, then you can create a a single ListValues table with a ListID column that is an FK to the List table, with the columns you require. If each user can create their own columns, then you may want to implement an Entity Attribute Value model.
Its bad idea your list table should something like following.
id list user_id