Re: Planning A Database

Hi Jim: Start simple. organize your data into logically related groups. Each group should have a title like you might name a folder that would hold files related to the name of the folder. Just make one or 2 simple tables at first and build the DB. Then you will get a feel for how it all works without having allot of things that will need changing later. After you build your first database with one or two very simple tables then you will have a better feel for what you will need to do. You can always use the code you build the first working db with later to expand the DB Definitions.Do not try and build your real, production, db first. Keep it really simple, one or 2 tables and only 2 or 3 column, fields. Then you will have a feel for what a table is and how it feels when you work with it. After that you can start planning your production db. Make sure the technicals are doable and you can work with the engine and the languages you want to use before spending allot of time designing your db only to find out you can not work with the technicals. Ya, read up on normalization to get a feel how to design the db but just get a simple one working before you try and design one that will have any complex issues. When you design one you will run into the problem of needing one piece of data in 2 diferent tables or the fact that you will need several occurances of a field for any one occurance of a field in another table. You might also run into needing several occurances for several occurances of a field in 2 or more tables. These are called relationships and are a part of the normalization process. Anyway, the first step is to make sure your development environment will work and that you can handle the technicals. You can build a messy database and still have it work but you can do nothing if the technicals will not work for you. So, just build 2 simple tables with perhaps 3 columns in each. Build the DB, Load some test data and then access it. If you can do that you are ready to think about designing a real database. It can get quite complicated and you really need your development environment up and running before you worry about building a larger DB. That is my own opinion. 
Rick USA
----- Original Message ----- From: "Homme, James" <james.homme@xxxxxxxxxxxx> 
To: <programmingblind@xxxxxxxxxxxxx>
Sent: Tuesday, March 02, 2010 11:05 AM
Subject: RE: Planning A Database


Hi Bill,
I'm going to use Sqlite. I'm debating about whether I want to use Autoit3 or Perl. I want to hold some data that I can then use to update a static web site, possibly a spreadsheet, and I'm not sure what else, but I want to have one chunk of data. I'm trying to minimize the learning curve as much as possible, because I have less than a month to make this all work. I may end up doing the site by hand while I get my database and so on together, then use it on the next iteration. I was looking at the Perl Template Toolkit, because you really don't have to know Perl to make that work. Mostly, I just need to decide, then face down my fear of the unknown, and go for it. 

Thanks.

Jim
Jim Homme,
Usability Services,
Phone: 412-544-1810
Skype: jim.homme
Internal recipients,  Read my accessibility blog


-----Original Message-----
From: programmingblind-bounce@xxxxxxxxxxxxx [mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Bill Gallik 
Sent: Tuesday, March 02, 2010 10:55 AM
To: programmingblind@xxxxxxxxxxxxx
Subject: Re: Planning A Database

Hi Jim,

Which DBMS engine are you planning to use? (not that that matters much as
regards your question)

You certainly can plan as you go; that's called growability in my book (not
published of course).  Here's the thing; I'd make sure to add at least one
"dummy" field in any given record format just in case you eventually need to
create an auxiliary table to hold additional information for a given record
in an original table.

For example; suppose you have a customer information table where each record
is made of key, first name, middle name, last name, address1, address2,
state or province, postal code and telephone number.  Suppose you wind up
wanting to add a cell phone number per customer; it would be great if you
had added an additional field to serve as the key into another table that
listed various cell phone numbers (just a basic example).  And because we
know that some folks have more than one cell phone account that key could be
a non-unique identifier to relate that customer record to one or more cell
phone numbers.

Of course, this can be expanded to ridiculous complexity, but hopefully this
will give you some ideas about how to design an expandable database.

----
Holland's Person, Bill
- "Be careful about reading health books. You may die of a misprint."
- US Humorist, Mark Twain (1835 - 1910)

__________
View the list's information and change your settings at
http://www.freelists.org/list/programmingblind
This e-mail and any attachments to it are confidential and are intended solely for use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not keep, use, disclose, copy or distribute this e-mail without the author's prior permission. The views expressed in this e-mail message do not necessarily represent the views of Highmark Inc., its subsidiaries, or affiliates. 
__________
View the list's information and change your settings at
http://www.freelists.org/list/programmingblind


__________
View the list's information and change your settings at http://www.freelists.org/list/programmingblind

Other related posts: