On Thu, Sep 27, 2012 at 9:24 PM, Essobi <ess...@gmail.com> wrote:
> Normalizing.  Some of those fields can be enums.  Normalize if you need it
> to scale.  Do input sanitation too.  Lookup OWASP.

> -essobi

> On Thu, Sep 27, 2012 at 3:16 PM, Jonathan Clark <jdc...@gmail.com> wrote:

>> Brian,

>> I like the concept of using single status and type tables for tables that
>> have the same status and type definitions.  You wouldn't use the same table
>> to put ALL status definitions in though..right?  Only when the fields
>> referencing the status values will share the same exact set of options?

>> I definitely missed the adding of a data/time stamp for entries!

>>  I don't know what an n-tier database strategy is, but I know how to
>> start google-ing :) Thanks for the input!

>> On Thu, Sep 27, 2012 at 3:06 PM, Brian Wagner <br...@tegrasys.com> wrote:

>>> I tend to create a single codes table for 'types' and 'statuses' and
>>> other lookup type codes.  Then as you add functionality to your db, you can
>>> simply add another code instead of building another table.  Also consider
>>> using an n-tier database strategy using a module that handles all database
>>> calls.  You really do not want sql in your view code.  Finally you might
>>> need a timestamp field in your tables if you worry about multiple
>>> people editing the same record at the same time.  Most of the DB work I do
>>> is in Visual Basic and Sql Server but the concepts are the same.  You may
>>> want to read up on Ruby on Rails.  Good database strategy there.  There is
>>> a lot to being a DBA and a good database programmer.  Keep reading and ask
>>> me any questions.  I have been in this game for 20+ years.  Good luck.

>>> Brian

>>> On Thu, Sep 27, 2012 at 1:53 PM, Jonathan Clark <jdc...@gmail.com>wrote:

>>>>  Thanks to everyone that's responded,

>>>> At the moment I'm just creating the initial database and working on
>>>> some very simple pages to display and input data.  I think I have the
>>>> database structured correctly but then again this is my first time creating
>>>> any type of database and I have less then 24 hours of experience, so I'm
>>>> sure there errors all over the place.

>>>> Once I have got the majority of the database setup I am definitely
>>>> interested in any guidance related to the best way to display data and
>>>> create forms for data input. (I may also be able to pay someone to get the
>>>> initial web interface up and running).

>>>> Here's a copy of the current database I've created and the relationship
>>>> diagram.  If any of you database guys wanna take a look at it and let me
>>>> know if there's anything I'm doing horribly wrong, please feel free.  I'll
>>>> take all the advice I can get.  THANKS!

> --
> Essobi