Hello!

Uh oh Jason, if I understood you correctly, then your gut feeling is
correct: you shouldn't be doing things this way. Okay, your solution does
work, but imagine what would happen if you would have something like 1000
customers (or 1,000,000) instead of just three? A performance nightmare to
say the least!

It is often a requirement in applications to have some kind of counter that
runs from 1 to the number of items (customers in this case). However, unless
you have special requirements for example about sorting/item ordering, it is
often enough to only display those numbers on the client, but never store
them on the database.

That is, now your database has the Serial, ID and Name fields. What would
happen if you wouldn't store the Serial in the database at all? If you
choose this route, you could use the ID field (I'm assuming it is unique
among all customer records) as a key to delete data from the database, and
then you would simple recreate all Serials on the client's ListView. This
should be very fast.

So, the Serial number would only be a virtual value that you generate
on-the-fly in the code. With this solution, you would never need to delete
all customers from the database and then recreate them, since the database
wouldn't have the Serial field at all. You could however still sort by Name
and ID, which might be enough for you.

Does this make sense to you? Of course, this is a simplistic solution, but
without knowing more about your specific needs, it if difficult to suggest a
definite solution.