Keresés: - MySQL topic - Mobilarena Hozzászólások

Legfrissebb anyagok

Mobilarena témák

PROHARDVER! témák

IT café témák

GAMEPOD témák

LOGOUT témák

Keresés

Új hozzászólás Aktív témák

#2169 bsh addikt instantwater #2168

Új Válasz 2021-05-10 10:23:42 #2169
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

bsh

addikt

válasz instantwater #2168 üzenetére

és az miért lesz úgy jobb?
#2167 bsh addikt instantwater #2166

Új Válasz 2021-05-10 09:23:26 #2167
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

bsh

addikt

válasz instantwater #2166 üzenetére

egy szállítólevél több több rendeléshez is tartozhat, mivel egy megrendelés kb. mindig több tételből áll (azaz több sor a táblában). ezeket ahogy egy nagyobb részmennyiség kész van és kiszállítható, csomagolják és egy fuvarlevéllel szállítják ki, de sokszor van olyan, hogy tételekre várni kell, ezért ezeket később egy másik fuvarlevéllel szállítják ki, és olyan is van, hogy mondjuk egy vagy több tételből csak X mennyiség van raktáron, ezeket kiszállítják, a maradékot meg később, amikro a hiányzó mennyiség beérkezik, akkor újabb szállítóval szállítják ki.
magyarán: egy szállítólevéhez több tétel is tartozhat (ez nem probléma), és egy tételhez tartozhat több szállítólevél is (jelen esetben max. 3)
próbáltam még olyat is, hogy:
... LEFT JOIN `szallitolevelek` sz ON m.Kisz1_flev = sz.id OR m.Kisz2_flev = sz.id OR m.Kisz3_flev = sz.id
de az úgy nemjó.
végülis működik a dolog, csak nem tudom, lehet-e "szebben".
#2165 bsh addikt instantwater #2164

Új Válasz 2021-05-10 07:30:22 #2165
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

bsh

addikt

válasz instantwater #2164 üzenetére

SELECT (...) m.Kisz1_menny, m.Kisz1_datum, sz1.szam as Kisz1_flev, sz1.hely as Kisz1_hely, m.Kisz1_szla, m.Kisz2_menny, m.Kisz2_datum, sz2.szam as Kisz2_flev, sz2.hely as Kisz2_hely, m.Kisz2_szla, m.Kisz3_menny, m.Kisz3_datum, sz3.szam as Kisz3_flev, sz3.hely as Kisz3_hely, m.Kisz3_szla FROM `megrendelesek` m LEFT JOIN `szallitolevelek` sz1 ON m.Kisz1_flev = sz1.id LEFT JOIN `szallitolevelek` sz2 ON m.Kisz2_flev = sz2.id LEFT JOIN `szallitolevelek` sz3 ON m.Kisz3_flev = sz3.id WHERE m.id > 0;
ez csak a kérdéses rész, a többit kitöröltem.
#2160 Keem1 veterán instantwater #2159

Új Válasz 2021-04-19 07:49:41 #2160
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Keem1

veterán

válasz instantwater #2159 üzenetére

Feltételezem, a kérdés nem valós
De ha mégis, attól függ, dilettáns módon csinálják-e. Sajnos még mindig látok olyan elvetemült, magát programozónak nevező embert, akinek a mínusz 1 hónap az, hogy levon 30 napot az aktuális dátumból
Pedig minden normális nyelv, a MySQL-t is beleértve tökéletesen csinálja.
PS C:\> (Get-Date("2021-03-31")).AddMonths(-1)
2021. február 28., vasárnap 0:00:00
PS C:\>
Szökőév:
PS C:\> (Get-Date("2024-03-31")).AddMonths(-1)
2024. február 29., csütörtök 0:00:00
PS C:\>
Viszont ha már amúgy is MySQL:
MariaDB [(none)]> SELECT DATE_SUB(STR_TO_DATE("2021-03-31", "%Y-%m-%d"),INTERVAL 1 MONTH);
+------------------------------------------------------------------+
| DATE_SUB(STR_TO_DATE("2021-03-31", "%Y-%m-%d"),INTERVAL 1 MONTH) |
+------------------------------------------------------------------+
| 2021-02-28 |
+------------------------------------------------------------------+
1 row in set (0.001 sec)
MariaDB [(none)]>
#2147 Panhard tag instantwater #2146

Új Válasz 2021-02-04 23:38:58 #2147
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Panhard

tag

válasz instantwater #2146 üzenetére

ai, date, time oszlopok voltak az adatbázisban. Az ai volt az auto increment, csak a rendezés miatt kellett, más haszna nem volt. Ez a három oszlop helyett lett a datetime, a másik három majd törölve lesz.
A datetime mezőben soha nem lesz két egyforma adat. De ha mégis valamiért feltöltődne, a primary key index megakadályozza.
A datetime oszlop tartalmát a date és time oszlopokból generáltam. Csak az a baj, hogy 2018 előtt nem figyeltem arra, hogy ne töltődjön fel két egyforma adat, így most van egy pár táblázat, ahol kb: másfél millió sorból van átlagban 500 duplikált. Azokat kellen törölnöm.
#2145 Panhard tag instantwater #2144

Új Válasz 2021-02-04 21:51:28 #2145
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Panhard

tag

válasz instantwater #2144 üzenetére

SELECT * FROM tabla WHERE datetime between '".$_GET["datum"]." 00:00:00' and '".$_GET["datum"]." 23:59:59' ORDER BY datetime DESC
Így működik.
Viszont lenne még egy kérdésem: Van pár tábla, ahol elég sok duplikált bejegyzés van a datetime oszlopban, és ezért nem engedi beállítani az indexet. Neten találtam pár megoldást a duplikált bejegyzések törlésére, de egyik sem működik. Erre tudsz valami működő megoldást?
#2143 Panhard tag instantwater #2140

Új Válasz 2021-02-04 19:00:14 #2143
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Panhard

tag

válasz instantwater #2140 üzenetére

"column BETWEEN dátum 00:00:00 AND dátum 23:59:59 ?"
Így működik. Köszönöm!
#2141 Panhard tag instantwater #2140

Új Válasz 2021-02-04 17:59:08 #2141
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Panhard

tag

válasz instantwater #2140 üzenetére

"column BETWEEN dátum 00:00:00 AND dátum 23:59:59 ?"
ezt nem értem.
Sajnos a tárhely szolgáltatóm nem használja a 8-as MySQL-t.
Vannak oszlopok is, amikben a dátum és idő van külön-külön, azokon az indexelés jól működik.
Gondoltam lecserélem őket egy datetime oszlopra. De akkor lehet marad ahogy van.
#2137 Agostino addikt instantwater #2136

Új Válasz 2020-12-11 08:29:54 #2137
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Agostino

addikt

válasz instantwater #2136 üzenetére

1064 syntax, azért kell kétszer mert - bár ezek csak kitalált táblanevek - mindkét tábla ugyan olyan adatokat tartalmaz, viszont ki kell egészítsék egymást. mert lehet, hogy az egyik táblában ugyan azon id-hez nincsen adat.
Ha nagyon minden kötél szakad 2 külön UPDATE utasításba lehetne szétszedni.

igen, ez van most