I’m a tech interested guy. I’ve touched SQL once or twice, but wasn’t able to really make sense of it. That combined with not having a practical use leaves SQL as largely a black box in my mind (though I am somewhat familiar with technical concepts in databasing).

With that, I keep seeing [pic related] as proof that Elon Musk doesn’t understand SQL.

Can someone give me a technical explanation for how one would come to that conclusion? I’d love if you could pass technical documentation for that.

  • 9point6@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    9 days ago

    The statement “this [guy] thinks the government uses SQL” demonstrates a complete and total lack of knowledge as to what SQL even is. Every government on the planet makes extensive and well documented use of it.

    The initial statement I believe is down to a combination of the above and also the lack of domain knowledge around social security. The primary key on the social security table would be a composite key of both the SSN and a date of birth—duplicates are expected of just parts of the key.

    If he knew the domain, he would know this isn’t an issue. If he knew the technology he would be able to see the constraint and following investigation, reach the conclusion that it’s not an issue.

    The man continues to be a malignant moron

    • snooggums@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      9 days ago

      The initial statement I believe is down to a combination of the above and also the lack of domain knowledge around social security. The primary key on the social security table would be a composite key of both the SSN and a date of birth—duplicates are expected of just parts of the key.

      Since SSNs are never reused, what would be the purpose of using the SSN and birth date together as part of the primary key? I guess it is the one thing that isn’t supposed to ever change (barring a clerical error) so I could see that as a good second piece of information, just not sure what it would be adding.

      Note: if duplicate SSNs are accidentally issued my understanding is that they issue a new one to one of the people and I don’t know how to find the start of the thread on twitter since I only use it when I accidentally click on a link to it.

      https://www.ssa.gov/history/hfaq.html

      Q20: Are Social Security numbers reused after a person dies?

      A: No. We do not reassign a Social Security number (SSN) after the number holder’s death. Even though we have issued over 453 million SSNs so far, and we assign about 5 and one-half million new numbers a year, the current numbering system will provide us with enough new numbers for several generations into the future with no changes in the numbering system.

      • halcyonloon@midwest.social
        link
        fedilink
        English
        arrow-up
        0
        ·
        9 days ago

        Take this with a grain of salt as I’m not a dev, but do work on CMS reporting for a health information tech company. Depending on how the database is designed an SSN could appear in multiple tables.

        In my experience reduplication happens as part of generating a report so that all relevant data related to a key and scope of the report can be gathered from the various tables.

        • DahGangalang@infosec.pubOP
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          9 days ago

          A given SSN appearing in multiple tables actually makes sense. To someone not familiar with SQL (i.e. at about my level of understanding), I could see that being misinterpreted as having multiple SSN repeated “in the database”.

          Of all the comments ao far, I find yours the most compelling.

          • Barbarian@sh.itjust.works
            link
            fedilink
            arrow-up
            0
            ·
            edit-2
            9 days ago

            Theoretically, yeah, that’s one solution. The more reasonable thing to do would be to use the foreign key though. So, for example:

            SSN_Table

            ID | SSN | Other info

            Other_Table

            ID | SSN_ID | Other info

            When you want to connect them to have both sets of info, it’d be the following:

            SELECT * FROM SSN_Table JOIN Other_Table ON SSN_Table.ID = Other_Table.SSN_ID

            EDIT: Oh, just to clear up any confusion, the SSN_ID in this simple example is not the SSN itself. To access that in this example query, it’d by SSN_Table.SSN

            • schteph@lemmy.world
              link
              fedilink
              arrow-up
              0
              ·
              9 days ago

              This is true, but there are many instances where denormalization makes sense and is frequently used.

              A common example is a table that is frequently read. Instead of going to the “central” table the data is denormalized for faster access. This is completely standard practice for every large system.

              There’s nothing inherently wrong with it, but it can be easily misused. With SSN, I’d think the most stupid thing to do is to use it as the primary key. The second one would be to ignore the security risks that are ingrained in an SSN. The federal government, being large as it is, I’m sure has instances of both, however since Musky is using his possy of young, arrogant brogrammers, I’m positively certain they’re completely ignoring the security aspect.

              • DahGangalang@infosec.pubOP
                link
                fedilink
                arrow-up
                0
                ·
                8 days ago

                Yeah, no one appreciates security.

                I probably overused that saying to explain it: ‘if theres no break ins, why do we pay for security? Oh, there was a break in - what do we even pay security for?’