Gestion des dates par ID (php5 mysql5)

Gestion des dates par ID (php5 mysql5) - SQL/NoSQL - Programmation

Marsh Posté le 18-06-2008 à 12:42:51    

Bonjour,  
Je suis en train de creer de un site de vente de billets en ligne et j'ai un souci dans mes liaison a la table date.  
 
Je vous explique: j'ai externalisé toutes les dates dans une table date: ID, DATE.  
Et je les retrouve en faisant des INNER JOIN date ON (matable.ID_DATE = date.ID);  
 
par contre je bute vraiment sur un probleme:  
dans une table 'produit', j'ai plusieurs id dates (debut de vente, fin de vente, date de mise en ligne, date de fin de mise en ligne etc..) sur lequelles je doit faire des comparaisons, idéalement dans ma requete SELECT.  
mais comme je passe par les ID_DATE, je ne sais pas du tout comment m'y prendre, hormis imbriquer les requetes SELECT ce qui serait assez lourd.  
 
SELECT id from produit INNER JOIN [...] WHERE date.DATE1 <= $madate  
while ($result = $result_produit->fetch()){  
     SELECT id from produit INNER JOIN [...] WHERE date.DATE2 >= $madate AND produit.ID=$id  
etc.. etc..  
 
si quelqu'un a une idée, merci de votre aide.

Reply

Marsh Posté le 18-06-2008 à 12:42:51   

Reply

Marsh Posté le 18-06-2008 à 13:29:47    

Suffit de mettre tous tes inner join dans la meme requete, donc 4 joitures entre ta table produit et ta table date, en donnant un alias à tes tables date :o

 

SELECT id , date1.*, date2.*, date3.*, date4.* from produit
INNER JOIN date date1 ON produit.ID_DATE_DEBUT= date.ID
INNER JOIN date date2 ON produit.ID_DATE_FIN = date2.ID
INNER JOIN date date3 ON produit.ID_DATE_VENTE = date3.ID
INNER JOIN date date4 ON produit.ID_DATE_MISE_LIGNE = date4.ID
WHERE ...

 


Message édité par Alisteroid le 18-06-2008 à 13:33:40
Reply

Marsh Posté le 18-06-2008 à 14:38:34    

je te suis pas trop la..
 
si je fait:
SELECT * from produit  
INNER JOIN date ON produit.ID_DATE_DEBUT= date.ID
WHERE DATE='aaaammjj'
ca roule bien
 
mais si je cherche dans le where avec des comparaisons de dates, je vois pas comment organiser ca meme avec tous les inner join qui eux pointent uniquement sur des id et non pas sur les valeurs de date.

Reply

Marsh Posté le 18-06-2008 à 14:42:53    

sansadressefixe a écrit :

Je vous explique: j'ai externalisé toutes les dates dans une table date: ID, DATE.  
Et je les retrouve en faisant des INNER JOIN date ON (matable.ID_DATE = date.ID);  


Avant de répondre, une question : c'est quoi l'interêt ??? :??:
A la limite que tu aies besoin d'une table pour gérer les vacances/jours fériés/exceptions je veux bien... Mais de là à mettre toutes les dates je comprends pas...
Pourquoi ne pas utiliser directement les dates dans la table produit???


---------------
Software and cathedrals are much the same - first we build them, then we pray.
Reply

Marsh Posté le 18-06-2008 à 14:50:09    

tout simplement pour éviter les doublons de dates dans pleins de tables différentes.


Message édité par sansadressefixe le 18-06-2008 à 14:50:27
Reply

Marsh Posté le 18-06-2008 à 15:21:57    

... et c'est quoi l'intérêt ??? Nan parce que vraiment la je vois pas ... J'en vois strictement aucun.

 

Au contraire, tu t'imposes des contraintes supplémentaires, entre autre:

  • complication des requêtes à coup de jointure
  • impossibilité d'utiliser du default current timestamp
  • tri sur les champs 'date' incertain (tu peux pas garantir que la date id=1240 est supérieur à la date id=1210 )
  • nécessité d'alimenter la table des dates avec toutes les dates ( de 1900? à 2100 ?)

Message cité 1 fois
Message édité par anapajari le 18-06-2008 à 15:22:07

---------------
Software and cathedrals are much the same - first we build them, then we pray.
Reply

Marsh Posté le 18-06-2008 à 15:50:18    

je vais laisser tomber cette solution.. non pas parcequ'elle n'as pas d'interet, mais pour gagner du temps.
 
pour anapajari: si tu as un client dont tu retrouves les données partout, tu crées une table client, tu le colles pas partout?  
mais pour les dates faut pas?  
l'analyse a ses regles, et hormis le coup du tri sur les champ date id qui cause mon pb, les contraintes ci dessus n'existent pas ;)
 
select id from date where dt='aaaajjmm'
if (!result) {
   insert into date set dt=now() as date;
}
 
en tout cas encore merci.

Reply

Marsh Posté le 18-06-2008 à 16:00:30    

sansadressefixe a écrit :

je vais laisser tomber cette solution.. non pas parcequ'elle n'as pas d'interet, mais pour gagner du temps.


si tu le dis [:spamafote]

 
sansadressefixe a écrit :

pour anapajari: si tu as un client dont tu retrouves les données partout, tu crées une table client, tu le colles pas partout?


Si

sansadressefixe a écrit :

mais pour les dates faut pas?


Bin non ... comme je ne fais pas non plus une table avec les entiers et un id qui pointent sur eux.

sansadressefixe a écrit :

l'analyse a ses regles,


je serais ravi que tu me donnes la règle d'analyse (j'imagine en Merise) qui recommande de placer un type de base dans une table.

sansadressefixe a écrit :

et hormis le coup du tri sur les champ date id qui cause mon pb, les contraintes ci dessus n'existent pas ;)


Bin si, les jointures t'es obligé de te les coltiner, le default n'est toujours pas possible et l'insertion alimentation te coute 3 requêtes au lieu d'une

sansadressefixe a écrit :


select id from date where dt='aaaajjmm'
if (!result) {
   insert into date set dt=now() as date;
}
insert into tatable (champs1, ... , idDate) values (valeur1, ..., last_inserted_id)


au lieu de "insert into tatable (champs1, ... , date) values (valeur1, ... ,'aaaajjmm')

 

note: je cherche pas a faire mon chieur, mais juste à te montrer que ta solution t'apportait plus d'emmerde qu'autre chose.


Message édité par anapajari le 18-06-2008 à 16:01:05

---------------
Software and cathedrals are much the same - first we build them, then we pray.
Reply

Marsh Posté le 18-06-2008 à 16:08:09    

j'ai bien compris que tes arguments sont techniques et pas pour faire ton chieur.. no soucy ;)

Reply

Marsh Posté le 18-06-2008 à 17:32:09    

anapajari a écrit :

... et c'est quoi l'intérêt ??? Nan parce que vraiment la je vois pas ... J'en vois strictement aucun.
 
Au contraire, tu t'imposes des contraintes supplémentaires, entre autre:

  • complication des requêtes à coup de jointure
  • impossibilité d'utiliser du default current timestamp
  • tri sur les champs 'date' incertain (tu peux pas garantir que la date id=1240 est supérieur à la date id=1210 )
  • nécessité d'alimenter la table des dates avec toutes les dates ( de 1900? à 2100 ?)

J'avais même pas pensé à la débilité du modèle de données  [:flu1]  
Je suis d'accord avec toi, les dates on les mets directement dans des colonnes, c'est absurde de creer une table pour stocker uniquement les dates.
Et puis la prise de tête après pour faire de simples requètes  [:darkmavis tt]

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed