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
|
|||
|
|||
Database Design Process Questions
I think this is appropriate for this group, so here goes:
I'm creating my first access database for my job. It is a computer/software catalog where I want to keep track of about 20-30 computers and servers, the software they currently have installed on them, when the software was installed, the specifications of the individual computers, network information for the computers and servers, and a catalog of all the software and licenses we have available. I know this has been done before, but they're paying me to do so I figure "Get paid to learn? Sure!" My question is this: What is good practice for table layout? Should I make one large table with ALL network/hardware/software information? Or break the tables up as small as possible? I'm leaning towards breaking them up into small tables because I have many canidates for primary key for each table(ip address, hostname, inventory#, license#, primary user). Any suggestions/tips would be appreciated. |
#2
|
|||
|
|||
Database Design Process Questions
you don't want to repeat multiple entries of the same data...
so I think you would have a hardware table that lists each physical server/desktop and you would have a software table that lists each type of software and then a third table that cross references between the two and has specific license # -- NTC " wrote: I think this is appropriate for this group, so here goes: I'm creating my first access database for my job. It is a computer/software catalog where I want to keep track of about 20-30 computers and servers, the software they currently have installed on them, when the software was installed, the specifications of the individual computers, network information for the computers and servers, and a catalog of all the software and licenses we have available. I know this has been done before, but they're paying me to do so I figure "Get paid to learn? Sure!" My question is this: What is good practice for table layout? Should I make one large table with ALL network/hardware/software information? Or break the tables up as small as possible? I'm leaning towards breaking them up into small tables because I have many canidates for primary key for each table(ip address, hostname, inventory#, license#, primary user). Any suggestions/tips would be appreciated. |
#3
|
|||
|
|||
Database Design Process Questions
Find and read several articles on data normalization.
Enlightenment will follow. ; (Lots of tables, few rows, no duplicate infomation, no 'calculated' values) Ed Warren. wrote in message ups.com... I think this is appropriate for this group, so here goes: I'm creating my first access database for my job. It is a computer/software catalog where I want to keep track of about 20-30 computers and servers, the software they currently have installed on them, when the software was installed, the specifications of the individual computers, network information for the computers and servers, and a catalog of all the software and licenses we have available. I know this has been done before, but they're paying me to do so I figure "Get paid to learn? Sure!" My question is this: What is good practice for table layout? Should I make one large table with ALL network/hardware/software information? Or break the tables up as small as possible? I'm leaning towards breaking them up into small tables because I have many canidates for primary key for each table(ip address, hostname, inventory#, license#, primary user). Any suggestions/tips would be appreciated. |
#4
|
|||
|
|||
Database Design Process Questions
It isn't so much the size of the tables as the contents. You could come up
with a (poorly-normalized) design that used small tables or one large table. Focus first on the topic/domain. What are the entities (subjects about which you want to save information), and how are they related? For example, from your description, it sounds like you are working with [computers] and with [software]. And if any of those software licenses are "site" licenses, you could have the "same" software installed on more than one computer, so you'd also be interested in [installed software]. You might also have a few "lookup tables" that hold the values you want selected (rather than letting the users get creative on their data entry/word choice/spelling. I agree with other responders ... spend some time learning about normalization. Here are a couple sources: http://support.microsoft.com/?scid=kb;EN-US;209534 http://www.fmsinc.com/tpapers/genacc...abasenorm.html -- Regards Jeff Boyce Microsoft Office/Access MVP http://mvp.support.microsoft.com/ Microsoft IT Academy Program Mentor http://microsoftitacademy.com/ wrote in message ups.com... I think this is appropriate for this group, so here goes: I'm creating my first access database for my job. It is a computer/software catalog where I want to keep track of about 20-30 computers and servers, the software they currently have installed on them, when the software was installed, the specifications of the individual computers, network information for the computers and servers, and a catalog of all the software and licenses we have available. I know this has been done before, but they're paying me to do so I figure "Get paid to learn? Sure!" My question is this: What is good practice for table layout? Should I make one large table with ALL network/hardware/software information? Or break the tables up as small as possible? I'm leaning towards breaking them up into small tables because I have many canidates for primary key for each table(ip address, hostname, inventory#, license#, primary user). Any suggestions/tips would be appreciated. |
#5
|
|||
|
|||
Database Design Process Questions
I'm going to get a little more advanced than the previous posters, but
it will be good to have the right database schema. I'd start with a Computers table. List all the things that you need to know, including OS Version, Memory available, Serial Number, etc. Next, have a Periphials table. This will include everything like hard drives, monitors, optical drives, scanners, printers, etc. This is a one to many relationship with Computers Next is a Software table. Include fields for version information, number of licenses owned by the company, etc. Finally, have a ComputerSoftware table. This will be a one-many relationship with both the Computers table, and the Software table. This will have a record for each installation of the software on a computer. Finally, once you build those, look into WMI (http://msdn.microsoft.com/library/de..._reference.asp). This will allow you to remotely ping the computer for all the information that you need, saving you from going out to each of the computers. You will need WMI enabled on your pc's, and be a domain admin to run this. The advantage is that inventories are much easier to do, and you can get alot of information about a computer this way, including software installed. If you need more help, I have some classes already created that do the brunt of the work. Chris Nebinger Chris DOT Nebinger AT GMail DOT com |
#6
|
|||
|
|||
Database Design Process Questions
I'd start with a Computers table. List all the things that you need to know, including OS Version, Memory available, Serial Number, etc. Next, have a Periphials table. This will include everything like hard drives, monitors, optical drives, scanners, printers, etc. This is a one to many relationship with Computers Next is a Software table. Include fields for version information, number of licenses owned by the company, etc. Finally, have a ComputerSoftware table. This will be a one-many relationship with both the Computers table, and the Software table. This will have a record for each installation of the software on a computer. This is basically what I've got so far, minus the periphials table. Nice to know I'm on the right track. Though I was using some table lookups which, I've heard, are discouraged at the table level. Finally, once you build those, look into WMI (http://msdn.microsoft.com/library/de..._reference.asp). This will allow you to remotely ping the computer for all the information that you need, saving you from going out to each of the computers. You will need WMI enabled on your pc's, and be a domain admin to run this. The advantage is that inventories are much easier to do, and you can get alot of information about a computer this way, including software installed. Wow, thats perfect. And yes, I am domain admin of this domain. I know a lot more about the client/server side of things than the database side. Honestly, the difficulty of the database learning curve really caught me off guard. Thanks for your suggestions everyone! Kelly |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Date range on reports | Mark_Milly | Setting Up & Running Reports | 10 | January 19th, 2006 03:49 PM |
Combo Box AfterUpdate Help | Harry Thomas | Database Design | 21 | January 9th, 2006 12:16 AM |
DataBase Design | AFKAFB | Using Forms | 1 | August 15th, 2005 12:02 PM |
Access Error Message when opening database | eah | General Discussion | 3 | January 26th, 2005 10:04 AM |
Exclusive access to the database | Steve Huff | General Discussion | 17 | December 24th, 2004 06:23 PM |