I don't mean to disagree with what you are saying but there are some
additional aspects which if considered make this more of a personal
preference than hard and fast rules one must strictly abide by.

> a well designed relational database will have table with few columns,
> 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).

Surely it does. Using a master-detail relationships between tables
accomplishes much of what a JOIN can do for you.

> 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).

Not necessarily.

> WRT business logic, it should be in the server. It can be replicated
> elsewhere, but it should definitely be at least in the server.

This issue is independent of whether you use tables or queries.

Also, don't forget about JOIN's which "tabelize" more complex data
relationships.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com