Re: Questions about my strategy - Mailing list pgsql-general

You are confusing database design with user interfece design.

Making a user enter any kind of code is stupid user interface
period.  Ifthe user is looking for size 11 1/2 shoues he should
nothave to remember to enter SizeCode='23W-Z47'  He shoul be
able to either select from a drop down menue or enter any of
"10 1/2", "10.5", or even "10.3 .. 10 3/4"

Here is an example of an inventory search page that is
even a bit more complex than the shoe shor example.  They
have tens of thousands of one of a kind items but still
searching by ad-hoc catagory is easy.  Try it

http://www.yachtworld.com/listing/yw_advanced_search_form.jsp

See, you can find boats built by "catalina" that are between
30 and 40 feet long that are currently in the UK.

Now if you want to storecodes in your DBMS fine. but just
don't show them to the user Use a translation table called
maybe code2human if you ned to save space.


--- Rob Brown-Bayliss <rob@zoism.org> wrote:
> On Wed, 2002-07-31 at 02:34, Andrew Sullivan wrote:
> > Why not three codes: model, colour, and size?  Then you can query
> all
> > by model, and limit by size, colour, or both.
>
> How do you mean three codes?
>
> If you mean having more than one product code for a type of shoe
> thats
> what I am trying to avoid.  I worked for acompany that did that a
> long
> time ago, the product was steel, and having 15 or more different
> lengths
> of a steel chanl meant having 15 product codes.  It was often easier
> to
> walk out to the store and look for the product than to query each
> product code at the counter...
>
>
> > I think your strategy will work, but it has the potential to
> degrade
> > seriously over time, or else to require some sort of regular
> > maintenance.  Nothing wrong with that, of course, just a potential
> > pitfall.
>
>
> One thing I am thinking is having a duplicate table called
> history_transactions, and at a stock take move all the transaction
> rows
> into the history table.  That way we have the total history, but ding
> a
> search for products in stock is useing a smaler table.
>
> Taht said, maybe do the history thing at the end of each financial
> year
> rather then each month or quater depending on how many transactions
> they
> are getting (at the moment it's less than 50 per store per day, so
> less
> 400 a day on a good day, but other potential customes could well be
> busier)
> --
>
> *
> *  Rob Brown-Bayliss
> *
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html


=====
Chris Albertson
  Home:   310-376-1029  chrisalbertson90278@yahoo.com
  Cell:   310-990-7550
  Office: 310-336-5189  Christopher.J.Albertson@aero.org

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com