smarter ids

[BenPortner]

In the current schema, IDs are implemented as INTs. I think they should be strings. The IDs should then be hashes representing the values of the fields. This has two advantages:

1) no integer overflow (although this might not be a problem if the int has enough bits) 2) automatic duplicate detection: if the hashes match, the content of the entry matches and addition to the database is prevented

[cmutel]

• ints won't overflow until 2 billion (21474836478, to be precise), and can be migrated to to bigint if necessary.
• Automatic duplicate detection is better handled by unique constraints. There could be cases where duplicate data is desired.
• Consistent hashing requires a fixed schema that won't change, which is unlikely in the future.

Debate on natural versus surrogate keys is long and more long; for the time being, can we leave it as it is, and revisit if there is a pressing need for change?

[BenPortner]

ints won't overflow until 2 billion (21474836478, to be precise), and can be migrated to to bigint if necessary.

Wow, yeah that should be enough unique keys for now. Case closed.

There could be cases where duplicate data is desired.

Just out of curiosity: Can you give me an example where it makes sense to have duplicate rows?