Hacker News Reader

Comment by BillyTheKing | Hacker News Reader

why though? this is exactly what databases have been invented for! One could simply store a mapping of numbers to their classifications as 'even' or 'odd' in an SQLite database. This approach has the added benefit of not requiring program updates whenever a number's classification changes from odd to even.

View on HN

Databases still have to be maintained and updated. You're better off setting up an Ethereum contract with proper economic incentives for others to act as an oracle and return the proper answer at any given time.

Anyone want to try to figure out the gas costs for deploying 30GB worth of smart contracts? xD

Yes, this seems like the kind of thing that should be in Wikidata. Then you also don't have to keep the database locally and can simply do a quick HTTPS request. (The only problem might be if TLS itself needs an even/odd function, but it probably doesn’t.)

> The only problem might be if TLS itself needs an even/odd function, but it probably doesn’t.

Doesn't sound like its ready for cloud scale.

I like this option just because then it makes it easy for anyone to update the data when future changes arise.

    CREATE TABLE even_or_odd (
      is_odd NUMBER(1);
      is_even NUMBER(1);
      is_zero NUMBER(1);
      is_one NUMBER(1);
      is_two NUMBER(1);
      is_three NUMBER(1);
      -- ...
    );
    INSERT INTO even_or_odd (is_odd,is_one) VALUES (1,1);
    INSERT INTO even_or_odd (is_even,is_two) VALUES (1,1);

A better design would look like this:

    CREATE TABLE numbers (
      minus_four_billions_two_hundred_ninety_four_millions_nine_hundred_sixty_seven_thousands_two_hundred_ninety_six_is_even BOOLEAN,
      ...
      zero_is_even BOOLEAN,
      one_is_even BOOLEAN,
      two_is_even BOOLEAN,
      ...
      four_billions_two_hundred_ninety_four_millions_nine_hundred_sixty_seven_thousands_two_hundred_ninety_six_is_even BOOLEAN
    )

That design can store multiple versions of the data, making it more resilient to future changes in the even/odd property of numbers.

Correct, but you'd certainly want to use an XML database.

Not only it helps with portability of the data, it also keeps it in a human-friendly format should the need to inspect it by hand arise.

XML is not web scale though, if you want to serve lots of users it has to be JSON in MongoDB.

AWS's Elastic Cloud Parity already provides this, and is far more scalable.

Reply on news.ycombinator.com