S'il existe une chance que vous en obteniez deux ajoutés avec la même date, vous aurez probablement besoin de :
SELECT balance FROM my_table ORDER BY date_added DESC,id DESC LIMIT 1;
(notez la clause 'descendante' sur les deux champs).
Cependant, vous devrez tenir compte de ce que vous voulez qu'il se passe lorsque quelqu'un ajoute une écriture d'ajustement du 2 février à laquelle est attribuée la date du 31 janvier pour vous assurer que le mois de janvier est complet. Il aura un ID supérieur à ceux réalisés le 1er février.
Généralement, les systèmes comptables ne fonctionnent qu'à la date. Peut-être pourriez-vous nous dire pourquoi l'ordre est important, nous pourrions faire d'autres suggestions.
En réponse à votre commentaire :
Je donnerais quelques conseils - c'est tout ce à quoi je pouvais penser immédiatement, je prodigue généralement beaucoup plus de "conseils" avec encore moins d'encouragements :-) Les deux premiers, plus liés à la base de données qu'à la comptabilité, sont :
Tout d'abord, faites tout en troisième forme normale et ne revenir que si et quand vous avez des problèmes de performances. Cela vous évitera beaucoup d'angoisse avec des données en double qui peuvent se déphaser. Même si vous revenez en arrière, utilisez des déclencheurs et d'autres fonctionnalités de SGBD pour vous assurer que les données ne se déphasent pas.
Par exemple, si vous souhaitez accélérer vos recherches sur une colonne last_name, vous pouvez créer une colonne upper_last_name (indexée) puis l'utiliser pour localiser les enregistrements correspondant à votre terme de recherche déjà en majuscules. Ce sera presque toujours plus rapide que la fonction par ligne upper(last_name) . Vous pouvez utiliser un déclencheur d'insertion/mise à jour pour vous assurer que le upper_last_name est toujours défini correctement et cela entraîne des frais uniquement lorsque le nom change, et non à chaque fois que vous effectuez une recherche.
Deuxièmement, ne dupliquez pas les données même entre les tables (comme votre schéma actuel) à moins que vous ne puissiez utiliser ces mêmes astuces de type déclencheur pour garantir que les données ne seront pas décalées. Que fera votre client si vous lui envoyez une facture dont le solde final ne correspond pas au solde de départ plus les achats ? Cela ne rendra pas votre entreprise très professionnelle :-)
Troisièmement (et c'est plus lié à la comptabilité), vous n'avez généralement pas à vous soucier du nombre de transactions lors du calcul des soldes à la volée. En effet, les systèmes comptables ont généralement une fonction de report à la fin de l'année qui réinitialise les soldes d'ouverture.
Ainsi, vous n'avez généralement jamais à traiter plus d'un an de données à la fois, ce qui, à moins que vous ne soyez le gouvernement américain ou Microsoft, n'est pas si onéreux.
