Comment les gens génèrent des entiers auto_incrimentation pour un utilisateur particulier dans une application SaaS typique?
Par exemple, les numéros de facturation de toutes les factures d'un utilisateur particulier doivent être auto_incrimentation et partir de 1. Le champ ID Rails ne peut pas être utilisé dans ce cas, car il est partagé parmi tous les utilisateurs.
Sur le dessus de ma tête, je pouvais compter toutes les factures qu'un utilisateur a, puis ajouter 1, mais quelqu'un connaît-il une meilleure solution?
6 Réponses :
Vous ne savez pas si ceci est la meilleure solution, mais vous pouvez stocker la dernière carte d'identité de la facture de l'utilisateur, puis utilisez-la pour déterminer l'ID suivant lors de la création d'une nouvelle facture pour cet utilisateur. Mais cette solution simple peut avoir des problèmes d'intégrité, devra faire attention.
Un attribut d'identification de facture appartient-il vraiment à un objet utilisateur? C'est une solution pragmatique mais pas une pour les puristes!
S'il y a une exigence selon laquelle les numéros de facturation sont simulentiels pour chaque utilisateur, alors "DerroiVoiCenChisUser" semble être étroitement associé à l'utilisateur.
Vous pouvez introduire une autre table associée à votre table "Utilisateurs" qui suit le numéro de facturation le plus récent d'un utilisateur. Cependant, la lecture de cette valeur entraînera une requête de base de données, de sorte que vous puissiez également obtenir un nombre de factures de l'utilisateur et l'ajouter une, comme vous l'avez suggéré. De toute façon, c'est une base de données frappée.
Si les numéros de facturation sont indépendants pour chaque utilisateur / client, il semble que le champ "LastInvoice" dans un magasin persistant (par exemple, un enregistrement DB) associé à l'utilisateur est assez inévitable. Cependant, cela pourrait conduire à une certaine contention au "dernier" numéro.
Est-ce vraiment important si nous envoyons des factures utilisateur 1, 2, 3 et 5 et ne leur envoient jamais la facture 4? Si vous pouvez détendre un peu l'exigence.
Si l'exigence est en réalité "Chaque numéro de facture doit être unique", nous pouvons examiner toutes les astuces de génération d'identifiant normale et celles-ci peuvent être assez efficaces.
S'assurer que les chiffres sont séquenciaux ajoute à la complexité, a-t-il ajouté à la prestation commerciale?
Oui, car il s'agit d'applications comptables, les numéros doivent être incrémentés automatiquement des entiers. Donc, il doit être assez solide aussi.
Une solution typique de toute base de données relativement pourrait être une table comme et une procédure stockée ou une requête SQL comme L'exigence fonctionnelle la plus importante que vous devriez vérifier est 1) exclure la procédure que vous utilisez pour obtenir de nouveaux numéros à partir des transactions de longue date. Supposons que Insérer dans la facture La procédure est une transaction à long terme avec une logique complexe côté serveur. Dans ce cas, vous acquérez d'abord un nouvel identifiant, puis dans une transaction séparée, insérez une nouvelle facture. Si la dernière transaction sera renvoyée, le numéro automatique ne diminuera pas. Mais user_invoice_numbers ne sera pas verrouillé pendant longtemps, de nombreux utilisateurs simultanés pourraient insérer des factures en même temps 2) N'utilisez pas de base de données transactionnelle traditionnelle pour stocker les données avec le dernier identifiant pour Chaque utilisateur. Lorsque vous devez conserver une liste simple des clés et des valeurs, de nombreux moteurs de base de données simples mais rapides peuvent faire ce travail pour vous. Liste des bases de données de clé / valeur < / a>. Probablement Memcached est le plus populaire. Dans le passé, j'ai vu les projets dans lesquels des stockages de clé / de valeur simples dans la mesure de la mise en œuvre à l'aide d'un registre Windows ou même d'un système de fichiers. Il y avait un répertoire où chaque nom de fichier était la clé et à l'intérieur de chaque fichier était le dernier identifiant. Et cette solution rugueuse était toujours mieux que l'utilisation de la table SQL, car les verrous ont été émis et libérés très rapidement et n'ont pas été impliqués dans la portée de la transaction. Eh bien, si ma proposition d'optimisation semble être surcpliquée pour votre projet. , oubliez cela maintenant, jusqu'à ce que vous rencontriez des problèmes de performance. Dans la plupart des projets, la méthode simple avec une table supplémentaire fonctionnera assez rapidement.
Je ne permettant pas d'éditer / de supprimer des factures, de sorte que cela simplifie le tout un peu (pas de lacunes). Mais je ne suis pas inquiet pour la performance maintenant. Merci
Memcached n'est pas un moteur de base de données: code.google.com/p/memcached/wiki / ... ?
Si vous utilisez une technologie pouvant entraîner des lacunes (comme il apparaît à partir de cette réponse, vous pouvez réduire la conflit en permettant de pré-obtenir des morceaux de la séquence. Le pire cas, vous perdez le morceau non utilisé.
Voulez-vous vraiment générer les ID de facturation dans un format incrémentiel? Cela ne pourrait-il pas ouvrir des trous de sécurité (où, si un utilisateur peut deviner la génération de numéro de facture, ils peuvent le modifier à la demande et conduire à une divulgation de l'information). Je générerais parfaitement les chiffres au hasard (et gardez une trace des nombres utilisés). Cela empêche également les collisions (les chances de collision sont réduites car les nombres sont alloués au hasard sur une plage).
Dans certains pays, ce n'est pas un nombre aléatoire juridique. Doit être séquentiel pour l'inspection du gouverneur.
Je viens de télécharger un gemme qui devrait résoudre votre besoin (quelques années de retard, c'est mieux que jamais!) :)