Bonjour à tous,

Je suis actuellement en train de re-faire notre système de transactions (comptables), et j'ai opté pour des écritures double du type: Donc une entrée est représentée par deux ligne de ma table...
sur mon premier exemple on peu voir que le compte 5116 est débité de 10 euros au profit du compte 123456.

bon sur le papier c'est ok (si vous avez des remarques je reste preneur )

Mais il y a un seul problème, c'est la génération de l'identifiant-unique-mais-pour-deux-lignes
Afin d'éviter les doublons, pour l'instant je le génère comme ceci: ce qui dans notre premier exemple donne: Le tout étant stocké sous forme de BIGINT dans ma table.

Donc plusieurs questions...
Premièrement je ne peux pas définir ma colonne ID comme étant unique, puisqu'il y a deux fois le même identifiant à chaque fois.
Est-ce qu'il serait préférable de passer en VARCHAR et de faire par exemple:
ligne 1 : xxxx-1
ligne 2 : xxxx-2
Et ensuite pour récupérer mes deux lignes, faire un LIKE 'xxxx-%'

Est-ce qu'il serait utile d'ajouter un autre ID en auto-increment?

Merci d'avance pour vos réponses

Salut !...

Perso, je réaliserait une table de 'transaction' avec un identifiant unique que j’utiliserai en ID de ta table actuelle !... et j'ajouterais un id-autoincrément, mais c'est plus pour rapidité/facilité de manipulation des données !...

Maintenant, ce n'est certainement pas une obligation et les solutions que tu proposes sont bonnes !... reste à voir au niveau de la rapidité de manipulation et fonction des opérations que tu as à effectuer !

il doit certainement y avoir des transactions qui comportent plus de 2 voir 10 comptes en contre-valeur !... je ne penses pas qu'une comptable face l'imputation d'un compte "caisse" à chaque tickets d'autoroutes !... et suivant, il peux donc y avoir un sacré paquet de données (plus de 255) dans ton ID ...
Mais simplement un cpt fournisseur, un compte matériels, et un compte TVA, ça fait déjà un bon gros ID

Réfléchis bien à tout ce qui pourrait mettre à mal ton système !...

@++

Hello,

il doit certainement y avoir des transactions qui comportent plus de 2 voir 10 comptes en contre-valeur !... je ne penses pas qu'une comptable face l'imputation d'un compte "caisse" à chaque tickets d'autoroutes !... et suivant, il peux donc y avoir un sacré paquet de données (plus de 255) dans ton ID ...
Mais simplement un cpt fournisseur, un compte matériels, et un compte TVA, ça fait déjà un bon gros ID

Je ne comprend pas trop l'histoire d'avoir "plus de 2 comptes en contre-valeur" ?
En fait le principe c'est que ça n'est pas de la comptabilité disons "commune", de notes de frais ou autres...
C'est un système relié aux utilisateurs de notre site.

En gros on a "seulement" 11 types de comptes...
Et les échanges sont de types 1<->1 => paiement externe <-> compte utilisateur, compte utilisateur <-> notre poche, etc...

Du coup il ne devrait pas y avoir d'imprévus si?

Bon et bien c'est la loose...
La gestion de l'ID ne fonctionne pas
la forme vient de montrer ses limites, sur un champs de type BIGINT...
Valeur maximale atteinte!

Du coup je ne sais plus trop comment prendre le problème :/

J'ai pensé à produire un hash md5 ou même sha* mais j'ai peur des collisions éventuelles... (même si il y une chance sur je ne sais combien de millions)
J'ai pensé également à gérer l'auto-increment moi même, en vérifiant au préalable le dernier identifiant en base, et en l'incrémentant de 1, mais pas moyen de "locker" la base le temps de faire l'insert, du coup il est possible de se retrouver avec un identifiant servant à plus de deux lignes...

Du coup je vous redemande votre aide à ce sujet... car je ne vois vraiment pas comment m'en sortir :/

J'ai pensé à produire un hash md5 ou même sha* mais j'ai peur des collisions éventuelles... (même si il y une chance sur je ne sais combien de millions)

ça doit plus que des millions... Cela dit sans dire si ton système est viable ou non, si tu as peur d'une collision due à un hash, tu peux toujours crypter.

Bonjour,

Alors j'ai résolu à priori ce problème pour l'instant...
J'ai procédé comme suit:
un ID en autoincrement (id_auto) et un champs id_transaction....
Ensuite pour faire mes enregistrement, je procède à la première insertion, je récupère mon id_auto,
je fait le second enregistrement (en indiquant l'id du premier) et je met à jour le premier...
Pas clair, ça donne ceci:

/// première requête d'insertion
$sql_insert1 = "INSERT INTO
                    `transactions` (
                        `id_auto`,
                        `id_transaction`,
                        ...
                      ) VALUES (
                        NULL,
                        0,
                        ...
                      )";

$insert1 = mysql_query($sql_insert1);

// récupération de l'id d'enregistrement
$id_insert1 = mysql_insert_id();

// update du champ id_transaction sur le premier enregistrement
$sql_update1 = 'UPDATE transactions SET id_transaction='.(int)$id_insert1.' WHERE id_auto = '.(int)$id_insert1;
$update1 = mysql_query($sql_update1);

// insertion de la deuxième ligne avec l'id_transaction déjà rempli
$sql_insert2 = "INSERT INTO
                `transactions` (
                    `id_auto`,
                    `id_transaction`,
                    ...
                  ) VALUES (
                    NULL,
                    ".(int)$id_insert1.",
                    ...
                  )";
$insert2 = mysql_query($sql_insert2);

Alors les questions à ce sujet:
-Y a t'il moyen d'éviter l'update du milieu via un genre de

INSERT INTO
                    `transactions` (
                        `id_auto`,
                        `id_transaction`,
                        ...
                      ) VALUES (
                        NULL,
                        id_auto,
                        ...
                      )

A priori non m'enfin sais-t-on jamais

Ensuite est-ce que ça vous parait sécurisé par rapport aux accès concurrents?
En gros si deux processus sont lancé exactement en même temps, est-ce que mysql_insert_id() est suffisamment lié à php, afin de récupérer le bon id?
Normalement oui?

En supplément j'ai un autre problème de comptage de résultats sur cette table... problème posté ici: sql-bases-donnees/comptage-enregistreme ... ml#p339740

Merci encore!