Didn't feel like creating an account (or figuring out my logon info) for the post so I'll include my thoughts here: > Yea, I wrote a blog post on this subject recently if you're interested. > > http://blog.kitchenpc.com/2012/06/27/3-4-things-left-to-do/ =============================================== Salt & Pepper is a sub-type of "spice" where generally the chef would either have some available - or not. 3 eggs + "eggs" = "3+ eggs" I see three categories of measurement: Known Unmeasured (i.e., "to taste") Measured - Unknown And two categories for ingredients: Unit Bulk Unit items are those where you can readily count how many you have/need; generally purchased and used within a handful of meals. Bulk items are those, like spices, that you buy enough for many meals. You measure when you use them but otherwise do not keep track of how much is remaining. I could see the presentation interface having multiple columns/sections each listing the appropriate ingredients. In searching for ranges I think: \d+\s*(-|to)\s*\d+ would be a better expression (capture the word "to" as well as "-") Basically a divide-and-conquer strategy. Classify, find differences and similarities, then decide how to present them to the user. Also, consider the following: WITH ruleset (regex_exp) AS ( VALUES ('exp1'), ('exp2') ) SELECT data, regex_emp FROM ruleset CROSS JOIN (SELECT 'data' AS data) dt WHERE dt ~ regex_exp; This returns one record for each expression that matches "data". I use this general technique to build a regex-based rule engine in postgresql. Generally you need to rank the rules and then return the match with the lowest/highest rank. //////////////////////////// > Really, the only thing I do with the data is total up amounts to generate a > shopping list. With ranges, I simply take the high amount. > If one recipe calls for 2-3 eggs, and another calls for 4 eggs, I would add 7 > eggs to the shopping list as that's the most you'd need to buy. The "Low" > amount is simply for display purposes only, I do no math with this. However, > I can't predict what the future holds for the site. Maybe I'll need to store all > sorts of crazy things, so it's best to handle things in the best way up front so I > don't have to rip apart all this low level code later on. ============================== Please do not suggest that people should buy an infinite number of eggs... :) David J. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
