Should I include the identifier as a property of objects stored in the database?

Question

I am creating a model for a web application. Tables have identifier fields as primary keys. My question is, should the identifier be defined as a property of the class?

I am sharing the problem because it is not clear to me whether I should consider the object as a representation of the structure of the table or whether I should consider the table as a means to save the object.

If I take the previous route, then the identifier becomes a property because it is part of the database table structure, however, if I use the latter approach, then the identifier can be considered as a fragment of metadata belonging to the database, which is not strictly part of the object model.

And then we reach the middle. Although the identifier is not actually part of the object I'm trying to model, I understand that the objects are retrieved and stored in the database and that the identifier of the object in the database is crucial for many system operations, so it would be useful to include it to facilitate interaction in which the identifier is used.

I am a solo developer, so I really like some other, perhaps more experienced, perspectives on this issue.

Answer 1

I guess, yes. All properties used for saving (including Hibernate, Ibatis) require that the identifier be in the object.

I understand your point of view on metadata, but an object from the database should really derive its identity in the same way as the database does - usually this is the primary key int. Then from this it is necessary to deduce the equality of the level of the object.

Sometimes you have primary keys that are compound, such as first name and last name (never do this!), In which case the primary key does not become “metadata” because it is part of the identifier of the object.

I usually reserve the object identifier column for the database. My opinion is that to use it for any client-oriented purpose (for example, use the primary key identifier as the client number), you will always shoot in the leg later.

Answer 2

If you have ever made changes to existing data (instead of adding only new data), you need a PC. Otherwise, you do not know which record should be changed in the database.

Answer 3

You must have an ID in the object. It is important.

The simplest example use case is the equality check:

public bool Equals(Object a, Object b) { return {a.ID = b.ID}; } 

Everything else is error prone and you will find it when you start receiving primary key violations or start overwriting existing data.

Counterargument:

Say you do not have an identifier in the object. As soon as you change the object and do not have its identifier from the database, how do you know which record will be updated?

---

At the same time, you should note that the operations mentioned are indeed private for the object instance, so the identifier does not have to be publicly available.

Answer 4

I include the identifier as a property. Having a simple unique identifier for an object is often very convenient, regardless of whether the object is stored in the database or not. It also makes your database queries simpler.

I would say that a table is just a means to save an object, but that does not mean that the object cannot have an identifier.

Answer 5

I really like that a table is a means to save an object, but even so, I always put identifiers on my objects for two main reasons:

• A database identifier is the most convenient way to uniquely identify an object, whether it be inside a class (if you use the serial / identification number identifier for each table) or everywhere (if you support a separate "ID-to-class mapping"). In the context of the web based applications it makes everything much easier and more efficient if your forms can simply specify <input type=hidden name=id value=12345> value = <input type=hidden name=id value=12345> instead of providing multiple fields, which together contain sufficient information to identify the target of the ekta (or, worse still, some circuit used to combine sufficient identifying information in one line, and then drop it back when the form is submitted).

• It must have an identifier in any case in order to maintain a reasonable database structure, and there is no reason not to disclose it.

Answer 6

Is the identifier in the object read-only or not? In my opinion, it should be read-only, because by definition the identifier will never change (since it uniquely identifies the record in the database).
This creates a problem when creating a new object (the identifier has not yet been set), save it in the database through a stored procedure that returns the newly created identifier, and then how to save it back to the object if the ID property is read-only?

Example:
Employee Employee = New Employee ();
employee.FirstName = "John";
employee.LastName = "Smith";

EmployeeDAL.Save (employee);

How the Save method (which actually connects to the database to save the new employee) updates the EmployeeId property in the Employee object if this property is read-only (which should be since EmployeeId will never change after it is created).