Welcome to Webmaster Hub

Inscrivez-vous maintenant pour avoir accès à toutes les fonctionnalités.

Une fois inscrit et identifié, vous pourrez contribuer à ce site en soumettant votre propre contenu ou en répondant au contenu existant. Vous pourrez éditer votre profil et communiquer avec les autres membres par messagerie privée.

Ce message sera supprimé une fois que vous serez identifié !

Aenoa

Fondateur
  • Compteur de contenus

    736
  • Inscrit(e) le

  • Dernière visite

  • Days Won

    4

Réputation sur la communauté

5 Neutre

À propos de Aenoa

  • Date de naissance 16 mai 1993

Pour me contacter

  • Skype
    Balkeyser

Information du profil

  • Genre
    Homme
  • Localisation
    Belgique
  • Société
    CloudRebelz BV/SA

Visiteurs récents du profil

4 797 visualisations du profil
  1. Bonjour, Un widget faisant? Uniquement des sondages? quel genre d'intégration? iframe? via injection JS ?
  2. Si vous pouvez changer la requête SQL, il suffit de modifier la colonne contenant la dernière modification avec NOW() (dépendant du type de colonne cela peut varier) Si vous ne pouvez pas, je ne vois que le Trigger pour changer cela
  3. Bonjour, la première effectue un SELECT * (toutes les colonnes) (que je déconseille, il vaut mieux spécifier les colonnes requises uniquement) et un IN (), qui doit donc parcourir toutes les données se trouvant dans la requête imbriquée, pour ensuite filtrer la requête primaire avec les données de l'imbriquée, et ce traitement prends du temps. La seconde ne possède pas de traitement, juste des valeurs brutes, ce qui réduit également le temps de traitement. Il doit simplement comparer une valeur avec une autre valeur, et non pas faire une récupération de valeur pour chaque enregistrement. Mon premier conseil serait avant-tout de changer votre SELECT * par le nom des colonnes requises, et si possible de faire une entrée de valeurs en brut. Ensuite, êtes-vous sûr que la colonne `villes`.`toto` contient une valeur de même type et identique à un enregistrement ? Aucun transtypage ne doit être fait par le serveur SQL ? Dans votre exemple, les données dans le IN devraient être toutes 38000 si l'on respecte la logique des noms, étant donné que votre requête récupère toutes les `toto` ayant comme `code_postal`= 38000, pour ensuite comparer la valeur de `toto` à `table1`.`cp` qui, d'après son nom, est aussi un code postal ? Cordialement,
  4. Bienvenue sur le hub!
  5. Bonjour, Tout d'abord, je ne peut que te suggérer de laisser tomber mysql_*. Ces méthodes sont déjà dépréciées en 5.X et totalement désactivées en 7.0, ce qui causera une armée de FATAL ERROR: MYSQL_FETCH_ARRAY IS NOT A FUNCTION et autres joyeusetés si ton projet venait à tourner dans un environnement 7.0. Ensuite, en effet, tu as la possibilité de re-sélectionner une colonne d'une table sous un autre nom grâce au mot clé AS. Comme indiqué par BlackPage, qui te propose une solution. Pour résumer: * Emploie une requête SQL similaire à ceci: SELECT test1.*, test2.*, test2.name AS t2name FROM test1 INNER JOIN test2 ON test2.test1_id = test1.id; * Le résultat sera semblable à celui-ci (utilisant des dummy-data) MariaDB [db]> select test1.*, test2.*, test2.name as t2name FROM test1 INNER JOIN test2 ON test2.test1_id = test1.id; +----+---------+--------+----+---------+----------+----------+---------+ | id | name | potato | id | name | pccotato | test1_id | t2name | +----+---------+--------+----+---------+----------+----------+---------+ | 3 | Test1-3 | C | 1 | Test2-1 | D | 3 | Test2-1 | | 2 | Test1-2 | B | 2 | Test2-2 | E | 2 | Test2-2 | | 1 | Test1-1 | A | 3 | Test2-3 | F | 1 | Test2-3 | +----+---------+--------+----+---------+----------+----------+---------+ 3 rows in set (0.01 sec) * N'utilise plus mysql_ en PHP. Privilégie la librairie PDO qui elle est supportée, et te permet de faire l'échappement des données bien plus facilement, en orienté objet. http://php.net/manual/en/ref.pdo-mysql.php * Utilise des préfixes ou suffixes dans tes colonnes, pour chaque table. Par exemple: MariaDB [db]> describe users; +--------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------------+--------------+------+-----+---------+-------+ | usr_id | int(11) | YES | | NULL | | | usr_name | varchar(30) | YES | | NULL | | | usr_email | varchar(240) | YES | | NULL | | | usr_password | varchar(150) | YES | | NULL | | +--------------+--------------+------+-----+---------+-------+ 4 rows in set (0.00 sec) MariaDB [db]> describe vehicles; +-----------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------+-------------+------+-----+---------+-------+ | veh_id | int(11) | YES | | NULL | | | veh_color | varchar(40) | YES | | NULL | | | veh_year | int(4) | YES | | NULL | | | veh_km | int(11) | YES | | NULL | | | veh_usr | int(11) | YES | | NULL | | +-----------+-------------+------+-----+---------+-------+ 5 rows in set (0.00 sec) Cela te permet, non seulement de toujours savoir à quelle table la colonne corresponds, mais cela évite tout doublon entre deux tables, le préfixe (ou suffixe) étant unique à une table. Dans mon exemple, j'utilise un préfixe, mais les gens ont plutôt tendance à utiliser un suffixe, tel que IDUSR, NAMEUSR, EMAILUSR, PASSWORDUSR, IDVEH, COLORVEH, YEARVEH, etc. Bonne journée!
  6. My bad, c'est 2000 https://support.google.com/a/answer/166852?hl=en
  7. Utilisant G Suite (nouveau nom pour G-apps) le quota d'email journalier est uniformisé avec gmail classique désormais, c'est 200 mails par jour max
  8. Bonsoir, Dans tous les projets PHP, il y a des mots de passe écrit en dur: Base de données, serveurs SMTP, clés secrètes d'API, et j'en passe. Ton code source, a moins que tu ne tripatouille fortement ton serveur web, ne sera pas accessible par n'importe qui le visitant, donc je peut te dire que cela ne pose pas de soucis Concernant le SHA1, c'est utile dans une certaine mesure. Du moins, le système de cryptage en soi. Tu as différents algorithmes de Cryptage (avec ajout d'un "sel", et décryptable si l'on a le sel) OU de hashage (indécodable par après). Tu aura des bases en ligne de plein de mots traduits de crypto à normal, mais également de mots hashés. C'est pour cela qu'utiliser un mot de passe fort (lettres Min/Maj, nombres, caractères spéciaux, ...) t'éloignera du dictionnaire et donc d'un éventuel mot de passe déjà encodé. Pour ton SMTP cela ne sert à rien d'hasher, car ton serveur SMTP recevrait une valeur hashée et dira "oui mais zee1g5re1ge563rg1erheh13 c'est pas motDePasseDeMamieGateaux ! je refuse la connexion tiens. Hop. A la trappe.". Tu devra donc l'envoyer "en clair" (lisible dans le code) mais cela ne posera pas de souci crois moi. Par contre, vérifie bien que le protocole utilisé emploie le TLS/SSL sinon la transaction entre ton serveur et le serveur SMTP, lui, ne sera pas sécurisé et un logiciel "man in the middle" pourrait récupérer ses informations et les exploiter.
  9. C'est si rare que ça de nos jours? J'espère que je ne suis pas en voie d'extinction ! Dans tous les cas, n'hésite pas à poser tes questions (dans les forums appropriés) et on tentera d'y répondre ! Bonne journée,
  10. Bienvenue sur le hub Jiizen
  11. Ravi de l'apprendre ! Bon début de journée
  12. Bonjour, Quelles données exactement souhaitez vous récupérer? Toutes ? J'ai remarqué que vous le convertissez en array, pourquoi ne pas utiliser une méthode telle que count pour savoir si location contient un seul ou plusieurs objets ? Ou éventuellement, vérifier avec une méthode d'array si une des clés sensée ne pas s'y trouver existe dans le nœud de location.
  13. Bienvenue sur le hub CodePromo24
  14. Bienvenue sur le hub FDF