Discussion :

[laurentSc]

Bonjour et bonne année à ceux qui me lisent !

Je m'interroge sur le choix de conception de ma classe Ticket. En gros, je lis des fichiers csv qui contiennent des enregistrements. Exemple :

Ticket ID+;Product Name+;Assigned Group+;Submit Date;Last Resolved Date;Summary;Priority;Status;Submit Month;Resolved month;Region;Country;Submitter;Customer Login ID;Organization;Incident Type;Reported Source

INC000006425994;Phenix;PHENIX_WW_L3;26/12/2018 13:20;17/01/2019 14:23;AR // Florida // Phenix // User unable to complete Phenix installation after Hard Disk change;Low;Closed;Earlier than Jan,19;Jan,19;ISMA;Argentina;SESA408981;SESA29353;International Operations;Incident;Phone

INC000006520388;AutoCAD;AUTOCAD_WW_L2;07/01/2019 14:08;12/02/2019 11:40;ar/florida/Autocad software license issue / Port blocked / communication issues;Medium;Closed;Earlier than Feb,19;Feb,19;ISMA;Argentina;SESA443857;SESA168129;Global Supply Chain;Incident;Direct Input

Donc chaque enregistrement a un identifiant. Il me semblerait plus naturel qu'un objet de cette classe porte sur un seul enregistrement. Si on fait ce choix, une instantiation aurait la forme new Ticket('INC000006425994');. Mais cela nécessite de connaître l'identifiant. Comment récupérer cette information ? Bref, quel serait une bonne conception ? (les 2 lignes blanches de l'exemple, je les ai rajoutées pour une meilleure lisibilité)

[rawsrc]

salut laurentSc,

meilleurs vœux et une santé de fer

Tu lis des fichiers csv, ok. La question est : une fois lus, tu en fais quoi ? Les données sont transférées vers une base de données ? Elles restent comme ça et tu te débrouilles avec des .csv en pagaille ?
Tu dois y apporter des mises à jour...

Bref, il faut être plus précis pour espérer avoir une réponse sur la conception de ton application.

[laurentSc]

Salut rawsrc,

j'ai vu sur mon téléphone que tu avais répondu mais attendu d'être sur mon PC pour la lire et y répondre (vu que le clavier est quand même plus confortable, et au cas où y ait besoin de faire des copier-coller)(et la mise en route est longue).

Donc oui, je mets les données de mes fichiers csv dans une bdd MySql. Pas besoin de les modifier, par contre, il faut pouvoir interroger la table. Voici sa DDL actuelle (que je peux changer si c'est mieux) :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
DROP TABLE IF EXISTS `tickets`;
CREATE TABLE IF NOT EXISTS `tickets` (
  `id` varchar(18) COLLATE utf8_bin NOT NULL,
  `Product_Name` varchar(25) COLLATE utf8_bin DEFAULT NULL,
  `Assigned_Group` varchar(30) COLLATE utf8_bin DEFAULT NULL,
  `Submitted_Date` datetime NOT NULL,
  `Last_Resolved_Date` datetime NOT NULL,
  `Summary` varchar(200) COLLATE utf8_bin NOT NULL,
  `Priority_Key` smallint(2) NOT NULL,
  `Status_Key` smallint(3) NOT NULL,
  `Region` varchar(10) COLLATE utf8_bin DEFAULT NULL,
  `Country` varchar(10) COLLATE utf8_bin DEFAULT NULL,
  `Submitter_SESA` int(6) NOT NULL,
  `Customer_SESA` int(6) NOT NULL,
  `Organization` varchar(30) COLLATE utf8_bin DEFAULT NULL,
  `Incident_Type` varchar(20) COLLATE utf8_bin DEFAULT NULL,
  `Reported_Source` varchar(20) COLLATE utf8_bin DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `Prioritytype` (`Priority_Key`),
  KEY `Statustype` (`Status_Key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

Il y a aussi 2 autres tables Priority et Status

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
DROP TABLE IF EXISTS `priority`;
CREATE TABLE IF NOT EXISTS `priority` (
  `id` smallint(2) NOT NULL AUTO_INCREMENT,
  `name` varchar(6) COLLATE utf8_bin NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
DROP TABLE IF EXISTS `status`;
CREATE TABLE IF NOT EXISTS `status` (
  `id` smallint(3) NOT NULL AUTO_INCREMENT,
  `name` varchar(13) COLLATE utf8_bin NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

[rawsrc]

salut,

tu dois viser la simplicité : est-ce que ton ticket a des méthodes particulières que tu devras coder mis à part les classiques accesseurs (set()get()) ?
Si la réponse est non, c'est juste des données extraites de la base pour être affichées, y'a même pas de classe à avoir, un simple tableau de tout, obtenu avec $stmt->fetchAll() suffit amplement.

Il faut éviter de tomber dans le travers de Java par exemple où tout doit être objet. PHP est fortiche avec les tableaux, donc quand il n'y a pas besoin de plus, reste simple.

[laurentSc]

Merci pour ta réponse, mais parfois, il y a d'autres méthodes, quand il s'agit par exemple d'extraire une information à partir de plusieurs attributs. Juste un exemple, mais y en a d'autres : la classe contient 2 attributs SESA_submitter et SESA_customer (SESA est l'identifiant chez Schneider). Déjà, il y a aussi la classe User :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
DROP TABLE IF EXISTS `users`;
CREATE TABLE IF NOT EXISTS `users` (
  `sesa` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `lastname` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `firstname` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `email` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `sesa_manager` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `id_site` tinyint(2) NOT NULL,
  PRIMARY KEY (`sesa`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

donc si on veut connaître le site du manager du submitter, on va pas stocker cette information. Si ça se trouve, le même submitter est l'auteur de 50 tickets, donc au lieu de stocker uniquement 50 fois le SESA, ça ferait 50*6 informations à stocker et même plus car du SESA du manager, viennent encore 6 informations, puis du manager du manager 6 autres, etc. En outre on veut aussi savoir si le submitter est le customer (j'avais pensé à une méthode isSubmitterSameThanSubmitter). Il est donc clair qu'il y a plus que de simples getters et setters, et qu'il faut donc faire de la POO...

[laurentSc]

Salut rawsrc,

hier, tu me disais de privilégier la simplicité ; soit. Cela dit, vu les besoins explicités dans le post précédent, je pense qu'on ne peut se passer de la POO. Qu'en penses-tu ? Et si tu es d'accord, vaut-il mieux une classe one_ticket ou une classe all_tickets ? Intuitivement, je choisirais plutôt one_ticket, mais après, pour s'adresser à un ticket, on a besoin de son identifiant, et pour les connaître, il faut lire une colonne entière de la bdd, ce qui ne colle pas avec le concept d'un objet qui serait un ticket unique. Donc, je reste avec ma question : quelle conception ?