I have a three tables - for simplicity let's call them - meat, dish, and order. In the meat table, there are different types of meat; in the dish table, there are different types of dishes you can prepare with those types of meats; in the orders table, the orders for these dishes are shown. The orders table has OrderID, MeatID, DishID.
I'm trying to make it so in the Design View on Microsoft Access when the drop menu displays all the types of meat in the MeatID column and chooses one, the other drop down menu in the DishID column will only display the types of dishes in relation with the meat
If so, is there a way to make Access automatically know using this code:
SELECT Meat.MeatName, Dish.DishName
FROM Dish
INNER JOIN Meat ON Meat.MeatID = Dish.MeatID
WHERE MeatID = [the selected meat in the previous column]
You can use the Meat combobox value as criterium, like this:
WHERE MeatID = Forms!yourFormName!cboMeat
Additionally, in the AfterUpdate event of cboMeat you need:
Me.cboDish.Requery
so it will read the dishes to the newly selected meat.
For more examples, search for: access linked combo boxes
It's a very common (and useful) technique.
Related
So I have a Query with a list of "Items" Say 'APPLE', 'Carrot', and 'Pear', and a field beside it called "Quantity". On a another table I have a column with a field called "Item", then beside it a field with "cost". (Thus to show the item and its cost.) What I want to do is search the list for the item then take that item and times the price by the quantity, and show it on the chart.
Let's also assume that in the table of items that some of the spelling is not exact so one person may have typed apple and another apples, but in my item column it just says Apple, how do I make sure that they will find each other or the closest match on the list?
I have done a little work and I assume I have to create a join of some sort, but I am not sure of the expression to do the paring or the prices with the items once that is done a simple multiplication expression can be done.
You are right that you will need to perform a JOIN between the two tables/queries to match up the rows that correspond to each other ("apples to apples", so to speak). If your first table/query was called [Orders] and your second table/query was called [Prices] then a simple query to "do the math" would be something like
SELECT
Orders.Item,
Orders.Quantity,
Prices.Price,
Orders.Quantity * Prices.Price AS Cost
FROM
Orders
INNER JOIN
Prices
ON Orders.Item = Prices.Item
Regarding your point...
Lets also assume that in the table of items that some of the spelling
is not exact so one person may have typed apple and another apples,
but in my item column it just says Apple, how do I make sure that they
will find each other
...the short answer is: You design your database in such a way that such discrepancies cannot occur. Use your favorite Internet search engine to do some research on the following topics:
Data Validation
Referential Integrity
Edit re: comment
I was just wondering if I could use a Like function with % sign of some sort to search for the closest answer to solve the [matching] problem
Generally speaking, no. Those types of approaches can be very difficult to implement reliably (think "apples" vs. "pineapples") and can be very difficult to audit if incorrect matching occurs.
If you have dirty data then you're most likely just going to have to get busy and clean it up.
I have 1-to-1 relation between Supplier and Country tables. I need to create a form so I can edit all the fields of Supplier and Country tables. So far it's possible to edit all fields of Supplier but there is only a option list of countries I can select from (but not add one).
You can probably get away with it by setting the Limit To List property to "No", and then maybe checking the field to see if it exists in the Country table and, if not, adding it before you continue processing the form. A bit unorthodox, but do-able.
I am new to symfony and PHP.
I have a problem that I hope someone can help:
supose we have 3 entities.
Groups, specialities, works; works belong to a speciality, speciality belong to a group.
Supose that I want to have a form to create a "work". I want to filter my specialities according to a select with the list of groups ( much like on a travel site where we get the destinations filtered by the origin).
So my form will only have 2 fields. The speciality and a name for the work. But in my view i must have 3 fields, 1 for groups that will filter the specialities and the fields belonging to the form.
Much like a booking flights site I must see the fields from the begining.
This as to be so simple, but I'm really stuck on it.
Thank you
At this moment I can come up with 2 solutions:
1) Use ajax.
On the request populate a selectbox with the groups. when you select one of the groups, all the specialities come into a different selectbox of that group.
2)
Use uri segments. Let the user first choose group, then go to a next page and let them choose a speciality. After that the user gets a form where he fills in the data.
I have the following parent <-> child datamodel:
(almost every line is a table, indented means child-of)
consumerGoods
food
meat
item
fruit
item
vegetable
item
The child-items of meat, fruit and vegetables are in the same table (named items) because they have identical attributes. In the items table I have fields that describes the parent and the parentId.
So an item record could be:
id:1
parentType:meat
parentId:4
price:3.25
expDate:2009-12-31
description:bacon
I'm now building a full text MySQL search for the contents of the description field in "items", but I also want each result to have the information of its parent table, so a "bacon-item" has the data that's in its parent record. I also want each returned result to have data that is in the parent food record and the parent consumerGoods record.
I've got the following query now, but I don't know how to join based on the value of a field in a record, or if that's even possible.
SELECT
*
FROM
item
WHERE MATCH
(description
AGAINST
('searchKey')
One way to do this is is to do multiple queries for each matching "item" record, but if I had a lot of results that would be a lot of queries and would also slow down any filtering I'd want to do for facet-based searching. Another option is to make a new table that contains all the parent item info for each item record and search through that, but then I'd have to constantly update that table if I add item records, which is redundant and quite some work.
I'd like to hear it if I'm thinking in the right direction, or if I'm totally misguided. Any suggestions welcome.
As a general rule of thumb your database structure should contain data, but should not itself be data. A sign that you're breaking this is when you feel that you have to join to a different table based on the data you're reading from some other table. At that point you need to back up and consider your overall data model because odds are very good that you're doing something not quite right.
You could join against a subquery containing the union of all parent types:
select *
from item
left join (
select 'meat' as type, Redness, '' as Ripeness from meat
union all
select 'fruit' as type, -1 as Redness, Ripeness from fruit
union all
select 'vegetable' as type, -1 as Redness, Ripeness from vegetable
) parent on parent.type = item.parentType
But if you can, redesign the database. Instead of the complex model, change it to one table of Items and one table of Categories. The categories should contain one row for meat, one for fruit, and one for vegetables.
Since your example is contrived, it's difficult to know what the actual information requirements are in your case. Damir's diagram shows you the correct way to model PKs and FKs when you have a super-type sub-type relationships.
This situation is one case of a pattern called "generalization-specialization". Almost any treatment of object modeling will deal with generalization-specialization, although it may use different terminology. However, if you want to find articles that help you build a relational database that uses specialization-generalization, search for "generalization specialization relational modeling".
The best of the articles will start by teaching you the same concept that Damir's response illustrated for you. From there, you will learn how to create queries and views that can search for either all kinds of items, or for particular kinds of items, if you know what you are searching for.
A sample view follows:
create view FruitItems as
select
c.ConsumerGoodsID,
Price,
Description,
ConsumerGoodType,
ExpiryDate,
FoodType,
IsTropic
from
ConsumerGoods c
INNER JOIN Food f on f.ConsumerGoodsID = c.ConsumerGoodsID
INNER JOIN Fruit fr on fr.ConsumerGoodsID = c.ConsumerGoodsID
Similarly, you could create views for VegetableItems, MeatItems, and HouseSupplyItems, and even one large view, namely Items, that's the union of each of the specialized views.
In the Items view IsTropic would be true for all tropical fruits, false for all non tropical fruits, and null for Meats, Vegetables, and HouseSupplies. I'm not going to show you the entire Item view for a contrived case, but you get the idea. Especially if you read the best of the articles on relational modeling of this pattern.
The Items view might be a little slow, but it could come in handy when you really don't know any better way to search. And if you search for Istropic = True, you'll automatically exclude all the Meats, Vegetables, and HouseSupplies.
As #Andomar suggested, the design is a bit off; having "multiple parent tables" does not map to DB foreign keys concept. Here is one possible suggestion. This one uses two levels of super-type/subtype relationships. Super-type table contains columns specific to all subtypes (categories), while subtype tables contain columns specific only to the category.
I hope I can explain this clearly. I have a table, lets call it Widgets, that contains information (Color, Size, etc) about many many different widgets that are specified by an ID# which is the primary key. I also have a table, call it Tests, that is related to Widgets through a one to many relationship. Each row in this table represents a test on a particular widget and has information like WidgetID, Date, Info1, Info2, etc. Each WidgetID may have multiple tests in the table Tests. What I'm doing with these is simply displaying various reports that contain data from both tables based on various queryies. I do not have write privileges to either of these two tables.
Ok now that that is set up here is what I want to do. I'd like to set up a new table that contains a correlation between the Color of a widget and a new piece of data that I'll call Group. In short, I'd like to be able to define "Groups" of widgets where all the blue, green, and red widgets would be in one group and all of the yellow and orange widgets in another group, etc. (there is no overlap...ie each color correpsonds to only one group) I also want to set up forms that allow the user to add a Group and define which colors go in it, delete a Group, or edit a Group (truthfully add and delete would be enough).
What is the best way to do this? I'm not necessarily looking for code, but more so just direction. The best situation would be if each widget had a column in the Widgets table that contained the Groups data, but I do not have write access and neither will the users and I would like to make the Group data editable by the user.
It should be simple enough to set up a table:
Colour
Group
Users add data via a form by selecting the colour from the list and either entering a new or existing group. The whole thing should be possible without any coding, only wizards.
The new table is then joined to widgets on colour to create the various reports that you require.
EDIT re Comments
How you set up the table depends on the results you want returned, let us say that only the colours that are in groups are included, and we have this SQL to join to the widgets table:
SELECT WidgetID, GroupID FROM Widgets
INNER JOIN GroupColour
ON Widgets.Colour=GroupColour.Colour
Only the widgets that have a colour that is listed in the GroupColour table will be included in the listing, this is because of INNER JOIN. If the SQL was:
SELECT WidgetID, GroupID FROM Widgets
LEFT JOIN GroupColour
ON Widgets.Colour=GroupColour.Colour
You would get all widgets returned, but a Null for GroupID when there was no match in GroupColour. This can be quite useful.
You may wish to read http://www.devshed.com/c/a/MySQL/Understanding-SQL-Joins/, which is about MySQL, but works quite well for Jet SQL.