Creating an element - which scheme is better?

Question

Database

Hello.
There was a question of implementation of adding of a new element.
There are two options:
1. Create an element in the database with default values, get its id and display to the user a dialog for changing the properties of an existing element. Those. use the unified Create method.
The user fills in the fields, hits save, and we just use the Update method.
2. Do not create an element, show the user a dialog for changing properties.
The user fills in the fields, clicks "Save" and we use the Create method, in which we create an element, fill in the properties and save it in the database.
In the second option, after pressing the "Save" button, we will need to determine whether the element already exists or not.
And accordingly use the Create or Update method.
As if the extra branching is obtained.
How to be? Which scheme is better to choose

Answer 1

Somehow, in practice, something like 2 is a little more convenient, also with the combined functionality in the form of create or update in a "semi-implicit" form.
That is, if the object does not have a UID, then when saving it, this is a clear sign that it is "new" and you need to insert, yes - it means update
The first approach - it turns out to be two-step, with no guarantee of the presence of a second step. Roughly, the user wanted to create a new record - it was created with defaults, and then the user turned off the computer ...
As a result, a mountain of "empty records" will appear in the database.

Answer 2

A completely ideal option: the client generates a GUID and creates its own local entry for it. Further, immediately or by pressing the "save" button, synchronization with the server occurs. If the server does not have an entry with this GUID, then it is created. If there is, then access rights are checked and if everything is OK, then the changes are applied.
Why is it good:
1. All requests are idempotent (they can be safely repeated when the network is plugged).
2. Even a record not saved on the server has a unique identifier, which greatly simplifies the client logic.
3. The database is not littered with temporary records.
4. The logic of the client does not depend on the interaction protocol. You don't need to pre-create a post before editing it, you don't need to have two different work logics for posts with local IDs and those with server IDs. You simply create and work with records, and a separate replaceable adapter will provide interaction with the server.
5. GUID can be generated immediately human-readable. For example, for a blog it could be "vintage/2017-03-08T12:47:33". Please note that here we do not allow more than one post per second. Records created in the same second will be the same record.
6. You decide when and how to save data to the server and this is not imposed on you by the protocol.
7. You can already link to an entry that has not yet been saved. In fact, it will be created only after the first editing. Relevant for wiki projects, where you first create a link, then follow it, and only then fill it out.
What is bad about it:
1. through numbering is not possible. But it is rarely needed.
2. Identifiers are relatively long. On the other hand, they may contain some meta-information. For example - when, by whom and where it was created.
3. In the base for the GUID there must be an additional text column with a unique index. But most likely you will still have one when you start implementing [slug]( https://ru.wikipedia.org/wiki/Semantic_URL#Slug) for human intelligibility.

Answer 3

Try to change the idea of ​​programming a little. Think of everything as "sources of data".
Do you have a base - this is the source.
If you have a user - this is also a source, BUT temporary (!).
You need to pre-assign an identifier only if you need to save and then restore (permanently, not temporarily). You can assign an ID immediately from the user, and then for some reason match the base-user through the "external id" (which you assigned in the program in advance) - but the user himself does not save his data, he gives them to you, so he does not need an ID .
But the base of your ID is needed. Therefore, the user fills in the fields, presses save, and only then you check whether there was such a record in your source according to some criteria - for example, according to the character code "Grisha" - "grisha".
Why do programmers love numbers? Because they are unique within the world. In any encoding, in any language, lowercase or uppercase, Arabic numerals still look like Arabic numerals, and when searching for a match, the probability of finding a result is higher.
The user enters Russian text - either he will add an extra space, then he will write a non-printable character, then he will put a letter in English, which looks the same as Russian. When looking for a match, this will cause a new entry to be added without finding the old one.
To reduce this possibility, you:
a) in the ideal case, you tell him about the ID and let him select records from the list, and the list binds to the ID
b) you give the text he entered according to your own algorithm - cutting out extra spaces, and realizing that at the end you will get a more or less adequate string for verification - character code. But be careful - this algorithm adds another problem - the user will enter two spaces after the name - he probably expected it to be a different name, just two spaces. And when he sees "there is already a record" - he will have a question. It needs to be beaten with design, bans, and so on.
Thus, ID is a pointer (!) - as in life - indicates "in-there" - to the location of the record in a particular system. If you make an ID within your program (while it is running) - then in your database you will have to make a connection "start_time_program_ID_base_ID" - and this is a horror how many problems - working with time intervals.
Use the ID to number the entry in a particular source, and the second field, the external ID, to make a link to another source, and try not to forget that link over time.
For example, when working with the European system of SAP codes - we have the following problem. When a client buys a SAP company for himself (one million Euros, by the way), he is given a set of available IDs for his products. But there are more products than ID-shniks, it’s worth looking for, but there is no second million, and the seller excludes goods from sale, assigning new goods to old ID-shniks.
Nothing worse in programming can be when the ID exists only within a certain time interval. In this case, it ceases to be an external ID, creating dozens of many-to-many relationships and breaking the fate of programmers for the next month.
It's like that somewhere.
ps. https://docs.google.com/spreadsheets/d/1nxHJiDv6dR...