Ú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

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