|
| If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|||||||
|
|
Thread Tools | Display Modes |
|
#1
October 29th, 2008, 04:21 PM
posted to microsoft.public.access.tablesdbdesign
|
|||
|
|||
Forecast Table
I would like to receive your feedback about my table design for forecast. The
forecast is set at product customer level. What do you think about the following table layout in Access 2003? ProductID CustomeID January February .... .... .... November December Year Thanks 
|
|
#2
October 29th, 2008, 04:48 PM
posted to microsoft.public.access.tablesdbdesign
|
|||
|
|||
|
Forecast Table
Is it possible to get a little more information, is this your only table?
What is the Primary Key for this table? Also, you shouldn't list your months like that. There should be a separate table for them that contains MonthID and Month... in the Month field is where you would put the data January, February, etc. -- Carrie "Mr.LuckyMe" wrote: I would like to receive your feedback about my table design for forecast. The forecast is set at product customer level. What do you think about the following table layout in Access 2003? ProductID CustomeID January February ... ... ... November December Year Thanks
|
|
#3
October 29th, 2008, 04:54 PM
posted to microsoft.public.access.tablesdbdesign
|
|||
|
|||
|
Forecast Table
Thank you for answer.
No, there are a lot more tables The Primary Key for this table is ProdCustId If I understood correct and as my forecast is in Kilograms, what you suggest is: ProdCustID ProductID CustomerID MonthID KG Year Thanks, "Sninkle" wrote: Is it possible to get a little more information, is this your only table? What is the Primary Key for this table? Also, you shouldn't list your months like that. There should be a separate table for them that contains MonthID and Month... in the Month field is where you would put the data January, February, etc. -- Carrie "Mr.LuckyMe" wrote: I would like to receive your feedback about my table design for forecast. The forecast is set at product customer level. What do you think about the following table layout in Access 2003? ProductID CustomeID January February ... ... ... November December Year Thanks
|
|
#4
October 29th, 2008, 05:11 PM
posted to microsoft.public.access.tablesdbdesign
|
|||
|
|||
|
Forecast Table
Sorry, but the primary key for the previous mentioned table is:
FcstKgID NOT ProdCustID Thanks "Mr.LuckyMe" wrote: Thank you for answer. No, there are a lot more tables The Primary Key for this table is ProdCustId If I understood correct and as my forecast is in Kilograms, what you suggest is: ProdCustID ProductID CustomerID MonthID KG Year Thanks, "Sninkle" wrote: Is it possible to get a little more information, is this your only table? What is the Primary Key for this table? Also, you shouldn't list your months like that. There should be a separate table for them that contains MonthID and Month... in the Month field is where you would put the data January, February, etc. -- Carrie "Mr.LuckyMe" wrote: I would like to receive your feedback about my table design for forecast. The forecast is set at product customer level. What do you think about the following table layout in Access 2003? ProductID CustomeID January February ... ... ... November December Year Thanks
|
|
#5
October 29th, 2008, 06:02 PM
posted to microsoft.public.access.tablesdbdesign
|
|||
|
|||
|
Forecast Table
I would not create months as fields. Try:
ProdCustMthID ProductID CustomerID ForecastMonthNumber ForecastYear ForecastKG You could also combine the month and year into a single date field. This would allow you to create forecasts by week if needed. -- Duane Hookom Microsoft Access MVP "Mr.LuckyMe" wrote: Sorry, but the primary key for the previous mentioned table is: FcstKgID NOT ProdCustID Thanks "Mr.LuckyMe" wrote: Thank you for answer. No, there are a lot more tables The Primary Key for this table is ProdCustId If I understood correct and as my forecast is in Kilograms, what you suggest is: ProdCustID ProductID CustomerID MonthID KG Year Thanks, "Sninkle" wrote: Is it possible to get a little more information, is this your only table? What is the Primary Key for this table? Also, you shouldn't list your months like that. There should be a separate table for them that contains MonthID and Month... in the Month field is where you would put the data January, February, etc. -- Carrie "Mr.LuckyMe" wrote: I would like to receive your feedback about my table design for forecast. The forecast is set at product customer level. What do you think about the following table layout in Access 2003? ProductID CustomeID January February ... ... ... November December Year Thanks
|
|
#6
October 29th, 2008, 07:37 PM
posted to microsoft.public.access.tablesdbdesign
|
|||
|
|||
|
Forecast Table
Duane,
Could you please elaborate on how combining the month and year would be usefull for creating weekly forecasts Thanks "Duane Hookom" wrote: I would not create months as fields. Try: ProdCustMthID ProductID CustomerID ForecastMonthNumber ForecastYear ForecastKG You could also combine the month and year into a single date field. This would allow you to create forecasts by week if needed. -- Duane Hookom Microsoft Access MVP "Mr.LuckyMe" wrote: Sorry, but the primary key for the previous mentioned table is: FcstKgID NOT ProdCustID Thanks "Mr.LuckyMe" wrote: Thank you for answer. No, there are a lot more tables The Primary Key for this table is ProdCustId If I understood correct and as my forecast is in Kilograms, what you suggest is: ProdCustID ProductID CustomerID MonthID KG Year Thanks, "Sninkle" wrote: Is it possible to get a little more information, is this your only table? What is the Primary Key for this table? Also, you shouldn't list your months like that. There should be a separate table for them that contains MonthID and Month... in the Month field is where you would put the data January, February, etc. -- Carrie "Mr.LuckyMe" wrote: I would like to receive your feedback about my table design for forecast. The forecast is set at product customer level. What do you think about the following table layout in Access 2003? ProductID CustomeID January February ... ... ... November December Year Thanks
|
|
#7
October 29th, 2008, 08:22 PM
posted to microsoft.public.access.tablesdbdesign
|
|||
|
|||
|
Forecast Table
If you are storing the month and year in two fields in your table, you are
limiting your granularity to monthly forecasts. If your field is a date type, you could enter values like: 10/5/2008 10/12/2008 10/19/2008 10/26/2008 This would allow you to create 4 forecast values in October 2008 and generally 52 in a year. You could still enter values like: 10/1/2008 11/1/2008 12/1/2008 if your forecasts are monthly. -- Duane Hookom Microsoft Access MVP "Mr.LuckyMe" wrote: Duane, Could you please elaborate on how combining the month and year would be usefull for creating weekly forecasts Thanks "Duane Hookom" wrote: I would not create months as fields. Try: ProdCustMthID ProductID CustomerID ForecastMonthNumber ForecastYear ForecastKG You could also combine the month and year into a single date field. This would allow you to create forecasts by week if needed. -- Duane Hookom Microsoft Access MVP "Mr.LuckyMe" wrote: Sorry, but the primary key for the previous mentioned table is: FcstKgID NOT ProdCustID Thanks "Mr.LuckyMe" wrote: Thank you for answer. No, there are a lot more tables The Primary Key for this table is ProdCustId If I understood correct and as my forecast is in Kilograms, what you suggest is: ProdCustID ProductID CustomerID MonthID KG Year Thanks, "Sninkle" wrote: Is it possible to get a little more information, is this your only table? What is the Primary Key for this table? Also, you shouldn't list your months like that. There should be a separate table for them that contains MonthID and Month... in the Month field is where you would put the data January, February, etc. -- Carrie "Mr.LuckyMe" wrote: I would like to receive your feedback about my table design for forecast. The forecast is set at product customer level. What do you think about the following table layout in Access 2003? ProductID CustomeID January February ... ... ... November December Year Thanks
|
|
#8
October 29th, 2008, 10:18 PM
posted to microsoft.public.access.tablesdbdesign
|
|||
|
|||
|
Forecast Table
Duane,
Thank you for your answer. In my business case the forecast is kept at monthly level. Do you think is better to have month and year in two fields or just one? Thanks, "Duane Hookom" wrote: If you are storing the month and year in two fields in your table, you are limiting your granularity to monthly forecasts. If your field is a date type, you could enter values like: 10/5/2008 10/12/2008 10/19/2008 10/26/2008 This would allow you to create 4 forecast values in October 2008 and generally 52 in a year. You could still enter values like: 10/1/2008 11/1/2008 12/1/2008 if your forecasts are monthly. -- Duane Hookom Microsoft Access MVP "Mr.LuckyMe" wrote: Duane, Could you please elaborate on how combining the month and year would be usefull for creating weekly forecasts Thanks "Duane Hookom" wrote: I would not create months as fields. Try: ProdCustMthID ProductID CustomerID ForecastMonthNumber ForecastYear ForecastKG You could also combine the month and year into a single date field. This would allow you to create forecasts by week if needed. -- Duane Hookom Microsoft Access MVP "Mr.LuckyMe" wrote: Sorry, but the primary key for the previous mentioned table is: FcstKgID NOT ProdCustID Thanks "Mr.LuckyMe" wrote: Thank you for answer. No, there are a lot more tables The Primary Key for this table is ProdCustId If I understood correct and as my forecast is in Kilograms, what you suggest is: ProdCustID ProductID CustomerID MonthID KG Year Thanks, "Sninkle" wrote: Is it possible to get a little more information, is this your only table? What is the Primary Key for this table? Also, you shouldn't list your months like that. There should be a separate table for them that contains MonthID and Month... in the Month field is where you would put the data January, February, etc. -- Carrie "Mr.LuckyMe" wrote: I would like to receive your feedback about my table design for forecast. The forecast is set at product customer level. What do you think about the following table layout in Access 2003? ProductID CustomeID January February ... ... ... November December Year Thanks
|
|
#9
October 29th, 2008, 10:26 PM
posted to microsoft.public.access.tablesdbdesign
|
|||
|
|||
|
Forecast Table
I would use a single date field. If you want this represented as year and
month, you can always calculate these from the forecast date ie: ForeCastMth: Month([ForecastDate]) ForeCastYr: Year([ForecastDate]) -- Duane Hookom Microsoft Access MVP "Mr.LuckyMe" wrote: Duane, Thank you for your answer. In my business case the forecast is kept at monthly level. Do you think is better to have month and year in two fields or just one? Thanks, "Duane Hookom" wrote: If you are storing the month and year in two fields in your table, you are limiting your granularity to monthly forecasts. If your field is a date type, you could enter values like: 10/5/2008 10/12/2008 10/19/2008 10/26/2008 This would allow you to create 4 forecast values in October 2008 and generally 52 in a year. You could still enter values like: 10/1/2008 11/1/2008 12/1/2008 if your forecasts are monthly. -- Duane Hookom Microsoft Access MVP "Mr.LuckyMe" wrote: Duane, Could you please elaborate on how combining the month and year would be usefull for creating weekly forecasts Thanks "Duane Hookom" wrote: I would not create months as fields. Try: ProdCustMthID ProductID CustomerID ForecastMonthNumber ForecastYear ForecastKG You could also combine the month and year into a single date field. This would allow you to create forecasts by week if needed. -- Duane Hookom Microsoft Access MVP "Mr.LuckyMe" wrote: Sorry, but the primary key for the previous mentioned table is: FcstKgID NOT ProdCustID Thanks "Mr.LuckyMe" wrote: Thank you for answer. No, there are a lot more tables The Primary Key for this table is ProdCustId If I understood correct and as my forecast is in Kilograms, what you suggest is: ProdCustID ProductID CustomerID MonthID KG Year Thanks, "Sninkle" wrote: Is it possible to get a little more information, is this your only table? What is the Primary Key for this table? Also, you shouldn't list your months like that. There should be a separate table for them that contains MonthID and Month... in the Month field is where you would put the data January, February, etc. -- Carrie "Mr.LuckyMe" wrote: I would like to receive your feedback about my table design for forecast. The forecast is set at product customer level. What do you think about the following table layout in Access 2003? ProductID CustomeID January February ... ... ... November December Year Thanks
|
|
#10
October 29th, 2008, 11:26 PM
posted to microsoft.public.access.tablesdbdesign
|
|||
|
|||
|
Forecast Table
Duane,
Thank you very much for your help "Duane Hookom" wrote: I would use a single date field. If you want this represented as year and month, you can always calculate these from the forecast date ie: ForeCastMth: Month([ForecastDate]) ForeCastYr: Year([ForecastDate]) -- Duane Hookom Microsoft Access MVP "Mr.LuckyMe" wrote: Duane, Thank you for your answer. In my business case the forecast is kept at monthly level. Do you think is better to have month and year in two fields or just one? Thanks, "Duane Hookom" wrote: If you are storing the month and year in two fields in your table, you are limiting your granularity to monthly forecasts. If your field is a date type, you could enter values like: 10/5/2008 10/12/2008 10/19/2008 10/26/2008 This would allow you to create 4 forecast values in October 2008 and generally 52 in a year. You could still enter values like: 10/1/2008 11/1/2008 12/1/2008 if your forecasts are monthly. -- Duane Hookom Microsoft Access MVP "Mr.LuckyMe" wrote: Duane, Could you please elaborate on how combining the month and year would be usefull for creating weekly forecasts Thanks "Duane Hookom" wrote: I would not create months as fields. Try: ProdCustMthID ProductID CustomerID ForecastMonthNumber ForecastYear ForecastKG You could also combine the month and year into a single date field. This would allow you to create forecasts by week if needed. -- Duane Hookom Microsoft Access MVP "Mr.LuckyMe" wrote: Sorry, but the primary key for the previous mentioned table is: FcstKgID NOT ProdCustID Thanks "Mr.LuckyMe" wrote: Thank you for answer. No, there are a lot more tables The Primary Key for this table is ProdCustId If I understood correct and as my forecast is in Kilograms, what you suggest is: ProdCustID ProductID CustomerID MonthID KG Year Thanks, "Sninkle" wrote: Is it possible to get a little more information, is this your only table? What is the Primary Key for this table? Also, you shouldn't list your months like that. There should be a separate table for them that contains MonthID and Month... in the Month field is where you would put the data January, February, etc. -- Carrie "Mr.LuckyMe" wrote: I would like to receive your feedback about my table design for forecast. The forecast is set at product customer level. What do you think about the following table layout in Access 2003? ProductID CustomeID January February ... ... ... November December Year Thanks
|
| Thread Tools | |
| Display Modes | |
|
|
Linear Mode
