Jason,

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

This is of course true. What I wrote was just my personal opinion (which
is incidentally shared by many people) and I meant to highlight some
fact the poster might not be aware of.

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

You still have to resort to joins and subselects to get descriptions for
the codes. You can of course use lookup fields tied to different
datasets (tables), it just seems to me a strange approach to development
with a relational database when it's me (the client) who has to build
the relations. ;-).
I agree that when you have a tool that shields you from the intricacies
of C/S (like many things in IBO, such as the IBOTable) you may well
ignore some of the classic relational "no-no"s.

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

You must have one or more examples of a business entity that is
described with just one table in a 3rd normal form database. I have
never seen one. Instead I have seen (and designed :-( ) many
denormalized databases.

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

Actually "table vs query" was not the (only) topic of the discussion.
:-)

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

Yeah, and views and stored procedures too. Isn't a relational database a
wonderful idea? We wouldn't be talking about reaching the perfection if
we were using, say, Paradox. :-)
Ciao
--
____
_/\/ando