View Single Post
  #7 (permalink)  
Old 07-10-2007, 12:38 AM
TeraTask's Avatar
TeraTask TeraTask is offline
PT Admin
Awards Showcase
Quality Tutorial Quality Tutorial Quality Tutorial 
Total Awards: 3
Join Date: Jun 2007
Location: Reno, NV
Posts: 440
iTrader: (0)
TeraTask is a splendid one to beholdTeraTask is a splendid one to beholdTeraTask is a splendid one to beholdTeraTask is a splendid one to beholdTeraTask is a splendid one to beholdTeraTask is a splendid one to behold
Quote:
Originally Posted by siLenTz View Post
For example: I create Notepad
application, I don't need any great math background because I don't
deal with any math in my program at all.
You mean to tell me that in a word processing application you have absolutely no formulas or logic? I bow to your ability to have done such and worked completely around any need for mathematics.

That said, I do agree that mathematics is not necessarily needed in all applications, but I would suggest that it's about 1 in a million where math is not used at all (e.g. the "Hello World" application, but that's not exactly useful.) Now, I'm specifically not addressing the usage of advanced mathematics - you don't necessarily need to ever use anything beyond Alg I and a quality class in logic, but if you have less than that you will undoubtedly have issues in a number of the programs you write.

Now, let me give an example of a program I once wrote:

PROBLEM: Create a profile page with dozens of fields, each with two or more options. Some of these fields will allow multiple options to be selected while others will only allow one of the options to be selected. Other users should be able to search for profiles which match one or more of the available options.

ELEMENTARY EXAMPLE:
A profile page which allows for gender, hair color, and eye color. For gender, the options are male, female, or transgender - only one option may be selected. For hair color, the options are red, blond, black, and brown - only one option may be selected. For eye color, the options are brown, hazel, amber, green, blue, gray, violet - more than one color may be selected (my wife's eyes are brown and blue, for example - rather interesting looking). Now, if someone is searching, they may search for females and transgendered even though that field only allows the registrant to have selected one of the fields.

SOLUTION #1 (The totally newbie solution)

Create a field for each allowed field that is a character field, storing the user's entered value. If more than one value is allowed, either create an associative table or separate options by a comma.

SOLUTION #2 (A decent solution, with a little mathematics in the background)

Create a field for each allowed field that is an enumerated or set field, storing the user's entered value. If more than one value is allowed, create an associative table or use set if there are no more than 64 different members (assuming we're using MySQL).

SOLUTION #3 (A robust solution)

Create a field for each allowed field that is an integer (appropriate for the number of options given), storing an integer equivalent for the user's entered value. If more than one value is allowed, store the sum of all selected values. The "integer equivalent" is defined as follows: Each available entry is assigned a successive power of 2. For example, in the case of gender, male := 2^0 = 1; female := 2^1 = 2; transgender := 2^2 = 4. (FYI, ":=" means "is defined to be equal to").


CONSEQUENCES OF SOLUTION #1

During a search, this solution requires a query which searches for matches using a rather slow string comparison method. If an associative table is used, then joins are necessitated thereby increasing the overall complexity of the resultant query. This method will result in excessive server usage for moderately busy sites.

CONSEQUENCES OF SOLUTION #2
This solution has the advantage over solution #1 of not requiring a string comparison (as the values are stored in the database with an assigned number). It requires less storage space than solution #3 if and only if an associative table is not required on any of the fields where more than one option allowed. It has an additional requirement that to add a new option requires a change to the underlying database structure, which is generally not preferred. And, if the number of options ever exceeds 64 on a field where more than one option can be selected, an associative table will need to be created to replace the existing field -- an enormous outlay of additional work which may be just to add one more field.

CONSEQUENCES OF SOLUTION #3
To search using this solution requires only a binary comparison of numbers which computers do very quickly. It will never require a join. It does have the overhead of needing a collection of definitions to define the appropriate power of 2 to the related string and adding a value requires updating this list of definitions. This solution when scaled up to a site with heavy traffic will prove to be the most efficient of the solutions given above.

Now, I obviously used solution #3. Does this prove my point? No, it's only anecdotal evidence, but it is a case in point where the application of mathematics results in a much more robust solution.

Side note: If anyone wants to take up alternatives to solution #3 above which would be more efficient, then I think we should open another thread (unless it's more efficient and doesn't use any math - my jaw would then literally hit the floor, but it'd be 100% on topic.)

__________________
Jeremy Miller
Content Farmer - Optimized Automated Blog Posting

Digg this Post! Del.Icio.Us this Post! Technorati this Post! Furl this Post! Mister Wong this Post! Newsvine this Post! Spurl this Post! Reddit this Post! Netscape this Post!
Reply With Quote
The Following 2 Users Say Thank You to TeraTask For This Useful Post:
ccoonen (08-21-2007), HelloWorld (07-10-2007)