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 //www.freelists.org/list/programmingblindThis 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 __________View the list's information and change your settings at //www.freelists.org/list/programmingblind
