🚀 go-pugleaf

In article <1990Dec28.223155.12781@bram.UUCP>, joe@bram.UUCP (Joe Saladino) writes:
|> I had a client who spent 300k developing a system for a mac network
|> using 4D.  My evaluation of 4D a year and a half before was that 4D
|> would not cut the mustard.
[...]
|> My client is now in a lot of pain.  The Macs are not doing the job and
|> 300k in costs.  They are looking at using Oracle for the Mac with 4D
|> as a front end.  Again there will be more programming costs.
|> 
|> Funny thing is that they went with the Macs because of the graphical
|> interface.  The users have been telling the programmers to set up hot
|> keys so they can move around the system better.

A familiar story. (Only the one I know of didn't involve 4D.) If you have
anything but a trivial DB application, getting the DB right is the major
priority. Once you have that part sorted out, you can start worrying about
user interface etc. Not that these are mutually exclusive - it's just a
matter of making sure you understand your priorities. If you need to get
a relatively big multi-user database right, with acceptable response time,
etc., you'd better make sure the tools you choose meet these goals from
the start. Maybe the correct approach would be a pretty interface on top
of a terminal emulator, for example (rather than a Mac-based DB) - but
this could only become obvious once you've had a first pass at the DB
design.

So my advice on this is to try to avoid committing to a specific tool until
a fair amount of the DB design is complete. In this scenario, 4D may well be
a good tool for prototyping. I'm not an DB expert - just reporting a few
observations based on seeing a project die as a result of doing things the
wrong way round.
-- 
Philip Machanick
philip@pescadero.stanford.edu