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.

  • halcyonloon
    link
    fedilink
    English
    arrow-up
    26
    ·
    1 day 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
      23
      ·
      edit-2
      1 day 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
        13
        ·
        edit-2
        1 day 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
          20
          ·
          1 day 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
            6
            ·
            1 day 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?’

          • esa@discuss.tchncs.de
            link
            fedilink
            arrow-up
            5
            ·
            1 day ago

            To be a bit more generic here, when you’re at government scale you’re generally deep in trade-off territory. Time and space are frequently opposed values and you have to choose which one is most important, and consider the expenses of both.

            E.g. caching is duplicating data to save time. Without it we’d have lower storage costs, but longer wait times and more network traffic.

          • Barbarian@sh.itjust.works
            link
            fedilink
            arrow-up
            3
            ·
            1 day ago

            Yeah, I work daily with a database with a very important non-ID field that is denormalized throughout most of the database. It’s not a common design pattern, but it is done from time to time.

        • DahGangalang@infosec.pubOP
          link
          fedilink
          arrow-up
          2
          ·
          1 day ago

          Yeah, databases are complicated and make my head hurt. Glancing through resources from other comments, I’m realizing I know next to nothing about database optimization. Like, my gut reaction to your comment is that it seems like unnecessary overhead to have that data across two tables - but if one sub-dept didn’t need access to the raw SSN, but did need access to less personal data, j could see those stored in separate tables.

          But anyway, you’re helping clear things up for me. I really appreciate the pseudo code level example.

          • Barbarian@sh.itjust.works
            link
            fedilink
            arrow-up
            6
            ·
            edit-2
            1 day ago

            It’s necessary to split it out into different tables if you have a one-to-many relationship. Let’s say you have a list of driver licenses the person has had over the years, for example. Then you’d need the second table. So something like this:

            SSN_Table

            ID | SSN | Other info

            Driver_License_Table

            ID | SSN_ID | Issue_Date | Expiry_Date | Other_Info

            Then you could do something like pull up a person’s latest driver’s license, or list all the ones they had, or pull up the SSN associated with that license.

    • Ephera@lemmy.ml
      link
      fedilink
      English
      arrow-up
      8
      ·
      1 day ago

      The SSN is likely to appear in multiple tables, because they will reference a central table that ties it all together. This central table will likely only contain the SSN, the birth date (from what others have been saying), as well as potentially first and last name. In this table, the entries have to be unique.
      But then you might have another table, like a table listing all the physical exams, which has the SSN to be able to link it to the person’s name, but ultimately just adds more information to this one person. It does not duplicate the SSN in a way that would be bad.

    • snooggums@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      ·
      1 day ago

      It is common for long lived databases with a rotating cast of devs to use different formats in different tables as well! One might have it as a string, one might have it as a number, and the other might have it with hyphens in the same database.

      Hell, I work in a state agency and one of our older databases has a dozen tables with databases.

      • One has the whole thing as a long int: 222333444
      • One has the whole thing as a string: 2223334444 (which of course can’t be directly compared to the one that is a long int…)
      • One has separate fields for area code and the rest with a hyphen: 222 and 333-4444
      • One has the whole thing with parenthesis, a space, and a hyphen as a string: (222) 333-4444

      The main reason for the discrepancy is not looking at what was used before or not understanding that they can always change the formatting when displayed so they don’t need to include the parenthesis or hyphens in the database itself.

      • pixxelkick@lemmy.world
        link
        fedilink
        arrow-up
        6
        arrow-down
        2
        ·
        1 day ago

        Okay but if that happens, musk is right that that’s a bit of a denormalization issue that mayne needs resolving.

        SSNs should be stored as strings without any hyphen or additional markup, nothing else.

        • Storing as a number can cause issues if you ever wanna support trailing zeros
        • any “styling” like hyphens should be handled by a consuming front end system, you want only the important data in the DB to maximize query times

        It’s more likely though it’s just a composite key…

        • snooggums@lemmy.world
          link
          fedilink
          English
          arrow-up
          15
          ·
          1 day ago

          This is not what he is actively doing though. He isn’t trying to improve databases.

          He is tearing down entire departments and agencies and using shit like this to justify it.

          • pixxelkick@lemmy.world
            link
            fedilink
            arrow-up
            4
            arrow-down
            2
            ·
            edit-2
            1 day ago

            Sure but my point is, if it was the scenario you described, then Elon would be talking about the right kind of denormalization problem.

            Denormalization due to multiple different tables storing their own copies of the same data, in different formats worse yet, would actually be the kind of problem he’s tweeting about.

            As opposed to a composite key on one table which means him being an ultracrepidarian, as usual.

            • snooggums@lemmy.world
              link
              fedilink
              English
              arrow-up
              9
              arrow-down
              1
              ·
              edit-2
              1 day ago

              Musk canceled the support for the long running Common Education Data Standards (CEDS) which is an initiative to promote better database standards and normalization for the states to address this kind of thing.

              It does not fucking matter if he is technically correct about one tiny detail because he is only using to to destroy, not to improve efficiency.

              • pixxelkick@lemmy.world
                link
                fedilink
                arrow-up
                3
                arrow-down
                3
                ·
                1 day ago

                I mean it matters here, as it’s literally the topic being actively discussed by the person who literally asked, so obviously it matters to them lol

                • snooggums@lemmy.world
                  link
                  fedilink
                  English
                  arrow-up
                  4
                  arrow-down
                  1
                  ·
                  1 day ago

                  The thing is, there are a large number of different reasons to store an SSN as a long int or a string depending on how it is used with the rest of the data. For a phone number, there can be a valid reason to store the area code separately to speed up data queries that narrow down by area code instead of all in one field and peeling it apart. There are also reasons to have additional, seemingly redundant, columns that can be used for optimizing searches or simplifying how queries are written.

                  A common one is that using 1 and 0 instead of Y an N is often faster for massively large dataset optimization, but isn’t as easily human readable.

                  There are complex reasons for choosing different approaches in a database, and the most important thing is generally consistency within the database. His point is meaningless without context beyond consistency, and the different government systems will have had different priorities, not to mention trying to update all of the databases to make them consistent is a MASSIVE fucking undertaking. And the systems can stay the way they are as long as they have APIs or other methods of transferring data that ARE normalized and consistent.

                  I have personally been working with reporting data to federal systems for 15 years as a semi knowledgeable technical person. This is what I do for a job. What he is saying is pointlessly small trivia used to justify tearing things down instead of improving them.

                  • Feathercrown@lemmy.world
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    arrow-down
                    1
                    ·
                    1 day ago

                    They weren’t justifying anything or making a moral statement, they were just discussing the technical question that was posed.