PHP+MySQL multiple queries m.m.

[Dennis Munding]

Halløj!

Jeg har givet mig selv lidt af en nød at knække, som jeg håber en
venlig sjæl kan kaste lidt lys over.


Scenarie:

Fejring af medlemskab skal vises på hjemmeside med forudgående
nedtælling (her ligger nødden).
Flg. markeringer skal der tælles ned til:

1000 dage
1500 dage
2000 dage
2500 dage
3000 dage

Jeg kan sagtens hente data og lave nedtælling til én af ovenstående,
men så bliver resten ikke tjekket.

Ønsket scenarie/løsning:
Der søges i db efter kommende antal dage (ovenstående) inden for næste
7 dage.

Findes 3000 ikke gås videre til næste o.s.v.
Findes både eks. 3000 og 1500, skal der laves to (eller flere)
nedtællinger, som vises.

Giver det mening?

Har lavet en test-side, hvor nedtællingen tidsintervallerne vises:
https://1dpb.dk/?side=test2

Uret der kører p.t. tæller ned til næste 1000-dages jubilæum, men jeg
ved, at der samme dag er et 1500-dages jubilæum.

Alle konstruktive indspark modtages som vanligt med stor tak. :-)



--
Med venlig hilsen

Dennis Munding

[Jan Hansen]

Dennis Munding skrev:

> Fejring af medlemskab skal vises på hjemmeside med forudgående
> nedtælling (her ligger nødden).
> Flg. markeringer skal der tælles ned til:
>
> 1000 dage
> 1500 dage
> 2000 dage
> 2500 dage
> 3000 dage

Skulle jeg lave sådan noget, ville jeg lave en tabel med medlems-
numre og starttid for fejring af næste jubilæum.
Ved hver indlæsning af siden ville jeg hente de poster, hvor
starttid er mindre end nutid, og så gennemløbe posterne i en
løkke. Er forskellen mellem starttid og nutid mindre end 8 dage,
så lav et ur, ellers opdater posten med starttid for medlemmets
næste jubilæum.

> Uret der kører p.t. tæller ned til næste 1000-dages jubilæum, men jeg ved,
> at der samme dag er et 1500-dages jubilæum.

Betyder det, at du har fundet begge to, men at den anden nedtælling
overskriver den første?



--
mvh Jan.
Help Microsoft stamp out piracy. Give
Linux to a friend today!

[Dennis Munding]

Jan Hansen wrote:

> Dennis Munding skrev:
>
> > Fejring af medlemskab skal vises på hjemmeside med forudgående
> > nedtælling (her ligger nødden).
> > Flg. markeringer skal der tælles ned til:
> >
> > 1000 dage
> > 1500 dage
> > 2000 dage
> > 2500 dage
> > 3000 dage
>
> Skulle jeg lave sådan noget, ville jeg lave en tabel med medlems-
> numre og starttid for fejring af næste jubilæum.
> Ved hver indlæsning af siden ville jeg hente de poster, hvor
> starttid er mindre end nutid, og så gennemløbe posterne i en
> løkke. Er forskellen mellem starttid og nutid mindre end 8 dage,
> så lav et ur, ellers opdater posten med starttid for medlemmets
> næste jubilæum.

Det kunne sagtens være en løsning, hvis ikke jeg kan gøre det
anderledes.
Har alle data om medlemmer samlet i en tabel i forvejen, hvor jeg (med
hjælp herinde fra - stor tak) fik lavet noget lign.

Er ved at kigge på, om den kode muligvis kan genbruges til formålet.

> > Uret der kører p.t. tæller ned til næste 1000-dages jubilæum, men
> > jeg ved, at der samme dag er et 1500-dages jubilæum.
>
> Betyder det, at du har fundet begge to, men at den anden nedtælling
> overskriver den første?

Nej.
P.t. er koden kun lavet til at hente næste medlem med 1000-dages
jubilæum.

Men det er også en problematik, jeg har med i mine overvejelser. :-)


Tak for indsparket. :-)

[Arne Vajhøj]

On 10/4/2019 11:49 AM, Dennis Munding wrote:
> Scenarie:
>
> Fejring af medlemskab skal vises på hjemmeside med forudgående
> nedtælling (her ligger nødden).
> Flg. markeringer skal der tælles ned til:
>
> 1000 dage
> 1500 dage
> 2000 dage
> 2500 dage
> 3000 dage
>
> Jeg kan sagtens hente data og lave nedtælling til én af ovenstående,
> men så bliver resten ikke tjekket.
>
> Ønsket scenarie/løsning:
> Der søges i db efter kommende antal dage (ovenstående) inden for næste
> 7 dage.
>
> Findes 3000 ikke gås videre til næste o.s.v.
> Findes både eks. 3000 og 1500, skal der laves to (eller flere)
> nedtællinger, som vises.
>
> Giver det mening?
>
> Har lavet en test-side, hvor nedtællingen tidsintervallerne vises:
> https://1dpb.dk/?side=test2
>
> Uret der kører p.t. tæller ned til næste 1000-dages jubilæum, men jeg
> ved, at der samme dag er et 1500-dages jubilæum.

Jeg er ikke sikker på at jeg har forstået problemstillingen.

Men her er "noget" som måske kan inspirere:

mysql> CREATE TABLE members (
-> id INTEGER NOT NULL,
-> name VARCHAR(50) NOT NULL,
-> start DATE NOT NULL,
-> PRIMARY KEY(id)
-> );
Query OK, 0 rows affected (0.27 sec)

mysql> INSERT INTO members VALUES(1,'A A','20181009');
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO members VALUES(2,'B B','20181020');
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO members VALUES(3,'C C','20171008');
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO members VALUES(4,'D D','20171021');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM members;
+----+------+------------+
| id | name | start |
+----+------+------------+
| 1 | A A | 2018-10-09 |
| 2 | B B | 2018-10-20 |
| 3 | C C | 2017-10-08 |
| 4 | D D | 2017-10-21 |
+----+------+------------+
4 rows in set (0.00 sec)

mysql> SELECT '1 year' AS typ,name,365-DATEDIFF(NOW(),start) AS
missingdays FROM members WHERE DATEDIFF(NOW(),start) BETWEEN 365-7 AND 365
-> UNION
-> SELECT '2 years' AS typ,name,2*365-DATEDIFF(NOW(),start) AS
missingdays FROM members WHERE DATEDIFF(NOW(),start) BETWEEN 2*365-7 AND
2*365
-> ORDER BY missingdays;
+---------+------+-------------+
| typ | name | missingdays |
+---------+------+-------------+
| 2 years | C C | 3 |
| 1 year | A A | 4 |
+---------+------+-------------+
2 rows in set (0.00 sec)

Arne

[Dennis Munding]

Dit svar siger det modsatte... ;-)

> Men her er "noget" som måske kan inspirere:

[SNIP]

> mysql> SELECT '1 year' AS typ,name,365-DATEDIFF(NOW(),start) AS
> missingdays FROM members WHERE DATEDIFF(NOW(),start) BETWEEN 365-7
> AND 365 -> UNION -> SELECT '2 years' AS
> typ,name,2*365-DATEDIFF(NOW(),start) AS missingdays FROM members
> WHERE DATEDIFF(NOW(),start) BETWEEN 2*365-7 AND 2*365 -> ORDER BY
> missingdays; +---------+------+-------------+
> > typ | name | missingdays |
> +---------+------+-------------+
> > 2 years | C C | 3 |
> > 1 year | A A | 4 |
> +---------+------+-------------+
> 2 rows in set (0.00 sec)

Det er lige netop sådan et kald, jeg er på udkig efter, omend mine
"datoer" er indsat som timestamps i stedet for, da jeg synes, det er
nemmere at arbejde med.
Jeg vil straks gå i gang med at "lege" med dit forslag.

Tusind tak for dit indspark - igen. :-)

[Jan Hansen]

Dennis Munding skrev:

...

> > typ,name,2*365-DATEDIFF(NOW(),start) AS missingdays FROM members

...

> Det er lige netop sådan et kald, jeg er på udkig efter, omend mine
> "datoer" er indsat som timestamps i stedet for, da jeg synes, det er
> nemmere at arbejde med.
> Jeg vil straks gå i gang med at "lege" med dit forslag.

Sådan noget mysql har da også en modulo funktion,
<https://www.w3schools.com/sql/func_mysql_mod.asp>
så det må vel være til at finde dem, der holder N*500 dages
jubilæum indenfor næste uge, med noget i stil med

SELECT * FROM tabel WHERE MOD(DATEDIFF(NOW(),indmeldt),500) > 493

Hvordan det skal skrives i virkeligheden, har jeg vist ikke
så meget forstand på.

[Dennis Munding]

Jeg kan se, at jeg har formuleret mig lidt forkert...


Der skal kun vises ét nedtællingsur!

Nødden består i at søge efter jubilæer (se ovenstående antal dage)
inden for en uge og udvælge det jubilæum, der er tættest på.

Eks.: Et 2500-dages jubilæum om 6 dage og et 1000-dages jubilæum om 4
dage.

Her vil jeg gerne have returneret 1000-dages jubilæet, da det ligger
tættest på.

Alle datoer er indsat some time(): Eks. vil skrivende stund være =
1570359313 (ca.)


Det er udvælgelsen via SQL-kaldet, der giver mig grå hår.


Til orientering så er Arnes glimrende eksempel testet, men det
returnerer desværre ingenting (skulle være minimum 1 række)...


Håber det giver mere mening...?

[Arne Vajhøj]

On 10/6/2019 6:00 AM, Jan Hansen wrote:
> Dennis Munding skrev:
> ...
>>> typ,name,2*365-DATEDIFF(NOW(),start) AS missingdays FROM members
> ...
>
>> Det er lige netop sådan et kald, jeg er på udkig efter, omend mine
>> "datoer" er indsat som timestamps i stedet for, da jeg synes, det er
>> nemmere at arbejde med.
>> Jeg vil straks gå i gang med at "lege" med dit forslag.
>
> Sådan noget mysql har da også en modulo funktion,
> <https://www.w3schools.com/sql/func_mysql_mod.asp>
> så det må vel være til at finde dem, der holder N*500 dages
> jubilæum indenfor næste uge, med noget i stil med
>
> SELECT * FROM tabel WHERE MOD(DATEDIFF(NOW(),indmeldt),500) > 493

Hvis det kun er multipla af 500, så kan man bruge noget a la
(jeg bruger 365 i.s.f. 500 men ...):

mysql> SELECT ((DATEDIFF(NOW(),start) + 7) DIV 365) AS years,name,(365 -
DATEDIFF(NOW(),start) % 365) AS missingdays FROM members WHERE
DATEDIFF(NOW(),start) % 365 BETWEEN 365-7 AND 365 ORDER BY missingdays;
+-------+------+-------------+
| years | name | missingdays |
+-------+------+-------------+
| 2 | C C | 1 |
| 1 | A A | 2 |
+-------+------+-------------+

2 rows in set (0.00 sec)

Arne

[Dennis Munding]

Arne Vajhøj wrote:

> On 10/6/2019 6:00 AM, Jan Hansen wrote:
> > Dennis Munding skrev:
> > ...
> > > > typ,name,2*365-DATEDIFF(NOW(),start) AS missingdays FROM members
> > ...
> >
> > > Det er lige netop sådan et kald, jeg er på udkig efter, omend mine
> > > "datoer" er indsat som timestamps i stedet for, da jeg synes, det
> > > er nemmere at arbejde med.
> > > Jeg vil straks gå i gang med at "lege" med dit forslag.
> >
> > Sådan noget mysql har da også en modulo funktion,
> > <https://www.w3schools.com/sql/func_mysql_mod.asp>
> > så det må vel være til at finde dem, der holder N*500 dages
> > jubilæum indenfor næste uge, med noget i stil med
> >
> >SELECT * FROM tabel WHERE MOD(DATEDIFF(NOW(),indmeldt),500) > 493
>
> Hvis det kun er multipla af 500, så kan man bruge noget a la
> (jeg bruger 365 i.s.f. 500 men ...):

Både ja og nej - jeg starter blot ved 1000 og derefter for hver 500. :-)

> mysql> SELECT ((DATEDIFF(NOW(),start) + 7) DIV 365) AS
> years,name,(365 - DATEDIFF(NOW(),start) % 365) AS missingdays FROM
> members WHERE DATEDIFF(NOW(),start) % 365 BETWEEN 365-7 AND 365 ORDER
> BY missingdays; +-------+------+-------------+
> > years | name | missingdays |
> +-------+------+-------------+
> > 2 | C C | 1 |
> > 1 | A A | 2 |
> +-------+------+-------------+
> 2 rows in set (0.00 sec)

Jeg har så brug for at søge efter alle indekstal (1000, 1500, 2000,
2500 & 3000).

Dit eksempel fra tidl. gav intet, men jeg tester lige ovenstående.
Har ikke gennemskuet om det skyldes mine data eller om DATEDIFF ikke
kan håndtere data sat ind med phps funktion time() - eks.: 1570523565.

Svar på hvorfor, jeg ikke bruger datoer er, at jeg på et tidligere
tidspunkt fandt det nemmere at bruge ovenstående til udregning af
tidsintervaller (ret mig gerne).

Men måske det er tid til at studere MySQLs dato- og tidsfunktioner mere
intenst...


Vender tilbage med resultatet af min test. :-)

[Dennis Munding]

Dennis Munding wrote:

[SNIP]

>
> Har ikke gennemskuet om det skyldes mine data eller om DATEDIFF ikke
> kan håndtere data sat ind med phps funktion time() - eks.:
> 1570523565.

Har så lige konstateret, at det skyldes min metode at gemme data på...
:-/

Lader til, at jeg skal i gang med en del arbejde, for at lette mit
arbejde i fremtiden. :-)


Tak for dine indspark, Arne!
Om ikke andet, så har de tændt (endnu) et lys for mig. :-)

[Jan Hansen]

Dennis Munding skrev:

> Arne Vajhøj wrote:

> > mysql> SELECT ((DATEDIFF(NOW(),start) + 7) DIV 365) AS
> > years,name,(365 - DATEDIFF(NOW(),start) % 365) AS missingdays FROM
> > members WHERE DATEDIFF(NOW(),start) % 365 BETWEEN 365-7 AND 365 ORDER
> > BY missingdays; +-------+------+-------------+
> > > years | name | missingdays |
> > +-------+------+-------------+
> > > 2 | C C | 1 |
> > > 1 | A A | 2 |
> > +-------+------+-------------+
> > 2 rows in set (0.00 sec)
>
>
> Jeg har så brug for at søge efter alle indekstal (1000, 1500, 2000,
> 2500 & 3000).

Det er vel ikke så slemt. Hvis start er inmeldelsestidspunktet lavet med
php's time funktion, skal NOW() vel bare skiftes ud med et tilsvarende
php-tal, og så dele med sekunder pr. døgn. Dvs DATEDIFF(NOW(),start) skal
udskiftes med ($phpnutid-start)/86400, så passer resten.
Hvis du ikke vil have 500 dages jubilæum med, skal der nok bare trækkes 500
dage fra.

[Arne Vajhøj]

On 10/8/2019 4:35 AM, Dennis Munding wrote:

> Arne Vajhøj wrote:
>> mysql> SELECT ((DATEDIFF(NOW(),start) + 7) DIV 365) AS
>> years,name,(365 - DATEDIFF(NOW(),start) % 365) AS missingdays FROM
>> members WHERE DATEDIFF(NOW(),start) % 365 BETWEEN 365-7 AND 365 ORDER
>> BY missingdays; +-------+------+-------------+
>>> years | name | missingdays |
>> +-------+------+-------------+
>>> 2 | C C | 1 |
>>> 1 | A A | 2 |
>> +-------+------+-------------+
>> 2 rows in set (0.00 sec)
>
>
> Jeg har så brug for at søge efter alle indekstal (1000, 1500, 2000,
> 2500 & 3000).

Hvis du vil have antal dage fremfor antal enheder, så er det bare at
undlade DIV 365 (DIV 500 i dit tilfælde).

Og hvis du ikke vil have 500, saa bare tilfoej en:

... AND numdays IN (1000, 1500, 2000, 2500, 3000)

Arne

[Dennis Munding]

Arne Vajhøj wrote:

> SELECT ((DATEDIFF(NOW(),start) + 7) DIV 365) AS
> > > years,name,(365 - DATEDIFF(NOW(),start) % 365) AS missingdays FROM
> > > members WHERE DATEDIFF(NOW(),start) % 365 BETWEEN 365-7 AND 365
> > > ORDER BY missingdays;

Jeg giver lige et kombineret svar til både dig (Arne) og Jan Hansen:


Ovenstående forslag fungerer fint, hvis dato er indsat i rette format
(Y-m-d H:i:s) - men IKKE hvis det er indsat via phps time() -
(1519254000).


Hvis jeg kører ovenstående forespørgsel (med dit rigtige kolonnenavne)
direkte i phpMyAdmin (mysql brugerfladen), så får jeg flg. fejlmelding:

Warning: #1292 Incorrect datetime value: '1519254000'


Men kører jeg den på en nyoprettet tabel, hvor dato-formattet er ændret
til Y-m-d H:i:s, er der ingen fejlmelding og jeg får leveret data som
forventet.

Og det ligger i DATEDIFF funktionen, er jeg ret sikker på. Har forsøgt
med den funktion, jeg antog var den rette TIMESTAMPDIFF(), men heller
ingen succes der.


Men pyt! Jeg er blevet klogere og må bare trække i arbejdstøjet - det
giver jo også gevinst på lang sigt (håber jeg!). :-)

[Kim Ludvigsen]

Den 09/10/2019 kl. 16.22 skrev Dennis Munding:

> Warning: #1292 Incorrect datetime value: '1519254000'
>
>
> Men kører jeg den på en nyoprettet tabel, hvor dato-formattet er ændret
> til Y-m-d H:i:s, er der ingen fejlmelding og jeg får leveret data som
> forventet.
>

> Men pyt! Jeg er blevet klogere og må bare trække i arbejdstøjet - det
> giver jo også gevinst på lang sigt (håber jeg!). :-)

Du skulle gerne kunne lave et lille php-script, der henter
time()-værdien fra den gamle kolonne, og som så omdanner den til Y-m-d
H:i:s og indsætter den i den nye kolonne.

--
Mvh. Kim Ludvigsen

[Bertel Lund Hansen]

Kim Ludvigsen skrev:

> Du skulle gerne kunne lave et lille php-script, der henter
> time()-værdien fra den gamle kolonne, og som så omdanner den til Y-m-d
> H:i:s og indsætter den i den nye kolonne.

Det gøres med en funktion:

https://www.php.net/manual/en/function.strftime.php

$present_time=strftime('%Y-%m-%d %H:%M:%S');
$sometime=1519254000
$pretty_sometime=strftime('%Y-%m-%d %H:%M:%S',$sometime);

--
/Bertel

[Bertel Lund Hansen]

Bertel Lund Hansen skrev:

> https://www.php.net/manual/en/function.strftime.php

PS. strftime tager hensyn til locale. Det er der andre
time-funktioner der ikke gør.

--
/Bertel

[Dennis Munding]

Det er skam allerede klaret. :-)

Kørte et kort script igennem i går og oprettede en ny tabel til
testbrug.

Derfor ved jeg også med ret stor sikkerhed, at jeg er nødt til at
trække i arbejdstøjet og ændre mine procedurer fremadrettet, når det
drejer sig om tidspunkter. :-)

"Af skade bliver man klog - sjældent rig" - må være derfor, jeg ved så
meget mere i dag og er ludfattig... :-D