Users on my site are shown a list of items. The list they see is based on criteria they have completed in a form - they're receiving suggestions if you like.
Now, if a user doesn't want to receive a certain suggestion again, i want them to be able to stop it from showing up.
So, do i create an exceptions table which simply has a user id number and suggestion id number per row and search that before giving suggestions..meaning if the user has previously said no then skip to next suggestion.
Or, do i have a table with a row per user which has their user id and a field of all their exceptions, maybe comma separated or enclosed in[] and do a "where in" search to see if an exception is there - if the latter though and the user decides they do want a particular suggestion at a later date, its easier to get it out of a row per suggestion table as opposed to a field where they are, in fact i wouldn't know if thats even possible.
All advice welcome.
It sounds like a many-to-many relationship between users and preferences/exceptions. I'd rather do that than the IN idea.
I'd have a table of "available suggestions" with a suggestion reference and a user reference. so for each user there would be one record for each suggestion available to them. When a user user clicks no, then that record can be deleted from the available suggestions.
Hope this makes some kind of sense.
Related
I have learned more, and was compelled to find the solutions, mind changed.
PS dear experts, your help is appreciated in the time-saving nature of having forums and discussion in the first place, and also is mined for usefulness, not street cred. get helping or get off. The time I wasted reading posts where the answer was "I don't understand what you are trying to do..." and then questioning the OP with animus or incredulity, or suggesting some unrelated answer further confusing issues, is seemingly the problem with the world these days, if you want to help, help
Original Post:
Ok so as per the comments, thanks to ANYONE who volunteers any help with this problem.
I have a table and relationship design problem.
I have a table with a pk auto and I want to have a related table with a related column incrementally numbered that updates every time new data is entered in the form that is bound to it. It needs to update the related rows in the autonumbered table's key.
---the answer was to join the table on the autonumbered field.
The autonumber of the first table (main recordsource) is just an ID. I think I need two Primary Keys as I need to update the related record with that number in the entry form and move to NextRec but update the pk in the main table and move to NewRec , how do I join (see jpg image)?
I want enter results and update that existing record but update the adjoining pk so that a new record is created in the main table.
Tourney
more in depth:
From yours
My desired form
note that the calculation table feeds the upcoming games table, where a query shows the players recent results. I would like to split the upcoming results to show the players' recent game history, the second tab I would like to enter either one result or many results at a time. I hope I am clearer. You can see why I have had a challenge. See my form though. The recordsource is the upcominggames table and the data entry form is for input (ENTER GAME DATA)
-----the answer to this was an update query (a separate form) and then requery the statistics form to show the new matchups that were entered.
As from the comments, this is what I'm thinking of when I read your description:
Since the UpcomingGames will be entered first and exactly one GameResult can be entered per UpcomingGame, this will be a 1:1 relationship. As the name Upcoming says: The Upcoming data has to be entered before the Result can make sense. Unless an UpcomingGame can be cancelled, there will indeed be a Result for the Game, so there is no need to separate the information into 2 tables. I'd say, a user interface could look like this:
As you can see, the T_NUM column is an autovalue. Before entering any data, I initialized that column using a query like this (and deleted that record afterwards):
INSERT INTO Games ( T_NUM )
VALUES (1004);
This way, the numbering started with number 1005.
You won't be able to to avoid gaps in the numbering, as long as the users can remove existing records or cancel the insertion of a new record. If you want at least to avoid the latter, you will need some VBA code in the form.
Let's say that I have a website and I want to know all the users that logged in during a certain time interval.
Would it be a good idea to create a new table in the database for this purpose and add a new entry whenever a users logs in?
The table would contain 2 columns: the id of the user and the login date.
My main concern is that the number of entries from the table will become extremely large.
Can this be considered a good idea? Do you know if this method is being applied for other websites?
Thanks in advance!
The number of records in a table can be controlled via external script, which is put on cron/scheduler. If it becomes too big, old records can be removed
if it is not possible, as a workaround there could be a check of the number of records on each insert
just do not forget to set an index on the date field...
Yes, you can create a table that logs all the login time of each user. If there are millions of users you might want to store the recent login time instead. If space is not a problem then it will be good to store the login time each time a user is authenticated or authorized. Like this you can archive the data in this table periodically.
The general answer to this question is 'depends'.
You can:
Add user to the table on login. You hit the disk for each user, so be careful with a big amount of users.
You store a bunch of users in memory and write all the group at a certain size or time. This way you hit the disk fewer times.
Depending on how many users you expect you can think of a no-SQL solution.
Depending on your system, I advise the 2nd o 3rd approach
Read this for more info: Fast write performance, even if reads are very slow
I have a question about web usability related with tables, this is my use case:
I have a view with more than 1 table, I mean, I have N>0 tables in the view and each table has a title (for example "Photo list", "Video list", "Sound list").
Using javascript, users have the possibility to change the "view level", I mean, the detail level of the view. This means that clicking in different action buttons (basic, medium, advance view) the users can modify the amount of rows in each table. So, could be that some of the tables would be empty (no rows).
My question: What is the best usability practice to manage empty tables?
When you have identified tables that shows certain information you shouldn't hide then when they are empty, at least not without showing in any way that there's no data related to the empty table.
If you don't show the table maybe your users don't perceive that there is an entity of data that's empty, if you show it they will. This is important.
It could, however, be less important depending on the way you are showing your data. Let's say, for example, that your view shows on top a list of the different data types with the number of records in each one. If you keep a reminder there that X data type has 0 records, you can hide the table header on the view body, as all the info your user need is on the view.
On the contrary, if your users have no way to know that a specific data type is empty other than seeing an empty table, you need to keep it in your view to avoid them loosing information.
Keep in mind that information is the key on our world. Design is important to help and improve user experience, but you shouldn't put it before information.
I am creating a new DB in MySQL for an application and wondered if anyone could provide some advice on the following set up. I'll try and simplify things as best as I can.
This DB is designed to store alerts which are related to specific items created by a user. In turn there is the need to store notes related to the items and/or alerts. At first I considered the following structure...
USERS table - to store basic app user info (e.g. user_id. name, email) - this is the only bit I'm fairly certain does not need to be changed
ITEMS table: contains info on particular item (4 fields or so). Contains user_id to indicate which user created/owns this item
ALERTS table: contains info on the alert, item_id to indicate which item the alert is related to, contains user_id to indicate which user created alert
NOTES table: contains note info, user_id of note owner, item_id if associated with an item, alert_id if associated with alert
Relationships:
An item does not always have an an alert associated with it
An item or alert does not always have a note associated with it
An alert is always associated with an item. More than one alert can be associated with the same item.
A note is always associated with an item or alert. More than one note can be associated with the same item or alert.
Once first created item info is unlikely to be updated by a user.
For arguments sake let's say that each user will create an average of 10 items, each item will have an average of 2 alerts associated with it. There will be an average of 2 notes per item/alert.
Very common queries that will be run:
1) Return all items created by a particular user with any associated alerts and notes. Given a user_id this query would span 3 tables
2) Checking each day for alerts that need to be sent to a user's email address. WHERE alert date==today, return user's email address, item name and any associated notes. This would require a query spanning 4 tables which is why I'm wondering if I need to take a different approach...
Option 1) one table to cover items, alerts and notes. user_id owner for each row. Every time you add a note to an item or alert you are repeating the alert and/or item info. Seems a bit wasteful but item and alert info won't be large.
Option 2) I don't foresee the need to query notes (famous last words?) so how about serializing note data so multiple notes are stored in one row in either the item or alert table (or just a combined alert/item table)
Option 3) Anything else you can think of? I'm asking this question as each option I've considered doesn't feel quite right.
I appreciate this is currently a small project and so performance shouldn't be of great concern and I should just go with the 4 tables. It's more that my common queries will end up being relatively complex that makes me think I need to re-evaluate the structure.
I would say that the common wisdom is to normalize to start and denormalize only when performance data suggest that it's necessary.
Make sure that your tables are indexed properly, with foreign key relationships for JOINs.
If you think you'll end up with a lot of data, this might be a good time to think about a partitioning strategy. Partitioning your fast-growing tables by time would be a good first step.
Four tables is not complex. I commonly write report queries that hit 15 or more tables in a database structure that has hundreds of tables (most with millions of records) and I wouldn't even say our dbs are anything more than medium sized (a typical db in our system might have around 200 gigs of data, so not large at all as databases go). Because they are properly indexed, they still run fast unless I am doing very complex calculations. Normalize, don't even consider denormalizing until you are an experienced database designer who knows better than to worry about the number of tables.
I have a question and I'm not sure about the best way to design it.
Basically, there are users. Each user can have a message box, and each box in turn can have several messages.
The problem is, is that there are some special message boxes, including "New," and "Trash." A user is required to have these two boxes.
I had some ideas about what could be done. One of my ideas was for each message box to have a field recording its type (enumeration of "new," "trash," or "other). But that doesn't force them to have those boxes, which I would prefer.
I could also have each user have fields specifically relating to their special boxes (so in the user table there would be fields like newBox and trashBox). Of course, if these are required, then the user and user_messageBox tables would be mutually related, which would cause obvious problems.
Then, I could make it many-to-many where the message box table doesn't relate to users, so there would be another table for relating these two as a many-to-many. But I don't want a many-to-many relationship, so it doesn't solve anything!
If you want just one message box per user, then call "new" and "trash" something else, like a state. Have this be a field of the message. (You'd also need a field for the user or equivalently the message box in each message as well.)
This gets you thinking outside of the box (!) and may give you other ideas as to how to use that field if you so choose: "Flagged," "important," "spam," etc.
Why dont u use a message_box_type field,.
I think you should force the users to have both the message box types using application logic.
Ideally there would be two tables, a messages table with a foreign key id message_box_id that links it to another table message_box. The message_box table in turn has a message_box_type field in addition to other fields. The application logic would make sure that two message_box records of the two types 'new' and 'trash' are created on user signup/creation