Multiple Database Question

[Guest]

Hi,

I'm currently creating multiple access databases. I really cannot explain
the database in full beacuse the information is private, but I can tell you
its based on software versions.. So, my question is... Would it be better
to create multiple databases for each version or is there a better way?

Thanks in advance!

 

[Tony Toews]

I'm currently creating multiple access databases. I really cannot explain
the database in full beacuse the information is private, but I can tell you
its based on software versions.. So, my question is... Would it be better
to create multiple databases for each version or is there a better way?

What kind of software versions? Please expand on that a bit more.
What is the problem?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Joseph Meehan]

Hi,

I'm currently creating multiple access databases. I really cannot
explain the database in full beacuse the information is private, but
I can tell you its based on software versions.. So, my question
is... Would it be better to create multiple databases for each
version or is there a better way?

Thanks in advance!

Sorry, but that is not nearly enough information. Change the names to
protect the innocent (or guilty) and give us some idea of the data and what
you want to do with it.

For example one field with a number in it and another with a date and a
third with a name and you want to track the numbers by date and name.

 

[Guest]

What kind of software versions? Please expand on that a bit more.
What is the problem?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

As I said earlier the information is private so I really cannot explain.
Well software has versions like 1.0, 1.1, 1.2, etc... And someone suggested
that I create multiple databases; one for each version. However, As I do
this I'm finding there is a lot of duplicate data throughout the multiple
database, thus using valuabe space and wasting my valueable time.. I was
wondering if there was a way to design a more efficent database that would be
able to house software information, specs, reports, parameters, etc.. without
creating multiple databases.

 

[Guest]

Sorry, but that is not nearly enough information. Change the names to
protect the innocent (or guilty) and give us some idea of the data and what
you want to do with it.

For example one field with a number in it and another with a date and a
third with a name and you want to track the numbers by date and name.

I apologize about being so general. I'm also a student intern so give me a
little break.. Anyway here goes nothing.. Our company develops software
for medical purposes(hospitals). So we have Crystal Reports, Specs that
explain what you can use the Crystal reports to do, and the parameters the
Crystal Reports have.. I am trying to figure out how to best design my
tables and relationships. It was suggested to me to create a database for
each software version, but only few things change in the software each
version release.. So, I was wondering if there was an alternate way to
create one big database... What I was thinking was creating a Version_Tbl
that would link to all the Specs.. If this does not help I just forget about
it.. I will figure something out.. Thanks though for trying to understand
me!!!

 

[John Vinson]

I was
wondering if there was a way to design a more efficent database that would be
able to house software information, specs, reports, parameters, etc.. without
creating multiple databases.

Absolutely. You do NOT want to store information in database names,
table names, or field names - you want to store data IN TABLES.

One database.

As many tables as you have kinds of entities (real-life persons,
things or events of importance to your application).

I'd expect you would have a table of Programs (or Applications),
related one-to-many to a table of Versions; a table of Specs, related
in some way which you would know better than I; and so on.

I'd suggest you read up on the topic of "Normalization" to get
started. There's a lot of good links at

http://home.bendbroadband.com/conradsystems/accessjunkie/resources.html

especially the Database Design 101 links.

John W. Vinson[MVP]

 

[Smartin]

I apologize about being so general. I'm also a student intern so give me a
little break.. Anyway here goes nothing.. Our company develops software
for medical purposes(hospitals). So we have Crystal Reports, Specs that
explain what you can use the Crystal reports to do, and the parameters the
Crystal Reports have.. I am trying to figure out how to best design my
tables and relationships. It was suggested to me to create a database for
each software version, but only few things change in the software each
version release.. So, I was wondering if there was an alternate way to
create one big database... What I was thinking was creating a Version_Tbl
that would link to all the Specs.. If this does not help I just forget about
it.. I will figure something out.. Thanks though for trying to understand
me!!!

No need to divulge confidential information. You can easily substitute
books, employees, or something else for your software.

Heed the advise of the database gurus here and read up a little on
normalization. Think, "software has versions, versions have specs", etc.
These are relationships. This will undoubtedly lead you to the finding
that you can store all this in one well designed set of tables in a
single database.

I have personally witnessed a prevalent mode of thinking from execs to
store similar data in separate tables that changes only from year to
year, person to person, version to version, etc. This is "excel mode".
They do not comprehend normalization. Break out of duplication, discover
normalization. It can be quite enlightening.

 

[Joseph Meehan]

I apologize about being so general. I'm also a student intern so
give me a little break.. Anyway here goes nothing.. Our company
develops software for medical purposes(hospitals). So we have
Crystal Reports, Specs that explain what you can use the Crystal
reports to do, and the parameters the Crystal Reports have.. I am
trying to figure out how to best design my tables and relationships.
It was suggested to me to create a database for each software
version, but only few things change in the software each version
release.. So, I was wondering if there was an alternate way to
create one big database... What I was thinking was creating a
Version_Tbl that would link to all the Specs.. If this does not help
I just forget about it.. I will figure something out.. Thanks
though for trying to understand me!!!

Let me guess a little. You want to keep track of the changes in a
software product by version?

Are there groupings of the type of changes?

I really doubt if you want to have a new database for each version.
That sounds like a spreadsheet person talking.

I have not worked directly with Crystal reports, but my girlfriend does
and it seems to be a good product for what it does.

 

[Tony Toews]

As I said earlier the information is private so I really cannot explain.

With all due respect the description of the data can hardly be all
that private. There is really nothing new in the database world.

Well software has versions like 1.0, 1.1, 1.2, etc... And someone suggested
that I create multiple databases; one for each version. However, As I do
this I'm finding there is a lot of duplicate data throughout the multiple
database, thus using valuabe space and wasting my valueable time.. I was
wondering if there was a way to design a more efficent database that would be
able to house software information, specs, reports, parameters, etc.. without
creating multiple databases.

Ah, so the data describes software versions. Than as John Vinson
states the version number should be a field in the tables.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Tony Toews]

I apologize about being so general. I'm also a student intern so give me a
little break.. Anyway here goes nothing.. Our company develops software
for medical purposes(hospitals). So we have Crystal Reports, Specs that
explain what you can use the Crystal reports to do, and the parameters the
Crystal Reports have.. I am trying to figure out how to best design my
tables and relationships. It was suggested to me to create a database for
each software version, but only few things change in the software each
version release.. So, I was wondering if there was an alternate way to
create one big database... What I was thinking was creating a Version_Tbl
that would link to all the Specs..

Good description of the problem. Yup, you are correct. A version
table should link to the specs.

Note that I see no reasons to include _Tbl as part of the table name.
Nor do I ever see any reason to put qry, frm or rpt as either a prefix
or suffix to an object name. Waste of time and you can't use a letter
to quickly go to where you want if they are a prefix that is. That is
at the database object window you wouldn't be able to hit the letter p
to go to the purchasing forms.

Tony's Table and Field Naming Conventions
http://www.granite.ab.ca/access/tablefieldnaming.htm

Tony

--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm