Testing DB and .....
in [Tables]
|
From: Terry Cano on 12 May 2010 23:25 I see two weakness in my db design. BTW I'm self taught so there are two I'm aware of and many I'm not. I make a folder for my test db I can only run so many scenerios and move the relationship around so many times...when do you know when to stop? I start with a list of what I think I will ever need. Level 1 Reports and QUERY that we will need on a daily or weekly bases Level 2 Predict what we may need six months + down the road Create the tables.....I then find that I'm looking at as many as six to ten tables that seems like a lot. I can use a switchboard to keep the form count down...so should I be thinking in that direction or ? ? ? ? ? Archview Apartments 126 units over 250 people all with 2 vehicles....so it isn't that big of a deal My other project is creating something for the recording studio. Here I'm dealing with clients and billing not many though. A ton of information on songs, sounds used instruments used plug ins...when and what was edited back up information, submission information, ISRC Codes....that could be six or so tables. Suggestions Thanks Terry
From: John W. Vinson on 13 May 2010 01:04 On Wed, 12 May 2010 20:25:01 -0700, Terry Cano <TerryCano(a)discussions.microsoft.com> wrote: >I see two weakness in my db design. BTW I'm self taught so there are two I'm >aware of and many I'm not. >I make a folder for my test db I can only run so many scenerios and move the >relationship around so many times...when do you know when to stop? I have no clue what you mean by "scenarios" or "move the relationship around". >I start with a list of what I think I will ever need. >Level 1 Reports and QUERY that we will need on a daily or weekly bases >Level 2 Predict what we may need six months + down the road >Create the tables.....I then find that I'm looking at as many as six to ten >tables >that seems like a lot. My animal shelter database currently has 105 tables. I know of many much larger databases. Six tables is TINY. >I can use a switchboard to keep the form count down...so should I be >thinking in that direction or ? ? ? ? ? A switchboard typically lets the user choose which (of many) forms or reports to open in a user friendly manner. It doesn't (by itself) keep the form count down; in fact a switchboard IS just another form. Again, I'm not sure what you're dealing with. >Archview Apartments >126 units over 250 people all with 2 vehicles....so it isn't that big of a >deal Ok, one table for units; a second table for people; a third table for vehicles; one or two more tables to model many to many relationshiips. You're making the assumption that we can see your table structure, or that you have communicated it somehow: neither assumption is correct! >My other project is creating something for the recording studio. Here I'm >dealing with clients and billing not many though. A ton of information on >songs, sounds used instruments used plug ins...when and what was edited back >up information, submission information, ISRC Codes....that could be six or so >tables. Or twelve or fifteen; so? You might want to see some of these resources to see how other folks design databases. Crystal's video might be a good start. If you're not comfortable with the concept of "Normalization" - learn it! >Suggestions Jeff Conrad's resources page: http://www.accessmvp.com/JConrad/accessjunkie/resources.html The Access Web resources page: http://www.mvps.org/access/resources/index.html Roger Carlson's tutorials, samples and tips: http://www.rogersaccesslibrary.com/ A free tutorial written by Crystal: http://allenbrowne.com/casu-22.html A video how-to series by Crystal: http://www.YouTube.com/user/LearnAccessByCrystal MVP Allen Browne's tutorials: http://allenbrowne.com/links.html#Tutorials -- John W. Vinson [MVP]
From: Terry Cano on 13 May 2010 16:01 Thanks John. for me "moving relationships" around means editing the relationships . U r right bout the switch board being another form ...I'll check out the links you have suggested....... seperate question is there a way to password protect the table? I left my asst with a data entry job, came back and she was working in the data sheet table view....I left the form openfor her, no idea how she got there but it isn't a good idea...I know that much "John W. Vinson" wrote: > On Wed, 12 May 2010 20:25:01 -0700, Terry Cano > <TerryCano(a)discussions.microsoft.com> wrote: > > >I see two weakness in my db design. BTW I'm self taught so there are two I'm > >aware of and many I'm not. > >I make a folder for my test db I can only run so many scenerios and move the > >relationship around so many times...when do you know when to stop? > > I have no clue what you mean by "scenarios" or "move the relationship around". > > >I start with a list of what I think I will ever need. > >Level 1 Reports and QUERY that we will need on a daily or weekly bases > >Level 2 Predict what we may need six months + down the road > >Create the tables.....I then find that I'm looking at as many as six to ten > >tables > >that seems like a lot. > > My animal shelter database currently has 105 tables. I know of many much > larger databases. Six tables is TINY. > > >I can use a switchboard to keep the form count down...so should I be > >thinking in that direction or ? ? ? ? ? > > A switchboard typically lets the user choose which (of many) forms or reports > to open in a user friendly manner. It doesn't (by itself) keep the form count > down; in fact a switchboard IS just another form. Again, I'm not sure what > you're dealing with. > > >Archview Apartments > >126 units over 250 people all with 2 vehicles....so it isn't that big of a > >deal > > Ok, one table for units; a second table for people; a third table for > vehicles; one or two more tables to model many to many relationshiips. You're > making the assumption that we can see your table structure, or that you have > communicated it somehow: neither assumption is correct! > > >My other project is creating something for the recording studio. Here I'm > >dealing with clients and billing not many though. A ton of information on > >songs, sounds used instruments used plug ins...when and what was edited back > >up information, submission information, ISRC Codes....that could be six or so > >tables. > > Or twelve or fifteen; so? > > You might want to see some of these resources to see how other folks design > databases. Crystal's video might be a good start. If you're not comfortable > with the concept of "Normalization" - learn it! > >Suggestions > > Jeff Conrad's resources page: > http://www.accessmvp.com/JConrad/accessjunkie/resources.html > > The Access Web resources page: > http://www.mvps.org/access/resources/index.html > > Roger Carlson's tutorials, samples and tips: > http://www.rogersaccesslibrary.com/ > > A free tutorial written by Crystal: > http://allenbrowne.com/casu-22.html > > A video how-to series by Crystal: > http://www.YouTube.com/user/LearnAccessByCrystal > > MVP Allen Browne's tutorials: > http://allenbrowne.com/links.html#Tutorials > > -- > > John W. Vinson [MVP] > . >
From: PieterLinden via AccessMonster.com on 13 May 2010 20:29 Terry Cano wrote: >I see two weakness in my db design. BTW I'm self taught so there are two I'm >aware of and many I'm not. >I make a folder for my test db I can only run so many scenerios and move the >relationship around so many times...when do you know when to stop? >I start with a list of what I think I will ever need. >Level 1 Reports and QUERY that we will need on a daily or weekly bases >Level 2 Predict what we may need six months + down the road >Create the tables.....I then find that I'm looking at as many as six to ten >tables >that seems like a lot. >I can use a switchboard to keep the form count down...so should I be >thinking in that direction or ? ? ? ? ? > >Archview Apartments >126 units over 250 people all with 2 vehicles....so it isn't that big of a >deal > >My other project is creating something for the recording studio. Here I'm >dealing with clients and billing not many though. A ton of information on >songs, sounds used instruments used plug ins...when and what was edited back >up information, submission information, ISRC Codes....that could be six or so >tables. > >Suggestions > >Thanks > >Terry Sorry, that's a bit of a "How long is a piece of string?" question... "Enough" tables is the right number to accurately describe all the "things" and relationships between things about the subject you're trying to model. Sometimes it's a pickup truck, sometimes it's a semi-trailer, sometimes it's in between. Before worrying about any of that, I would get out a pad of paper and describe (at least to yourself) the situation you are attempting to model. Once you have modeled the subject/situation and can figure out what tables you need to access to answer questions from your data, then you can start building. Building before you understand what the DB should do or how it will be used is asking for trouble. Just my two cents. -- Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/201005/1
From: Terry Cano on 14 May 2010 01:21 Yep that's what I do then I think of the relationships I need (many scenerios and move the relationship around) before I start the table. I'll get it eventually... "PieterLinden via AccessMonster.com" wrote: > Terry Cano wrote: > >I see two weakness in my db design. BTW I'm self taught so there are two I'm > >aware of and many I'm not. > >I make a folder for my test db I can only run so many scenerios and move the > >relationship around so many times...when do you know when to stop? > >I start with a list of what I think I will ever need. > >Level 1 Reports and QUERY that we will need on a daily or weekly bases > >Level 2 Predict what we may need six months + down the road > >Create the tables.....I then find that I'm looking at as many as six to ten > >tables > >that seems like a lot. > >I can use a switchboard to keep the form count down...so should I be > >thinking in that direction or ? ? ? ? ? > > > >Archview Apartments > >126 units over 250 people all with 2 vehicles....so it isn't that big of a > >deal > > > >My other project is creating something for the recording studio. Here I'm > >dealing with clients and billing not many though. A ton of information on > >songs, sounds used instruments used plug ins...when and what was edited back > >up information, submission information, ISRC Codes....that could be six or so > >tables. > > > >Suggestions > > > >Thanks > > > >Terry > > Sorry, that's a bit of a "How long is a piece of string?" question... > > "Enough" tables is the right number to accurately describe all the "things" > and relationships between things about the subject you're trying to model. > Sometimes it's a pickup truck, sometimes it's a semi-trailer, sometimes it's > in between. > > Before worrying about any of that, I would get out a pad of paper and > describe (at least to yourself) the situation you are attempting to model. > Once you have modeled the subject/situation and can figure out what tables > you need to access to answer questions from your data, then you can start > building. Building before you understand what the DB should do or how it > will be used is asking for trouble. Just my two cents. > > -- > Message posted via AccessMonster.com > http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/201005/1 > > . >
|
Next
|
Last
Pages: 1 2 Prev: Table design question Next: How do I record the date of the first record entry. |