Re: Database architecture...

[Martin L. <m-l...@le...>]

Roland Stoker <sql...@st...> writes:

> I'm kind of new here, so it's probably not my place to do this but I would 
> like to suggest a prety large change in the db-architecture...

In general you speak about normalization of the db. *If* there are any
plans to modify the layout of the db I agree with you that there should
be spent most time to build a fairly normalized db-design. Perhaps
http://www.phpbuilder.com/columns/barry20000731.php3 is also helpful if
you're interested in db-design.

> Solution: [...] To recreate that you make a th folowing tables:
> 
> -companies (with the fields like customar or vendor)
> -function (a table with company_nr and function_nr, they are primary key)
> -function_define (function_nr = primary key, and some explanation fields)
> -people (probably something like employees like adres and phone,... but 
> without salary)
> -peoplecompany (a bit like function to tie people to companies, like contacts)
> -employee (people_nr, salary,...)

And what if an employee(=people) becomes a company (i.e. a vendor)? IMO
it should not matter wether a person is a natural person or a company -
they should be part of one single table. And this is only one example. A
properly planned db-design is the most important base.

> Queries will not change much, other then always having to define who you want.

Nack. The queries are not the main problem. The content of any existing
db is it, partially due its redundancy. Porting data from an existing
(redundant) db-layout to a new one can be a nightmare.

> Should be something to think about.

With a slightly different approach: Yes.

Martin