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?
Related
[ms- access]
I have two tables one called tblContracts and one called tblClientName.
tblClientName contains a list of uniquely named clients.
tblContracts has a list of contracts each of which are assigned a client name, contracts can have the same client names.
In my relationships tool I have setup a many(tblContracts) to one(tblClientName) relationship between the two tables. Both using the field ClientName.
When I enter a new client name(one that doesn't currently exist in tblClientName) into tblContracts I want tblClientName to automatically append this name.
What is the best way to achieve this?
KR
Chris
The database i'm trying to create have four tables. tblPatient information, tblparasitology tests, tblserology tests and tblbiochemical tests. All the later three tables are related to patient information table. What i want to ask is that, is there a problem if i use the primary key in the table patient information to foreign keys of all the other tables? in other words how many tables (foreign keys) can be related to a primary key on one table?
There is really no practical or particular limit here.
however one tip, one concept to keep in mind?
While you can setup all these related tables, to create forms that edit the data?
Each form is STILL based on the one base table.
So you can create a form based on tblPatients.
So allow view and editing and adding of say tblserology results?
That will become a sub form. NOTE VERY careful here that the form tblPaitent is based ONLY on that one table. And the child table (and child form (ie: sub form) tblserology will ONLY be based on tblserology table. So the forms to hook up, wire up the relatonships between the tables are STILL only based on the single table.
To allow editing of related data, you thus use sub forms. If you do this correctly, then no code is required to edit and display and maintain say display of test results for a given patient.
So each and all tables will have a primary key (auto number id).
To realate a child table back up to a parent table, you create a plane jane long number column. This value will be automatic setup for you if you follow the above advice for a main form, and then a sub-form for the child table data.
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
I have a table that holds bibliography entries, with a bibID primary key. I also have a table that holds a list of categories that can be assigned to the bibliography entries with a categoryID primary key. A table links these two tables as bibID:categoryID, so that each bibID can be associated with multiple categoryIDs.
Categories associated with bibliography entries can be edited via a form with checkboxes that represent all possible categories.
What is the most efficient way to update this relationship? I could just delete all relationships from the linking table associated with an entry and then reinsert whatever the form says, but this seems inefficient.
Efficiency is a slippery term. It can mean different things to different people.
However in most cases it means "performance", so I will assume that is what you mean for now.
I suspect the reality is that this is the most efficient (performant) way.
Other methods may appear more elegant, as they will preserve existing data, and only add missing data, but they will (potentially) require more database accesses and (definitely) more complicated SQL. One database call to delete and one to add should fix you up.
The only exception may be where there are large numbers of entries and the changes are small (or negligible). In this case you may need to reconsider.
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