2

There are some cases where some of the data on a class of the domain model of an application seems to be dependent on the technology being used. One example of this is the following: suppose we are building one application in .NET such that there's the need of an Employee class. Suppose further that we are going to implement relational database, then the Employee has a primary key right? So that the classe would be something like

public class Employee 
{
     public int EmployeeID { get; set; }
     public string Name { get; set; }
     ... 
}

Now, that EmployeeID is dependent on the technology right? That's something that has to do with the way we've choose to persist our data. Should we write down a class independent of such things? If we do it this way, how should we work? I think I would need to map all the time between domain model and persistence specific types, but I'm not sure.

  • 1
    A relational database means more than just "ID"s. You can have a non-relational (flat file) database that uses "IDs". Thus, the presence of an "ID" doesn't imply anything about how the database is implemented. – Shoe Oct 18 '13 at 19:59
4

No. You need an ID whenever you want to uniquely identify something. My id card/passport has an ID that uniquely identifies me as a specific citizen. This has nothing to do with it being a piece of laminated paper.

Likewise, you will probably need an employee ID for organizational purposes. I encourage you to re-use this existing ID in a database schema, but this has nothing to do with databases. Your confusion may have arisen by implicitly using a memory location as an ID for most of your objects. However, memory locations are only unique at a certain point in time, on one single system. Therefore, they cant be used for serializations.

  • 1
    To add to this. Social Security Numbers for the U.S. came out in 1936, long before anyone thought about how these would be stored in a computer. – Shoe Oct 18 '13 at 20:22
  • Your answer is fine, but I think you are missing one point: in a case like the one above, the artificial EmployeeID would be probably introduced by many data modelers even when there was already a key like a passport ID, because a relational DB is the target system, and its best practice to use artificial keys for relationships instead of keys with business information. So the additional attribute is indeed technology dependend, at least, to a certain degree. – Doc Brown Oct 20 '13 at 7:08
2

Adding ID fields as primary keys (or also as foreign keys) is indeed a technological choice, since you would not need those for non-persistent data. In all OO languages I know of you can express relationships and references between objects without any artificial IDs, just by the way your programming languages offers references or pointers.

However, such an ID field will be helpful for lots of of different persistence mechanisms, so it is not dependent on a specific technology, only on the fact that you want to persist that data. In fact, using an ID field for relationships will be compatible with almost any persistence mechanism I know of. I remember that there had been some OO database systems in the past which tried to avoid the need of introducing additional ID fields, but using such a system and not introducing an ID field does make your program much more technology dependent than it gets with additional IDs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.