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

This is just a part of developing a user interface. You have to have a table
of the lookup values with the keys if the user is going to look through the
meaningful values and the key is what is going to be plugged in as a result
of their choice. I fail to see where an actual JOIN is useful in this
process other than at the reporting side of things, but that isn't what I am
talking about here. I'm talking about interactive GUI apps for data entry
and such.

I think I am just missing your point.

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

I don't see your point of view here. I am not suggesting anyone do anything
that is a classic relational "no-no". Relational database means we store
things in relations. This is one of the basic building blocks of any good
relational system. There is nothing wrong with an application being designed
to directly use relations at their basic level. Perhaps you can elaborate on
this if you find a spare minute or two.

It isn't important to me that we agree. But, it is important that I feel
like I understand what you are saying and that you know what I am saying.

Do you feel like what I am saying may encourage people to miss out on all
the cool stuff you and I enjoy while using InterBase? If that is your point,
then it is well received. In actuality, I don't use TIBOTable in any of my
applications, if that makes you feel any better. I just recognize that it is
a very quick, easy and powerful way to put together a very easy to use GUI
app. I agree there is more out there to be enjoyed, it is just that
TIBOTable really packs in quite a lot of nice things (which are all
available with native IBO queries as well) in an easy to use package.

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

We are saying the same thing. Just because someone is putting a LookupField
on a table so they get a nice pick list in their DBGrid doesn't mean they
are or aren't putting business rules on the server or the client. I totally
agree with you that business rules are best placed on the server and only
duplicated on the client where absolutely necessary (which is why I shun
cached updates).

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

I love InterBase! I can't imagine using anything else.

Thanks for your insights. I think this little bouncing back and fourth is a
good way to open people's views to some of the questions they may be having
about how to approach the design of their applications. I've trusted you
would have the patience with me to contrast some things you have said. I am
sure you are making good points, I just want them to be crystal clear. Too
often there are over-generalizations made and I like to combat them where I
can.

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