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
Related
I am struggling with an issue in designing my Access database.
I am a caregiver, and part of my job is taking clients out into the community. I am attempting to build a catalog of outings to help the employees at our company come up with and store ideas for these. I want to store information for each of up to 5 types of events that clients can do at a location. That information includes the event type, when it runs and doesn't, and how much it'll cost, all of which would be user-selectable. (Separately in the same table, I want to include contact information and information that helps the user search for event locations, such as the ZIP code.) I have attempted to normalize the database by spreading event information across fields in the main table, linked to lookup tables. I am aware that Access has a limit of 32 relationships per table.
To help staff find event types, I am trying to set up a method for categorizing them. That requires setting up nested lookup tables, as shown in the first picture.
If I understand correctly, the additional "copies" of those lookup tables are aliases. When I save the setup for the relationships between those aliased lookup tables, close the Relationships window, and open it again, I find Access has changed them, as shown in the second picture. This happens whether I delete the lookup table information for each field in Datasheet View. I don't understand why it does this or how to fix it.
To answer your question:
In the object browser I see that you have only one table: t_OutingType. Therefore, the "tables" t_OutingType_2, t_OutingType_3 are just aliases; "pointers" to the same table (like a shortcut to a document). When you save the relationships and close the window, the relationship information is written to the metadata of the database. When you re-open the Relationships window Access re-builds the relationship diagram from the metadata, and it does not include the redundant aliases.
Additional advice:
Whenever you find yourself duplicating columns in a table, e.g., Event_1, Event_2, ... a little voice in your head should start shouting "Are you sure that's a good idea?" Imagine if you want to search the database for events that fall on a certain date. With the table layout described above you would need to ...
SELECT ... WHERE EventDate_1 = [theDate] OR EventDate_2 = [theDate] OR EventDate_3 = [theDate] ...
It's almost always better to split the Event information into a separate child table and maintain an association table between the child table and its parent.
Firstly, here is the relationship between the relevant tables.
I'm developing an Access frontend to serve as a CRUD for an underlying MySQL database, and I'm most of the way there for properly representing and interacting with the tables in a many-to-many relationship. I followed the instructions in this tutorial and my form is mostly functional. But the tutorial example is limited in that the third table in the relationship (in my case, Addresses) is static, and cannot be changed from the form.
Here's how my form looks currently. When adding a new entry in the people_has_addresses subform, if I wish to add an address which already exists in the addresses table by entering its ID into the addresses_addressID column, everything works. The rest of the columns automatically load in the address, and people_has_addresses automatically populates a new row with this unique combination of PersonID and AddressID. The problem comes when I want to create a new address on the fly, add it to the Addresses table, and populate people_has_addresses with this new combination. If I free-form type a new address into the subform and hit enter, I get the following error: "The Microsoft Access database engine cannot find a record in the table 'addresses' with key matching fields 'addresses_AddressID'."
My question is, what do I need to do in order to allow the creation of new rows in Addresses? Ideally working the way I describe above. I feel that I'm close to getting this right, but don't know what to do from here.
Ok, so the combo box in that row lets you select a given address. You not really described that if you have 10 address,which one you want to appear say in a mailing list or what not. What you could do is add an extra column to the table where you shove in (save) the address id, and add a "default" check box. Then you can have a query with the default Address column = true to only pull the one address for mailing etc. So in this example, I do have a check box to select which out of possible many address are to be used by default. And we could add another column for home, business, holiday location or whatever. That way you can categorize the address to what it is.
However, the issue and your question is of course how to add a new address?
There is as many ways to do this as their are flavors of ice cream. In other words, it up to your creative mind. One way would be to use the combo box not in list event. So if you typed in a address id that don't exist, you could be prompted to enter it. However, users should never have to see, know, or use some silly "id" during data entry. Users in fact should never even see PK or FK id's during use of the application.
I would suggest you next to the combo box that lets you select a address is place a button to add a new address. You could use a graphic image like a + sign. So, they can use the combo box to select an existing address, or click on on the + button to add a new address. What the code behind the button would do is launch a form to edit the address, but launch the form in add mode. And when you close/save the form, then the code could/would stuff in the PK id of the new address you just added into the FK Address_ID column for the address.
And in the interest of cruelty to animals and your users? They should not need to know or see or type in some "number". The combo box can hide the first PK column. So when you select a given address (in this example hotel, but it could be just a address) you display the name. So, users in place of expanding the combo box can just start typing in the hotel name. To be fair, with address, you really don't have a "name" to type in, so your case is somewhat different. In most cases the thing you are selecting has some name, or part name/number, or in our case a Hotel Name.
Note that the sub form is based on a query that joins in the other columns. So, when they crack open the combo box, they are in fact selecting a PK. So like magic (and without code), then the city,province, description columns automatic display from that other table.
So the form would look like this:
In above, we selected several hotels. However, note the check box as to which address to use, since we might have several, but for printing a letter or envelope, then the check box will determine which address will appear.
And in the above, if we don't find or have a Hotel (or address) we want to use, then we can hit the + sign beside the combo box. That would launch up a nice single form layout to enter a new Hotel (or address). As noted, how you setup your UI to work is quite much a open canvas. One great way to get ideas is to look at other software you use. So, how do you add multiple address to outlook users? So, a gazilion ways and ideas exist as to how you want to do this. It not really how to do this, but HOW YOU want this to work, since you can design this to your hearts content to work quite much anyway you want.
So, the PK id should not be exposed here. Users can't care or know about such things. I mean, as I am typing this response, no doubt the SQL server that drives stack overflow generated a new number for this post - but it not a user thing, only a developer thing to care about.
Ok, so we build that sub form. The table driving that sub form is only
ID (PK)
Customer_ID (FK to parent form driving this)
Hotel_ID (FK to hotel - or in your case address)
DefaultAddress (true/false column)
And as noted, we should add ONE MORE column that sets the address as the default address to use.
eg: default address.
. All of the other columns display as a result of a left join. (a left join for this sub form is VERY important).
Now, if a hotel is not in our list of choices, then the user can simply hit the + sign beside the combo box, and we pop up a nice form to edit/add a new hotel. And take well note that when you use outlook, an accounting system, or just about any software? You not seeing and typing in PK id values - that only really for you the developer to see, and end users should never see or have to deal with actual PK numbers.
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.
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.
I have a table, called Contracts, where I want to have a field that is an array of another table instances called Goods. Is there a way to do it through MS Access GUI?
Are arrays even a thing in RDBMS?
p.s. I am very new to databases, so sorry if it's a dumb question.
Relational datbases dont' work the way you are asking. You can't find a answer and soluion to your question becuase your question is all wrong, incorrect and ignores how databases work.
If you have some contacts in a table, and you want to attach some goods (say purchased), then you simply need to add a table called:
GoodsPurchased
You will relate that table to table contacts.
The relationship will look like this:
The result will be a table that looks like this:
Note that as a result of the relationship, the + sign that appears for each row.
If you click on the + sign, then you can add as many GoodsPurchased for one row (one Contact) as you want. This is the WHOLE essence of database systems, and why they are oh so often better then a spread sheet.
So, for each contact, you can add or "attach" as many goodsPurchased (the child table).
The result will look like this when you hit the + to expand the child table, and you can enter as many "things" for each contact.
in sql an array and a table are the same thing.
in the form you put the "array" table either as a:
*sub form bound to a table
*list box bound to a table
….technically you could also use a combobox…..
the presumption is the main form is bound to the main table.....the subform is inset into the main form while a list box is a control put onto the main form....
do it via forms rather than attempt to do at the table/field property level....