Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re: In base 1, the number after 0 is:

by chacham (Priest)
on May 01, 2014 at 19:08 UTC ( #1084678=note: print w/ replies, xml ) Need Help??


in reply to In base 1, the number after 0 is:

The idea of ℵ₀ (aleph-zero), and for that matter, "many", comes from George_Gamow's book, One_Two_Three_..._Infinity. He explains that in one language there are words for "one", "two", "three", and after that, "many", because it didn't matter at that point. (a search for one two three many found this which mentions this idea.)


Comment on Re: In base 1, the number after 0 is:
Re^2: In base 1, the number after 0 is:
by tobyink (Abbot) on May 01, 2014 at 23:54 UTC

    In terms of database design, class design, and many other programming tasks, it is often useful to restrict your concept of numbers to there being only three numbers:

    • None
    • One
    • Many

    For example: never design a database that can store two e-mail addresses for a contact. It should store none, one, or many. Now, your interface might restrict people to entering a "sensible" number of e-mail addresses like two, or six, or ten, but the database design should stick with none, one, or many.

    use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

      In terms of database design, class design, and many other programming tasks, it is often useful to restrict your concept of numbers to there being only three numbers

      That is a good rule of thumb, but it is just a starting point. The real rule is, in my mind, whether a data rule requires it; and if it does, how many. If how many cannot be answered with a specific number, a new (child) table is used for them. Otherwise, same table.

      For example, if storing email addresses and one alternate, it may make sense to store both email addresses in the same table. Another example (from my current project), if you have an entity created with up to 12 parts (each part being similar to a level), it is likely better to store the 12 parts in the same table.

      Technicalities, perhaps. But, this is what i do for a living.

        If you want to search for entities which contain a "Foo" part then you need to do:

        SELECT entity_id FROM entities WHERE part1='Foo' OR part2='Foo' OR part3='Foo' ... OR part12='Foo';

        Or perhaps slightly more concise:

        SELECT entity_id FROM entities WHERE 'Foo' IN (part1, part2, part3, ..., part12);

        I'd much prefer something like:

        SELECT e.entity_id FROM entities e INNER JOIN entity_parts ep ON e.entity_id=ep.entity_id WHERE ep.part='Foo'

        When you get to searching for different combinations of parts, the advantages of joining become even more apparent:

        SELECT e.entity_id FROM entities e INNER JOIN entity_parts ep1 ON e.entity_id=ep1.entity_id INNER JOIN entity_parts ep2 ON e.entity_id=ep2.entity_id WHERE ep1.part='Foo' AND ep2.part IN ('Bar', 'Baz')

        And in terms of the e-mail example, it's much easier to, say, enforce a UNIQUE constraint over a single column.

        use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1084678]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (6)
As of 2014-11-28 23:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (200 votes), past polls