I'm trying to figure out what fields could be normalized. After looking up
normalization I think I understand the concept, and I think the database is
structured according to that method, but I may not be fully understanding
normalization. Can you point out an example of whats not normalized?
On Thu, Sep 27, 2012 at 9:24 PM, Essobi <ess...
> Normalizing. Some of those fields can be enums. Normalize if you need it
> to scale. Do input sanitation too. Lookup OWASP.
> On Thu, Sep 27, 2012 at 3:16 PM, Jonathan Clark <jdc...@gmail.com> wrote:
>> 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.
>>> 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!