mazur@inmet.inmet.com (04/09/90)
Please accept my apologies if this is akin to the Mrs. Fields postings
in rec.cooking, but I'm interested in free advice...
I'm at the preliminary design stage of a customized inventory program for
a caterer I do work for. I'm a bit overwhelmed about all the choices I
seem to have and am trying to narrow things down a bit. The program as
I visualize it will be primarily search and query by the user and I want
it to be idiot-proof - these are computer-illiterate users. I hope to
make it look like an ATM (i.e., no mice, nothing fancy, just menu-driven
screens with on-line help).
I haven't ruled out the idea of selling it to other caterers so I'd rather
have that option (and not have to have them buy a dBASE III, etc.). So
my questions:
- Is there any reason to consider a MAC if I don't want a mouse?
- Given my simple database scheme (screens, search & query), what
database program would you recommend? (my friend thinks we could
do it in C, but I'd think that's a bit like re-inventing the
wheel).
- Any other comments, suggestions? This is something I'm doing in
my spare time, not for "real work", but I'd like to do it right
the first time.
Thanks in advance,
Beth Mazur
mazur@inmet.inmet.comrickf@pmafire.UUCP (rick furniss) (04/11/90)
My personal view for a relational DB is FilePro from Small Comp. Co.
Runs on DOS, and most Unix machines.
Ive used Unify, Progress, DB3, Informix, and most other majors, and find
FilePro eats them all. You can start simple a progress to complicated
relational models as you learn.
Its is not the cheapest DB but you pay for what you get. Sometimes you
even get what you paid for as with FilePro.
I am not associated in any way with Small Computer Company.
These are personal views only and not open for personal flames.
Rick Furniss
Standard Disclaimer.........awd@dbase.A-T.COM (Alastair Dallas) (04/11/90)
In article <19500001@inmet>, mazur@inmet.inmet.com writes: > I'm at the preliminary design stage of a customized inventory program for > a caterer I do work for. I'm a bit overwhelmed about all the choices I > seem to have and am trying to narrow things down a bit. The program as > I visualize it will be primarily search and query by the user and I want > it to be idiot-proof - these are computer-illiterate users. I hope to > make it look like an ATM (i.e., no mice, nothing fancy, just menu-driven > screens with on-line help). From the database point of view, "simple" means that the table of data you require does not itself require other tables. For example, a table of work orders might have an entry for "Client name" which would be a reference to a separate table of client's names, addresses and phone numbers. Inventory systems often need more than one table--this is called 'relational' as opposed to 'flat file'. > I haven't ruled out the idea of selling it to other caterers so I'd rather > have that option (and not have to have them buy a dBASE III, etc.). Most systems, such as dBASE III, have runtime options by which you can distribute your software without having your end users purchase the development system. > So my questions: > > - Is there any reason to consider a MAC if I don't want a mouse? Macintoshes are more friendly for novice users. ATMs are a rather klunky user-interface model (as an aside, I had a long talk recently with software developers at a major bank which is developing ATM capabilities based on touch-screen Mac II's). You're right to leverage your user's existing knowledge of ATMs, but Macs take advantage of leverage as well because each application on a Mac uses the same interface. Also, Macs were designed to be "Information Appliances," and a kitchen counter was considered the likely home for the Mac that Jef Raskin designed, but I digress. The point is, it's self- contained. However, I wouldn't have mentioned Macs if you hadn't--go with what you're comfortable with. > - Given my simple database scheme (screens, search & query), what > database program would you recommend? (my friend thinks we could > do it in C, but I'd think that's a bit like re-inventing the > wheel). You're right; don't write it in C if you can help it. A higher-level language will get a prototype working faster and will be much easier to change. If you sell this to other caterers, you'll probably sell them version 2 or 3 after your current client works the bugs out. You probably need multiple-file capability, so I'd recommend dBASE III PLUS. dBASE IV is probably over-kill, and there's more third-party support just now for III+ in terms of compilers and development tools. Of course, dBASE IV's integrated application generator would get you off to a fast start. (I try to be unbiased, generally, but here your question was too vague--try asking me specifically about one of our competitors and I'll be more fair :-). > - Any other comments, suggestions? This is something I'm doing in > my spare time, not for "real work", but I'd like to do it right > the first time. This task could be done in dozens of different environments. I'd say prototype something in whatever is at hand before you go out and buy hardware or software. If you're without either, buy a Compaq 386 and dBASE IV. Trust me. But if you've got something now, like BASIC, like Lotus 1-2-3, like Turbo Pascal--use that and see how far you get. Systems like this are a lot smoother the second time around, once you know the totality of what you're getting into. > Thanks in advance, > Beth Mazur > mazur@inmet.inmet.com Good luck! /alastair/ Disclaimer> I'm speaking just for me, even when I sound like such a cheerleader.