The basic problems with SSN (and similar IDs) come from the fact they are being treated as ... numbers.
First, the fact that something is made up by digits doesn't imply it's a decimal number! That it's an ID so it'd be treated as text. We'd check for equality only and are not supposed to do any math there.
Phone numbers are not decimal numbers and also there the zeros matter quite a lot.
Second, padding is a bad idea. You add information (blanks and zeros) without recording where and how much. So, from the previous point, use TEXT for text.
Third. The America is powerful and big. But there's a whole world there outside. Maybe adding an ISO-3166 column would have helped a little bit.
So, yes, choose you PK wisely. Or be wise in the DB design first, then maybe a wise PK will pop automatically up.
Warning: pg_query() [function.pg-query]: Query failed: ERROR: syntax error at or near ")" at character 130 in /home/community/planetpg/people.planetpostgresql.org/serendipity/include/db/postgres.inc.php on line 210
Error in DELETE FROM dfetter_options WHERE okey LIKE 'commentsub_%' AND cast(name as integer) < 1248934906)
ERROR: syntax error at or near ")" at character 130
array (
0 =>
array (
'file' => '/home/community/planetpg/people.planetpostgresql.org/serendipity/include/functions_comments.inc.php',
'line' => 891,
'function' => 'serendipity_db_query',
'args' =>
array (
0 => 'DELETE FROM dfetter_options
WHERE okey LIKE \'commentsub_%\' AND cast(name as integer) < 1248934906)',
),
),
1 =>
array (
'file' => '/home/community/planetpg/people.planetpostgresql.org/serendipity/comment.php',
'line' => 38,
'function' => 'serendipity_commentSubscriptionConfirm',
'args' =>
array (
0 => '615b0202881cfb0d5f4769c3db54ac03',
),
),
)
DELETE FROM dfetter_options WHERE okey LIKE 'commentsub_%' AND cast(name as integer) < 1248934906)
Here's two more reasons why SSN's aren't good ID candidates and neither is technical.
Firstly, Social Security Numbers aren't unique. The get recycled over time. Therefore, if you have an application looking at a set of historical data, the social security number will likely run into duplication collisions. It doesn't even have to be a long span of time between occurrences either. I've heard of duplication happening within only a few years.
Secondly, it's actually illegal to use Social Security Numbers as "identifiers". This stems from a little-known law passed during the Great Depression (1933?). What I find amazing is that every time I call to inquire about an account, the company always wants my SSN to look it up. Go figure.
My point is that a Social Security Number, based on the two statements above, should never be considered as a primary key candidate. They're good for look ups but nothing more.
Another thought is that SSNs do not reliably identify a person. I know people who (for personal security reasons) use "made up" SSN numbers for everyone other than the IRS.
David,
Not disagreeing with you. The biggest problem with SSN is identity theft. The irony is that its such a well established identifier of a person that its worth stealing just like credit cards. Sure SSNs get recycled when people die and so forth, but that doesn't make it any worse than any other natural key identifier we can come up with that is prone to duplication.
The more pressing question is "What is a better alternative if you need to share data with other agencies? Do you just use a dummy key" I suppose you could still use SSN and encrypted and have it as a lookup and just put a unique constraint on it or is that what you are proposing?
I'm proposing thinking things through in advance, and doing research about how these things can mess up.
One of the pervasive, destructive myths of computing is the idea that what you're doing is, by default, ground-breaking. The vast majority of people are doing something that's at least mostly similar to one or more things that have already been done.
uggs
,ugg boots uk
buy ugg boots sale
,buy ugg boots uk
buy ugg boots sale
,buy cheap uggs uk
ugg boots uk sale
,buy ugg boots sale uk
ugg boots cheapest
,buy discount uggs uk.
http://www.wholesaleuggsale.co.uk/
First, the fact that something is made up by digits doesn't imply it's a decimal number! That it's an ID so it'd be treated as text. We'd check for equality only and are not supposed to do any math there.
Phone numbers are not decimal numbers and also there the zeros matter quite a lot.
Second, padding is a bad idea. You add information (blanks and zeros) without recording where and how much. So, from the previous point, use TEXT for text.
Third. The America is powerful and big. But there's a whole world there outside. Maybe adding an ISO-3166 column would have helped a little bit.
So, yes, choose you PK wisely. Or be wise in the DB design first, then maybe a wise PK will pop automatically up.
Warning: pg_query() [function.pg-query]: Query failed: ERROR: syntax error at or near ")" at character 130 in /home/community/planetpg/people.planetpostgresql.org/serendipity/include/db/postgres.inc.php on line 210
Error in DELETE FROM dfetter_options WHERE okey LIKE 'commentsub_%' AND cast(name as integer) < 1248934906)
ERROR: syntax error at or near ")" at character 130
array (
0 =>
array (
'file' => '/home/community/planetpg/people.planetpostgresql.org/serendipity/include/functions_comments.inc.php',
'line' => 891,
'function' => 'serendipity_db_query',
'args' =>
array (
0 => 'DELETE FROM dfetter_options
WHERE okey LIKE \'commentsub_%\' AND cast(name as integer) < 1248934906)',
),
),
1 =>
array (
'file' => '/home/community/planetpg/people.planetpostgresql.org/serendipity/comment.php',
'line' => 38,
'function' => 'serendipity_commentSubscriptionConfirm',
'args' =>
array (
0 => '615b0202881cfb0d5f4769c3db54ac03',
),
),
)
DELETE FROM dfetter_options WHERE okey LIKE 'commentsub_%' AND cast(name as integer) < 1248934906)
Maybe by using... TWO columns...
One value is a US SSN. The other isn't.
Firstly, Social Security Numbers aren't unique. The get recycled over time. Therefore, if you have an application looking at a set of historical data, the social security number will likely run into duplication collisions. It doesn't even have to be a long span of time between occurrences either. I've heard of duplication happening within only a few years.
Secondly, it's actually illegal to use Social Security Numbers as "identifiers". This stems from a little-known law passed during the Great Depression (1933?). What I find amazing is that every time I call to inquire about an account, the company always wants my SSN to look it up. Go figure.
My point is that a Social Security Number, based on the two statements above, should never be considered as a primary key candidate. They're good for look ups but nothing more.
Not disagreeing with you. The biggest problem with SSN is identity theft. The irony is that its such a well established identifier of a person that its worth stealing just like credit cards. Sure SSNs get recycled when people die and so forth, but that doesn't make it any worse than any other natural key identifier we can come up with that is prone to duplication.
The more pressing question is "What is a better alternative if you need to share data with other agencies? Do you just use a dummy key" I suppose you could still use SSN and encrypted and have it as a lookup and just put a unique constraint on it or is that what you are proposing?
One of the pervasive, destructive myths of computing is the idea that what you're doing is, by default, ground-breaking. The vast majority of people are doing something that's at least mostly similar to one or more things that have already been done.
,ugg boots uk
buy ugg boots sale
,buy ugg boots uk
buy ugg boots sale
,buy cheap uggs uk
ugg boots uk sale
,buy ugg boots sale uk
ugg boots cheapest
,buy discount uggs uk.
http://www.wholesaleuggsale.co.uk/