1

Currently working on a project where the user will create a JSON file that's then read into the system. The fields of one object can be referred to in another object for relevant operations. Something like this:

{
    employees: [
        {
            name: "Mark",
            department: "Accounting",
            join_date: "09-03-2001",
            id: "mark"
        },
        {
            name: "Brenda",
            department: "Human Resources"
            join_date: "10-12-2005",
            id: "brenda"
        },
        {
            name: "Charles",
            department: "Sales"
            join_date: "02-23-2011",
            id: "charles"
        }
    ],
    teams: [
        {
            team_lead_id: "mark",
            size: 10
        },
        {
            team_lead_id: "charles",
            size: 3
        }
    ]
}

The IDs are supposed to uniquely refer to the elements of a list and prevent the duplication of data, but I'm wondering if it makes sense to call them IDs since they are created by the user and their uniqueness needs to be validated.

user6490576
  • 67
  • 3

2 Answers2

1

Like any data, once validated it can be put "in the system". So once validated they are IDs are they not?

That said, I often define such things with "external IDs" or "external reference", usually combined with the ID of the system ("CRM", "Marketo", "System X" or whatever). If there's a chance the source of your people might be diverse you could consider that approach, i.e. after validating assign an internal, immutable ID & rewire the entities to use that.

LoztInSpace
  • 1,149
  • 6
  • 8
0

Natural IDs can be good, for example country codes, days of the week, things that don't change. Basically Enums

Here you have name field which duplicates the ID and begs the questions,

  • "what if I change my name?"
  • "what if there are two people with the same first name?"
  • "what if my name has non 'standard' characters?"
Ewan
  • 70,664
  • 5
  • 76
  • 161