RE: Planning A Database

  • From: "Homme, James" <james.homme@xxxxxxxxxxxx>
  • To: "programmingblind@xxxxxxxxxxxxx" <programmingblind@xxxxxxxxxxxxx>
  • Date: Tue, 2 Mar 2010 11:05:07 -0500

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
//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
//www.freelists.org/list/programmingblind

Other related posts: