code

You should consider storing your Data in a proper Database, where each entry has a proper unique PrimaryKey. The job of the UI then is to allow the user "to choose the right primary key, without having to know of the primary key".

[@Christopher84: Expertly stated!  I really like the way you've expressed that!]

I feel like explaining a bit more about the point of a primary key -- sort of aDatabases 101, if you don't mind. There are many other excellent references on the topic, but I'll try and put a personal touch on it here for you, (surajit halder, the OP).

Suppose you have a class (table) with two fields: Name and City.  It should be apparent that you could have two objects (records) with the exact same data, but are still distinct.  For example, not only could there beSam from New York and Sam from New Jersey, but there could even be two (or more) people namedSam from New York.

Every object needs a way of being uniquely identified.  The first technique we are introduced to in programming is often thevariable.  We keep track of an object by which variable holds its reference.  And quickly we learn that we can have two variables referring to the same object.  This can happen because objects in memory are inherently unique because they are assigned an address (in .NET we know of this address indirectly through a tracking reference), and their virtual address in memory is often enough to keep it straight which object is which, provided the scope in which you want to keep them distinct is limited to one process in memory.  But they are only unique within the scope of that address space.  There could be another object of type Person with Name="Sam", and City="New York" running in another process on the same machine, and because it may reuse the same virtual address, the address alone is not enough to distinguish it from another one.  In memory, they will also have unique physical addresses but we don't get to know what those are, and they change around as pages are moved in memory.  Also, if we change the storage location of an object (such as saving it from memory to disk or transferring it to another computer) we lose the notion of its address in memory.  Instead we have the notion of its filename and perhaps the offset from the beginning of the file.  We typically don't get to choose those uniquely identifying addresses and offsets, and they change around.  So if we want to serialize our data, or have multiple processes or computers share this data, we have to have a way of choosing the unique identifier.

Rather than rely on this external identification of an object, we instead embed the identity of an object in a field that can be automatically generated, and comes with some guarantee that no two records will get the same identifier.  In its simplest form, this can be an integer that we increase every time we create a new record.  And to keep this all organized, every class (table) should have a non-user-facing field that is unique.  Let's call idID.  So now we have:

It doesn't matter where or how we store these objects, the unique ID is embedded in the data itself.  We do, however, need some kind of authority to hand out new unique identifiers.  It must work correctly when two records are created at the same time from different threads/processes/computers.  So somewhere somebody knows that the next unused ID is 4 and they must be consulted when committing a new record to the database.

This unique ID field is called a primary key.

If another table wants to refer to a Person, it should do so, by its ID (its primary key).  In other words, if we want to refer to a particular person, we can't say "Sam from New York",   we have to say, "Person with ID: 1".  This is particularly important when there are other tables that refer to a Person.  This forms arelationship between the tables.

e.g: A list of payments made by people for something.

Here we see that the first Sam from New York (ID=1) has made a payment of $300.  And the other Sam from New York (ID=3) has made two payments totalling $15.  Note that each payment, also has a unique ID in case we need to refer to one of those payments specifically.  The identifiers only have to be unique within a table, not universally.

So when you refer to any record, you must name both its Table and its primary key value.  The Table is often implicitly stored as part of the relationships of the database (the schema) but the primary key value is stored explicitly.  For example, in my example directly above, the Person field is implicitly known to be a record in thePerson table and the ID field is the primary key for the Payment table.

Another thing that may occur to you is that we may eventually run out of IDs.  Or that we may wish to reuse the IDs of deleted records.  This is where you really start to get into the benefits of proper databases.  If we delete person with ID 3, then we must also do something about records in other tables that refer to person with ID 3 because it no longer exists.  Sometimes we just never reuse ids.  People people may be deleted from a database, or even die, but they're never really erased from history, whereas a payment may be cancelled and deleted entirely, so if we ever want to do something like that, then we must enforce the relational integrity of our database by removing all occurrences of the primary key in related tables.  Databases can do this and it's just one of a multitude of complex data manipulation scenarios that are addressed by sophisticated relational databases.

So I strongly support your investigation into databases.  It's good to know how they work and the lessons you learn the best are the ones you discover for yourself.  But it's also good to look ahead a little bit and learn from what others have done -- learn some database theory and get some exposure to real databases to see some good solutions to universal issues inherent to data management.