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
Related
So I'm trying to work on a small app that would allow you to have a grocery list that can be edited by multiple people via their mobile phone. So I'm trying to design the database I will use on the backend. I'm having trouble figuring out how to relate all the tables. User will be able to be apart of multiple lists, and each list will be accessible by multiple people. ( I believe this is called a many-to-many relationship?)
So far my tables look as follows:
User(id, name)
List(id, Name)
List_item(id, List_id(key), name, amount)
The list to list_item ID relationship is easy enough, but how do I go about modelling the relationship between Users and Lists? Do I need a separate join table:
User-to-List(User ID,List ID)
I'm trying to come up with the most efficient structure as possible, Thanks!
Edit: Only the user needs to know about all the lists he is associated with, the list doesn't need to keep track which user are associated with it. At least for the initial app!
Many-to-many:
CREATE TABLE ListsUsers (
list_id ...,
user_id ...,
PRIMARY KEY(list_id, user_id),
INDEX(user_id, list_id)
) ENGINE=InnoDB;
Then use suitable JOINs to connect the tables when doing a SELECT.
I'm building a system that will auto-drop someone from one or more mailing lists, when they subscribe to another mailing list. I have a table 'lists' containing the list names. Each list will have one or more children in the form of 'exclusions', which are basically other lists. Here is my table:
I'm wondering how best to achieve this. I originally thought of having another table called 'exclusions' linked via a lookup table with a many-to-many relationship, then I could grab all the exclusions for a particular list name.
However, the exclusions are basically the same list names that are contained in the lists table, so it seems like I have redundant data there.
Would there be a better way of acheiving this? I considered adding an extra column to the lists table, containing the ID's of the other lists that I need to exclude.
I think adding a new table that will link the ID of your list to the ID of the email address would be the best course of action with this. Then when your system goes to send email to a specific list, the lookup can be done on this table using joins to the referenced tables.
I found that the answer lies here, in the form of a 'junction' or 'mapping' table: How can I associate one record with another in the same table?
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)
I'd like to design something that would allow users to put lists together of, let's say, grocery items. If each user can have multiple lists (i.e. not a set amount) and those lists all have a variable number of items on them (again, not set) while some items appear on several different lists, how do I create a database without being horribly redundant?
I'm completely new to this kind of problem, not having put together any complex database before, and have no idea where to start. This is what I came up with as an example, but I doubt this is the right way of doing things:
Any help or ideas would be much appreciated!
Looks like you need something similar to this:
A list is private to user, but an item can be shared among multiple lists:
The relationship between USER and LIST is one-to-many which is modeled through a simple foreign key.
The relationship between LIST and ITEM is many-to-many, which is modeled by a junction (aka. link) table in between them: LIST_ITEM.
I have used identifying relationship between USER and LIST in the diagram above, producing more "natural" keys in the "downstream" tables which:
Reducing the need for JOINs (you already know which USER a given LIST_ITEM belongs to, without the need to JOIN with LIST).
But makes downstream keys "fatter".
The design using non-identifying relationship between USER and LIST (producing "slimmer" keys) would look like this:
You can create join table LIST_LINK_ITEM between three tables
Her primary key is : composition of three primary keys
The best way to describe this scenario is to use an example. Consider Netflix: do they
store their orders (DVD's they mail out) in a separate table from their member lists (NOT members table, but a joiner table of members and movies--a list of movies each member has created), or are orders distinguished by using additional information in the same row of the same table?
For those not familiar with Netflix, imagine a service that lets you create a wish list of movies. This wish list is subsequently sent to you incrementally, say two movies at a time.
I would like to implement a similar idea using a MySQL database, but I am unsure whether to create two tables (one for orders and one for lists) and dynamically move items from the lists table to the orders table (this process should be semi-automatic based on the member returning an item, where before a new one is sent out, a table with some controls will be checked to see if the user is still eligible/has not gone over his monthly limit)...
Thoughts and pros and cons would be fantastic!
EDIT: my current architecture is: member, items, members_items, what I am asking is if to store orders in the same table as members_items or create a separate table.
Moving things from one database table to another to change its status is simply bad practice. In a RDBMS, you relate rows from one table to other rows in other tables using primary and foreign key constraints.
As for your example, I see about four tables just to get started. Comparing this to Netflix, the grand-daddy of movie renting, is a far-cry from reality. Just keep that in mind.
A User table to house your members.
A Movie table that knows about all of the available movies.
A Wishlist or Queue table that has a one-to-many relationship between a User and Movies.
An Order or Rental table that maps users to the movies that are currently at home.
Statuses of the movies in the Movie table could be in yet another table where you relate a User to a Movie to a MovieStatus or something, which brings your table count to 6. To really lay this out and design it properly you may end up with even more, but hopefully this sort of gives you an idea of where to begin.
EDIT: Saw your update on exactly what you're looking for. I thought you were designing from scratch. The simple answer to your question is: have two tables. Wishlists (or member_items as you have them) and Orders (member_orders?) are fundamentally different so keeping them separated is my suggestion.
A problem with storing orders in the members table is that there's a variable number (0, 1, or several) of orders per member. The way to do this using a relational database is to have two separate tables.
I feel like they would store their movies as follows (simplified of course):
tables:
Titles
Members
Order
Order_Has_Titles
This way an order which has a foreign key to the Members would then have a pivot table as many orders could have many titles apart of them.
When you have a many to many realtionship in the database you then need to create a pivot table:
Order_Has_Titles:
ID (auto-inc)
Order_FkId (int 11)
Title_FkId (int 11)
This way you're able to put multiple movies apart of each order.
Of course this is simplified, and you would have many other components which would be apart of it, however at a basic level, you can see it here.