A Microsoft Office (Excel, Word) forum. OfficeFrustration

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.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Testing DB and .....



 
 
Thread Tools Display Modes
  #1  
Old May 13th, 2010, 04:25 AM posted to microsoft.public.access.tablesdbdesign
Terry Cano
external usenet poster
 
Posts: 12
Default Testing DB and .....

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
Ads
  #2  
Old May 13th, 2010, 06:04 AM posted to microsoft.public.access.tablesdbdesign
John W. Vinson
external usenet poster
 
Posts: 18,261
Default Testing DB and .....

On Wed, 12 May 2010 20:25:01 -0700, 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 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/acc...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]
  #3  
Old May 13th, 2010, 09:01 PM posted to microsoft.public.access.tablesdbdesign
Terry Cano
external usenet poster
 
Posts: 12
Default Testing DB and .....

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
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/acc...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]
.

  #4  
Old May 14th, 2010, 01:29 AM posted to microsoft.public.access.tablesdbdesign
PieterLinden via AccessMonster.com
external usenet poster
 
Posts: 307
Default Testing DB and .....

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/For...esign/201005/1

  #5  
Old May 14th, 2010, 06:21 AM posted to microsoft.public.access.tablesdbdesign
Terry Cano
external usenet poster
 
Posts: 12
Default Testing DB and .....

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/For...esign/201005/1

.

  #6  
Old May 14th, 2010, 08:03 PM posted to microsoft.public.access.tablesdbdesign
John W. Vinson
external usenet poster
 
Posts: 18,261
Default Testing DB and .....

On Thu, 13 May 2010 22:21:01 -0700, Terry Cano
wrote:

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.


Don't get too hung up on the "scenarios" (different kinds of data display I'm
guessing).

Instead, think about the Entities - real-life people, things or events -
represented by your database. Each kind of Entity gets its own table. For
example a Customer is one kind of entity; a Product is another; a Sale is yet
another.

Then identify how the tables representing these entities are related:

Each Customer may have zero, one or many Sales
Each Product may have zero, one, or many Sales
Each Sale involves one and only one Customer and one or more Products

--

John W. Vinson [MVP]
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 08:31 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Copyright 2004-2019 OfficeFrustration.
The comments are property of their posters.