Subject | Re: [IBO] info on database design |
---|---|
Author | Nando Dessena |
Post date | 2001-11-19T13:02:46Z |
Sandeep,
and a huge number of them. Normalization gives you narrow and tall
tables.
Any request made against a well designed database, that should bring
back reasonably related data, must then be written as a SQL join.
You just can't do this with a table component (in my view, you just
can't think a table component has any understandable meaning in a
relational environment).
The final note is that if you can use table components for anything
other than dumb lookups, log tables and such, your database must not be
well normalized (which is not necessarily a bad thing, just something
not to use as example).
WRT business logic, it should be in the server. It can be replicated
elsewhere, but it should definately be at least in the server.
Just MHO.
Ciao
--
____
_/\/ando
> Another advantage of using Table is that the sql statement is madea well designed relational database will have table with few columns,
> by it so you don't have to worry about writing it (doesn't makes a
> big difference but I still think is good). And another reason I prefer
> using a table is because I define my business logic inside table
> component.
and a huge number of them. Normalization gives you narrow and tall
tables.
Any request made against a well designed database, that should bring
back reasonably related data, must then be written as a SQL join.
You just can't do this with a table component (in my view, you just
can't think a table component has any understandable meaning in a
relational environment).
The final note is that if you can use table components for anything
other than dumb lookups, log tables and such, your database must not be
well normalized (which is not necessarily a bad thing, just something
not to use as example).
WRT business logic, it should be in the server. It can be replicated
elsewhere, but it should definately be at least in the server.
Just MHO.
Ciao
--
____
_/\/ando