Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Bidouille & Développement Informatique
Agrandir
Bidouille & Développement Informatique
Les Mains dans le Cambouis
Bidouille & Développement Informatique
Actu 1 1
Articles
Médias 33 33
Tutoriels
Forums 326 326

Sujet Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 122 640 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
1871
Dans ce cas, pourquoi ne pas faire le test et l'assignation directement dans la routine plutôt que dans la main loop?
On se retrouve avec un "micro driver" qui, sur interruption, mémorise l'état de la pin et lève un flag pour indiquer au reste du programme que l'état de la pin a changé.
Le programme traite le changement d'état et baisse le flag.

Resistance is not futile... it's voltage divided by current

1872
Question à propos de SQL:

Je veux faire un truc truc style rézosocio.

J'ai une table accounts pour les comptes.

J'ai ensuite pensé à créer une table relationship pour mes accounts.

Après maintes recherche j'ai pu comprendre qu'il était préférable de créer également la relation inverse.
Et je me suis dit qu'il était préférable d'avoir toutes les infos de la relation (depuis quand?, statut de l'invitatio? etc...) et de la relation inverse dans une autre table plutôt que de dupliquer ces infos.

J'ai donc maintenant trois Tables:
- accounts,
- relationships,
- et relationships_informations pour toutes les infos concernant la relation

Après quelques galères(j'ai rarement utilisé SQL directement au boulot) je suis arrivé à ce résultat:


-- # FUNCTIONS
-- ###########
CREATE FUNCTION reverse_relationship_informations_not_exists(
  account_id_a INTEGER, account_id_b INTEGER
) RETURNS BOOLEAN AS $$
BEGIN
    RETURN EXISTS(
        SELECT
            1
        FROM relationships_informations
        WHERE rship_account_a_id = account_id_b AND rship_account_b_id = account_id_a
    );
END;
$$
LANGUAGE plpgsql;


-- # TABLES
-- ########
CREATE TABLE accounts(
    id INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
);

CREATE TABLE relationships(
    account_a_id INTEGER REFERENCES accounts (id),
    account_b_id INTEGER REFERENCES accounts (id),
    CONSTRAINT relationship_has_not_same_user CHECK (account_a_id != account_b_id),
    PRIMARY KEY (account_a_id, account_b_id)
);

CREATE TABLE relationships_informations(
    rship_account_a_id INTEGER,
    rship_account_b_id INTEGER,
    FOREIGN KEY (
        rship_account_a_id,
        rship_account_b_id
    ) REFERENCES relationships (account_a_id, account_b_id),
    reverse_rship_account_a_id INTEGER,
    reverse_rship_account_b_id INTEGER,
    FOREIGN KEY (
        reverse_rship_account_a_id,
        reverse_rship_account_b_id
    ) REFERENCES relationships (account_a_id, account_b_id),
    PRIMARY KEY(
        rship_account_a_id,
        rship_account_b_id,
        reverse_rship_account_a_id,
        reverse_rship_account_b_id
    ),

    CONSTRAINT relationships_has_same_users CHECK (
        rship_account_a_id = reverse_rship_account_b_id
        AND rship_account_b_id = reverse_rship_account_b_id
    ),
    CHECK (reverse_relationship_informations_not_exists(rship_account_a_id, rship_account_b_id)),

    -- Informations
    last_action_account_id INTEGER NOT NULL REFERENCES accounts (id),
    CONSTRAINT last_action_done_by_one_of_two_users CHECK(
        last_action_account_id IN (rship_account_a_id, rship_account_b_id)
    )
);

Je me retrouve avec une clé primaire composé de 4 colonnes pour la table relationships_informations, sachant que les 4 colonnes sont ni plus ni moins que deux id différents.
Et je me retrouve également obligé de vérifier que l'inverse de ma relationship_informations n'existe pas.

Y'a t'il un moyen plus intelligent de faire tout ca?

Pour infos j'utilise PostGres et j'ai enlevé pas mal de trucs inutiles concernant ma question.

[ Dernière édition du message le 20/02/2020 à 20:51:35 ]

1873
Je ne suis pas un expert en architecture de DB mais ça me semble super compliqué pour rien ton histoire.

Tu ne pourrais pas:

- avoir compte A / compte B / ID (un INT en auto increment utilisée pour la Primary Key) dans ta table relationship
- ajouter un contrainte d'unicité sur les deux colonnes compte A / compte B
- ajouter directement la contrainte de non existence de la relation inverse dans la table relationship
- mettre toutes infos sur la relation dans ta table relationship_informations en ayant pour seule contrainte l'ID de relationship en Foreign Key

Encore une fois je ne suis pas un spécialiste mais en procédant comme ça il me semble que tu vires une bonne partie de duplicata et de contraintes inutiles.
1874
Perso, identifier ton besoins en partant direct sur les CREATE TABLE ça me semble un peu compliqué.
Avant de modéliser, et pour notre (en tout cas la mienne) compréhension de ton objectif, je pense qu'il faudrait commencer par poser quelques questions basiques en mode texte du type :
- Un client peut-il avoir plusieurs fournisseurs ?
- Un fournisseur peut-il avoir plusieurs clients ?
- Un fournisseur à t'il plusieurs adresses ?
- etc...

ça permet d'identifier les relations 1,1 / 1,N / N,N pour ensuite construire un modèle relationnel...

[ Dernière édition du message le 20/02/2020 à 22:52:05 ]

1875
D’accord avec Krisfrom (et IPP aussi).


Citation :
Je me retrouve avec une clé primaire composé de 4 colonnes pour la table relationships_informations, sachant que les 4 colonnes sont ni plus ni moins que deux id différents.

Même si c’était déconseillé à l’époque de Merise, en pratique c’est bien d’ajouter et toujours avoir un identifiant entier unique dans une colonne. Ça simplifie pas mal d’opérations ; car j’imagine que tu vas exploiter ces tables depuis un langage de programmation classique.

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

1876
Ca va aussi être une question de performances le fait d'utiliser une clé primaire composite vs une ID en clé primaire et un index unique sur les x colonnes en contrainte. Avec un index tu vas beaucoup augmenter la vitesse de SELECT mais ralentir (pas dans les mêmes proportions) les INSERT et les UPDATE.

Dans la pratique les clé primaire composite je trouve que c'est pas mal de complications (ou de facilités en moins) pour pas grand chose.
1877
En outil gratos pas mal pour faire ton modèle entité-relation y'a ça : https://dbdiagram.io
1878
Bon jvais faire mon chieur de stack overflow (mais si vous savez celui a qui on demande comment faire ca en php et qui te repond fais le en c++ c'est plus simple), mais est ce que tu as une contrainte technique pour mettre ta "logique metier" dans ton sql ? Pourquoi ne pas mettre ta contrainte d'unité dans ton code ?

Bon si jamais tu es oblige d'utiliser que sql, comme ont dit les copaings tu fais un index (auto incremente, uuid, ce que tu veux) unique qui te sert de clef primaire. Et ensuite pour verifier l'unicite du couple de relation_id tu ecris un trigger sql.

https://dev.mysql.com/doc/refman/8.0/en/trigger-syntax.html

Tu specifies que ta fonction s'active quand tu fais un INSERT ou un UPDATE sur la table relation, et hop c'est réglé

Le chien aboie mais n'invente pas le fil à décongeler le beurre.

Les 6l6, des lampes qui nous éclairaient

[ Dernière édition du message le 21/02/2020 à 11:30:44 ]

1879
Pas super d'accord pour la contrainte d'unicité, justement à mon sens ça porte bien son nom et ça a plus sa place dans une contrainte SQL. C'est une garantie qu'aucune donnée incorrecte ne peut être insérée dans la DB (ce qui ne sera pas le cas si tu déplaces ça dans le code application).

Après je pense que la question fait débat, non ?

[ Dernière édition du message le 21/02/2020 à 11:51:02 ]

1880
Ben c'est une question de philosophie.

Tout laisser en sql c'est la solution la plus logique et naturelle. Mais bon un index a 4 colonnes c'est n'imp. Faire un select dessus ca doit être marrant.

Tout mettre dans le code serait une heresie aussi. Les contraintes d'unicite c'est une fonctionnalite de base des sgbd, ca serait débile de s'en priver surtout pour une solution moins robuste.

Jserais partisant de faire moitie moitie. Tu geres la relation dans un sens en sql, ca te fait une primary key a deux colonnes, et tu geres la relation inverse dans ton code ou en trigger.

Ou alors tu concatenes les primary key de ta relation pour en faire un id unique, comme ca ta primary key sera composee d'une seule colonne. Niveau perf c'est au top, tu gères la contrainte dans un sens, manque plus que de la gerer dans l'autre

Le chien aboie mais n'invente pas le fil à décongeler le beurre.

Les 6l6, des lampes qui nous éclairaient