论坛每个帖子都有一个id号,从1开始增长,每新增一个帖子,id增1
假设帖子有三项,id,文本和时间
在后端,设计一个类Article,类里就有三项:id, text, time
现在这个id增长有两种思路:
1) 利用数据库自增,id设为主键,启动数据库自增
2) 页面帖子前,利用ajax请求,取得数据库当前最大号maxid,然后帖子的id设为maxid+1
2)的思路在高并发的时候有问题,有可能多人同时发帖从而ajax请求获得同样的id,然后他们的帖子都是id+1
但是如果是1),那么提交帖子的时候,帖子数据只有两项,text和time
这样的话,后端可能就要设计两个类
一个Article有三项,id, text, time,另一个只ArticleWithoutID有两项 text, time
因为前端用户如果查看帖子,那么后端就要返回id, text, time三项了
但是要设计两个类,又感觉怪怪的
大家怎么看?
Il doit être incrémenté côté serveur, sinon cela risque d'entrer en conflit.
Vous vous demandez peut-être pourquoi y a-t-il encore un conflit alors que j'ai pris le plus gros ? Si vous savez pourquoi les bases de données ont le concept de verrous, vous ne serez pas confus ici.
Lorsque la concurrence est grande, il peut s'agir de l'ID maximum obtenu en même temps. Lors de la soumission, l'une avant l'autre, cela entraînera l'échec d'une soumission.
De plus, les données front-end peuvent être falsifiées. En tant que programmeur, vous devez être sceptique quant aux données front-end et les vérifier
Les bases de données relationnelles peuvent définir des champs d'auto-incrémentation. Vous n'avez pas besoin de les spécifier lors de la saisie des données. La base de données gère elle-même l'ID d'auto-incrémentation
.Il est certain que la base de données des identifiants sera automatiquement incrémentée, et le front-end sera définitivement terminé si la concurrence est augmentée automatiquement. Cela ne fait aucun doute. Selon vos besoins, une classe peut tout à fait s’en charger, ce n’est pas si compliqué. (La solution d'ID auto-augmentante n'est pas bonne et n'est pas recommandée pour une concurrence élevée)
1. Le front-end envoie un objet article au serveur, y compris le texte et l'heure.
2. Le serveur stocke cet objet dans la base de données et la base de données incrémente automatiquement pour générer un identifiant. Il existe un traitement simultané du côté de la base de données.
3. Après un dépôt réussi, vous pouvez renvoyer l'intégralité des données ou l'identifiant au front-end.
4. Le front-end reçoit le message de réussite puis affiche la publication actuelle dans la liste. À ce stade, l'ID du message a été obtenu et peut être interrogé en fonction de l'ID.
====
Il est recommandé de générer des identifiants aléatoires sur le front-end, afin qu'une concurrence élevée du côté de la base de données n'entraîne pas de perte de performances due au problème d'auto-incrémentation.