A Beer Bottle Database Question - Newbie

[indyslim]

Hi,

Warning- Newbie

background:

I'm designing a database in FM7 to host my beer (bottle) collection. It is

currently a ragged excel file. After reading the FM7 tutorials and stumbling

along with the information on filemakermagazine.com, I am struggling with a

database design.

fact:

As we beer chuggers all know, a single brewer comes out with multiple beers, and

at times, the same beer gets a facelift and ends up with a new bottle design.

Database:

I have three separate tables each holding data about the "brewer", the "beer"

and the "bottle", repectively.

I have an id field (autoenter serial number) for each of the tables identifying

the brewer, beer and bottle.

Situtation:

I have entered the information for Budweiser (I am from St. Louis) along with

the brewer and beer information. My next bottle happens to be a Bud Light (both,

crappy beers) from the same brewer.

Question:

How do I go about entering the information about the brewer from a previous

record? The way, I want it to work is to enter the first few letters in a field

and the rest should be autocompleted.

Solutions:

1. I was looking through the database solutions that filemaker ships with the

FM7 application, in particular the one called "registration". Here, they make

you go to a list of previous records and then select the one you want. Is that

the way to go?

2. Or Should I just do away with multiple tables and have just one. This way, I

can just a select a previous record and then duplicate and edit in the new

information. Is there any practical advantage to having the data spread out into

multiple tables?

Thanks for your help and I promise to send you a finished version of the

database.

-Indy

[indyslim]

Hi,

Warning- Newbie

background:

I'm designing a database in FM7 to host my beer (bottle) collection. It is

currently a ragged excel file. After reading the FM7 tutorials and stumbling

along with the information on filemakermagazine.com, I am struggling with a

database design.

fact:

As we beer chuggers all know, a single brewer comes out with multiple beers, and

at times, the same beer gets a facelift and ends up with a new bottle design.

Database:

I have three separate tables each holding data about the "brewer", the "beer"

and the "bottle", repectively.

I have an id field (autoenter serial number) for each of the tables identifying

the brewer, beer and bottle.

Situtation:

I have entered the information for Budweiser (I am from St. Louis) along with

the brewer and beer information. My next bottle happens to be a Bud Light (both,

crappy beers) from the same brewer.

Question:

How do I go about entering the information about the brewer from a previous

record? The way, I want it to work is to enter the first few letters in a field

and the rest should be autocompleted.

Solutions:

1. I was looking through the database solutions that filemaker ships with the

FM7 application, in particular the one called "registration". Here, they make

you go to a list of previous records and then select the one you want. Is that

the way to go?

2. Or Should I just do away with multiple tables and have just one. This way, I

can just a select a previous record and then duplicate and edit in the new

information. Is there any practical advantage to having the data spread out into

multiple tables?

Thanks for your help and I promise to send you a finished version of the

database.

-Indy

[indyslim]

Hi,

Warning- Newbie

background:

I'm designing a database in FM7 to host my beer (bottle) collection. It is

currently a ragged excel file. After reading the FM7 tutorials and stumbling

along with the information on filemakermagazine.com, I am struggling with a

database design.

fact:

As we beer chuggers all know, a single brewer comes out with multiple beers, and

at times, the same beer gets a facelift and ends up with a new bottle design.

Database:

I have three separate tables each holding data about the "brewer", the "beer"

and the "bottle", repectively.

I have an id field (autoenter serial number) for each of the tables identifying

the brewer, beer and bottle.

Situtation:

I have entered the information for Budweiser (I am from St. Louis) along with

the brewer and beer information. My next bottle happens to be a Bud Light (both,

crappy beers) from the same brewer.

Question:

How do I go about entering the information about the brewer from a previous

record? The way, I want it to work is to enter the first few letters in a field

and the rest should be autocompleted.

Solutions:

1. I was looking through the database solutions that filemaker ships with the

FM7 application, in particular the one called "registration". Here, they make

you go to a list of previous records and then select the one you want. Is that

the way to go?

2. Or Should I just do away with multiple tables and have just one. This way, I

can just a select a previous record and then duplicate and edit in the new

information. Is there any practical advantage to having the data spread out into

multiple tables?

Thanks for your help and I promise to send you a finished version of the

database.

-Indy

[Ender]

I'd stick with the relational design, as it gives you more options and simplifies data entry. There's different user interfaces you could use for adding new records:

1. Enter data in each table separately, using value lists of Brewer and Beer where possible.

2. Going through a hierarchical group of data entry screens. To add Beers, you go the the Brewer layout and enter them in a portal. To add Bottles, you'd go to the Beer's Detail layout and enter Bottles in a portal.

3. Use the Brewer layout as the main data entry screen. You'd have both a Beer and a Bottle portal on the screen, where new Beers or Bottles would be entered. The Bottle portal would have a Beer field that could be defined as having a pop-up list of the Beers that this Brewer has.

I like option 3 the best, as everything can be seen from one screen. If you are tracking more than just a few fields about Beers and Bottles, then the space in the portal window may not be enough. In this case it may be better to do data entry using option 2 above, but still use an overview screen like in option 3.

[Ender]

I'd stick with the relational design, as it gives you more options and simplifies data entry. There's different user interfaces you could use for adding new records:

1. Enter data in each table separately, using value lists of Brewer and Beer where possible.

2. Going through a hierarchical group of data entry screens. To add Beers, you go the the Brewer layout and enter them in a portal. To add Bottles, you'd go to the Beer's Detail layout and enter Bottles in a portal.

3. Use the Brewer layout as the main data entry screen. You'd have both a Beer and a Bottle portal on the screen, where new Beers or Bottles would be entered. The Bottle portal would have a Beer field that could be defined as having a pop-up list of the Beers that this Brewer has.

I like option 3 the best, as everything can be seen from one screen. If you are tracking more than just a few fields about Beers and Bottles, then the space in the portal window may not be enough. In this case it may be better to do data entry using option 2 above, but still use an overview screen like in option 3.

[Ender]

I'd stick with the relational design, as it gives you more options and simplifies data entry. There's different user interfaces you could use for adding new records:

1. Enter data in each table separately, using value lists of Brewer and Beer where possible.

2. Going through a hierarchical group of data entry screens. To add Beers, you go the the Brewer layout and enter them in a portal. To add Bottles, you'd go to the Beer's Detail layout and enter Bottles in a portal.

3. Use the Brewer layout as the main data entry screen. You'd have both a Beer and a Bottle portal on the screen, where new Beers or Bottles would be entered. The Bottle portal would have a Beer field that could be defined as having a pop-up list of the Beers that this Brewer has.

I like option 3 the best, as everything can be seen from one screen. If you are tracking more than just a few fields about Beers and Bottles, then the space in the portal window may not be enough. In this case it may be better to do data entry using option 2 above, but still use an overview screen like in option 3.

[Zadkin]

Being lazy, I would go for a single table approach, close to the present Excel sheet. I suppose the Excel sheet has as only information of the brewer and the beer a name. Brewers can be set in a drop down list. The 'Contact Management.fp7' template shows ways to present related records in a single table, in this case brewer or beer, in a portal.

If the need arises extra tables can be created, although it is possible to avoid data replication even in a single table approach with the use of sorted portals.

[Zadkin]

Being lazy, I would go for a single table approach, close to the present Excel sheet. I suppose the Excel sheet has as only information of the brewer and the beer a name. Brewers can be set in a drop down list. The 'Contact Management.fp7' template shows ways to present related records in a single table, in this case brewer or beer, in a portal.

If the need arises extra tables can be created, although it is possible to avoid data replication even in a single table approach with the use of sorted portals.

[Zadkin]

Being lazy, I would go for a single table approach, close to the present Excel sheet. I suppose the Excel sheet has as only information of the brewer and the beer a name. Brewers can be set in a drop down list. The 'Contact Management.fp7' template shows ways to present related records in a single table, in this case brewer or beer, in a portal.

If the need arises extra tables can be created, although it is possible to avoid data replication even in a single table approach with the use of sorted portals.