- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Hogy is néznek ki a gépeink?
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Dell asztali gépek
- Gaming notebook topik
- Vezetékes FEJhallgatók
- Asztrofotózás
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Azonnali VGA-s kérdések órája
- SSD kibeszélő
Hirdetés
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Samsung Univerzum: Így ismerhető meg a Galaxy AI bármilyen telefonon
ma A Try Galaxy webalkalmazás kontrollált környezetben mutatja meg, mit tud a One UI 6.1-es rendszer és a mesterséges intelligencia.
-
Premier előzetesen a Gray Zone Warfare
gp A mai naptól hivatalosan is elrajtol a játék korai kiadása PC-n.
Új hozzászólás Aktív témák
-
Drótszamár
őstag
válasz Peter Kiss #1400 üzenetére
Köszi, mindjárt kipróbálom a két mezős indexet.
Bejön a 10.000 adat. Ebből csinálok egy nagy SELECT-et, ami nézi a duplikációt, visszaad 0 és 10.000 sor közötti adatot attól függően, hogy van e dupla adat, vagy nincs. Amit visszaadott a SELECT, azokat a dátumokat kukázom a bejövő adatok közül (mivel duplák), és a maradék adatból csinálok egy nagy insert-et.
( 2b || !2b ) az itt a kérdés...
-
Drótszamár
őstag
válasz Peter Kiss #1400 üzenetére
Köszönöm, nagyon sokat gyorsult így az ellenőrzés. Az eddigi 3-5 percről lement kb 1s-re.
Tolok még a táblába teszt adatot, hogy lássam meddig bírja.Akkor a rossz indexelés volt a gond. Eddig úgy tudtam az a lényeg, hogy legyen az adott oszlopra index, de ezek szerint az adott WHERE feltételben szereplő mezőkre kell közös index.
( 2b || !2b ) az itt a kérdés...
-
válasz Drótszamár #1402 üzenetére
Az indexelés sokszor nem triviális, mert pl. ha a WHERE-ben 2 oszlopot fet az index, és pl. a SELECT-ben benne van az a 2 és még egy, akkor akár azt az egyet még mellé lehet tenni, és akkor tisztán indexből dolgozhat a cucc.
-
Drótszamár
őstag
válasz Peter Kiss #1403 üzenetére
Értem, köszi. Át fogom nézni a táblákat e szerint, hogy hol min lehet gyorsítani.
Az előző táblába tettem 800.000 rekordot, és egyelőre nincs lassulás. Köszönöm mégegyszer a segítséget.
( 2b || !2b ) az itt a kérdés...
-
biker
nagyúr
válasz Peter Kiss #1403 üzenetére
Sima select/where felallast meg latvanyosan nem is gyorsit az index, tapasztalat
Match/against eseten igazan latvanyos, no meg kovetelmeny is mert csak indexbol dolgozik150.000 soros 30+ oszlopos 250megas tabla keresese index nelkul 6 oszlopra (termek nev, leiras, cimke, kategoria megjegyzes stb) 15-25mp
Index es select 2-5mp
Index 6 oszlopra es match against utan 0,01-0,06 sec, max 0,15 sec, erre mar mehetett a live search result boxElektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
"Sima select/where felallast meg latvanyosan nem is gyorsit az index, tapasztalat"
He? Tehát, ha 3 DATETIME oszlopra szűrök, akkor végül is tök felesleges indexelni mondjuk egy 10 millió soros táblában, mert nem lesz látványos? Vagy az előző példa nem eléggé az?
MATCH() ... AGAINST FULLTEXT index esetén van, ez egy elég speciális cucc CHAR, VARCHAR és TEXT típusú oszlopokhoz, arról nem is beszélve, hogy 5.6 alatt nem lehet használni InnoDB táblákkal.
Plusz megjegyezném, hogy, ha van egy táblánk, ami 30+ oszloppal rendelkezik, akkor igazából egy tervezési hibával állunk szemben.
-
biker
nagyúr
válasz Peter Kiss #1406 üzenetére
akkor úgy mondom, nem eléggé látványosan gyorsít
egyébként igen, fulltext search miatt kell a match/against, és ez legalább relevancia szerint is tud rendezni, score-ra.
a 30+ oszlop nem tervezési hiba, max egy másik elv...ha van egy termék és 30 jellemzője, akkor mitől jobb 16 táblába szétpakolni és egy segédtáblába mondjuk összeszedni a jellemző><ID párokat, mint egy woocommerce féle webshop esetén?
nálam 150.000 termék 150.000 sor, a woocommerce a széthányt termékjellemzők miatt ugyan 4-5 oszloppal dolgozik, de 15.000 termék 670.000sort foglal el, és lassú mint egy halott disznó a jégen
[ Szerkesztve ]
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
A woocommerce sem azért lassú, mert van benne +2-3 tábla, hanem azért, mert nincs benne semmi sem optimalizálva. Szar index-ek lehetnek benne, lehet, hogy még FKEY-ek is hiányoznak, nehogy értelmesen el tudjon rajta menni az optimizer. Emellett nyilván benne van, hogy egyszerűen rosszul futtatják a lekérdezéseket benne (teszem azt termékenként és jellemzőként 1-1 lekérdezés és hasonlók).
Tervezési hiba, mert sem egy SQL szerver sem pedig a programnyelvek, technikák nem úgy vannak kitalálva, hogy ekkora adathalmazt így kezeljenek, gyakorlatilag ez azt jelenti, hogy lenne egy pl. egy sima PHP osztályod 30+ property-vel, ami fed egy sort (2*30+, ha külön getter-setter), ez nem kezelhető. Plusz olyan rugalmas így a cucc, mint az öntött vas.
-
biker
nagyúr
válasz Peter Kiss #1408 üzenetére
nem minden alkalmazás lényege a rugalmasság. ez is egy szempont, de nem mindenek feletti.
Ezen túl külön tábla csak azoknak jár, amit garantáltan többször felhasználunk és/vagy sűrűbben írjuk6olvassuk mint a termékek táblát (kategóriák, értékelések, statisztikák, kosárban lévő cikkek, korábban vásárolt cikkek, stb)
de mondd már meg, miért nem lehet egy táblában minden termék jellemző?
id, név, rövid leírás, hosszú leírás, cikkszám, szállítói kód, vonalkód, cimkék, kat_id, szállítási idő, áfa osztály, ára, akciós ára, akció eleje, akció vége, eredeti ára, és még fejből nem tudom, mik
te ezt szétdarabolnád? akkor minden darabolással egy redundáns termék_ID oszloppal hízlalod az adatbázist...martonx: nem arról volt szó, kinek az apukája erősebb, és kinek van több tapasztalata, hanem leírtam egy gyakorlati tapasztalatomat, ennyi.
[ Szerkesztve ]
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
Sk8erPeter
nagyúr
Csak gyorsan futottam át, amit írtál, de sztem a legrosszabb példákat írtad, például ha van egy adott termék, aminek az alapvető jellemzői nem változnak, de a szállítói adatok bőven változhatnak (például adott hónapban valamiért más a szállítója ugyanannak a terméknek), akkor azok miért kell, hogy ugyanott szerepeljenek, ahol a termék id, név, leírás? Vagy például az akció eleje és vége hogy lehetne már ugyanabban a táblában, sőt, ugyanabban a rekordban tárolható? Az ára, akciós ára meg aztán végképp állandóan változik... Szerinted nem épp az a feleslegesen redundáns, hogy a leírás ennyiszer szerepel a táblában? Vagy nem is értem az elgondolást.
Az a kijelentés meg, hogy az indexelések nem gyorsíthatnak jelentősen a rengeteg adatot tartalmazó táblában való keresésen, már inkább a vicces kategória szerintem.Sk8erPeter
-
Arra hivatkozni, hogy redundás lesz a termék ID-ja, az kicsit megmosolyogtató, egy SQL szervernek ez nem érdekes.
Termékek tábla:
id,
név,
rövid leírás,
hosszú leírás,
cikkszám,
vonalkód,
kat_id,
+ ki mikor módosította és még e mögé a tábla mögé még egy, ami minden sort ment triggerrel.Kellene egy szállítók, és a szállítókkal összerendelő:
szállítói kód,
szállítási idő,
termék_id
+ mettől meddig ki és mikor módosítottaCímkék nyilván nem kerülhetnek ide, szintén: címkék tábla + összerendelés + audit;
ÁFA osztály inkább tartozik a kategóriához, ha egy termék csak egy kategóriában lehet.
Egy termék árát szintén külön táblában vezetjük, hogy lássuk, mettől meddig mennyi volt, és ki módosította. (Nem beszélve arról, hogy már a jelenben beszélhetünk a jövőről.)
Az akciókat belekeverni talán a legdurvább, azt eleve ki kell vezetni, hogy milyen akcióink vannak, meddig tart és mi tartozik bele, nyilván a beállításai (melyik/minden termék hány százalékkal, stb) + az auditálási dolgok megint.
Csík így hirtelen pongyolán ezek jutottak eszembe. A gond az, hogy elég lenne csak egy "ki mit csinált" kérdést feltenni a te szerkezetedhez, fel kellene tenned a kezed, hogy izé, az úgy volt. .
-
fordfairlane
veterán
akkor minden darabolással egy redundáns termék_ID oszloppal hízlalod az adatbázist...
Mert jellemzően nem attól lesz redundáns az adatbázis, hogy túl sok tábla kerül bele, hanem attól, hogy túl kevés. Például ebben a példában a közös akciókban szereplő termékeket nem tudod összekötni egymással, mert termékenként tárolod az akciók összes attribútumát. Aztán mi van akkor, ha egy adott termék más szállítótól érkezik, hogyan kapcsolod a kettő tételt össze, ha a termék statisztikájára vagy kíváncsi?
Ez az egész téma ráadásul egy adatbázis tervezési tanfolyam első leckéi közé tartoznak. Normálformák, ilyesmi. Alapvető dolog relációs adatbázisoknál. Ez az egész aggódás, hogy túl sok a tábla akkor szokott előjönni, ha a JOIN-ok vagy az indexek használata már lassan és nehézkesen megy, ami adatbáziskezelésnél viszont alapvető dolog.
x gon' give it to ya
-
GG888
senior tag
Sziasztok!
MySQL-ben LIKE-on kívül valahogy még lehet vizsgálni hasonlóságot?
Egy kérdezős-válaszolós alkalmazás készítésével bíztak meg, viszont a magyar nyelvben egy kérdést szerencsére rengeteg féle képpen fel lehet tenni, erre kéne valami megoldás.Algoritmikus, bonyolultabb megoldások is érdekelnének, lényeg, hogy minél intelligensebb legyen a program.
pcmodding.hu | PC MODDING | Minden, ami modding, verhetetlen árak.
-
biker
nagyúr
mindenkinek egyszerre válaszolok, és le is zárom, mert látom, egyetlen célotok, fikázni, és most ehhez fáradt vagyok. sok lúd disznót győz.
de akkor szóljatok már az összes sap/nav/exact fejlesztőnek, hogy ne használjon táblákat, hogy az importáláshoz olyan excel táblákat kell kitölteni, amik AW-ig vagy ébb BQ-ig tartanak, ugye az hány oszlop???egyébként:
"ÁFA osztály inkább tartozik a kategóriához, ha egy termék csak egy kategóriában lehet."
Normális vagy? nézz meg egy könyves áruház áfa listáját, még a térképek közt is van 5 meg 27%-os áfás termék is, tehát lehet ugyanabban a kategóriában símán több áfás termék, termékenként kell áfa osztályt megadni, tehát szerinted az nyerő, hogy a termék adatbázisban egy oszlop áfa helyett legyen egy külön tábla két oszloppal termékID,áfakulcs, az hol értelmes már???tökéletesen vezetve van ki mikor és mit módosított, a naplóban, amit vezet a rendszer, nem pedig máshol
akciók pedig símán összeköthetők ak ezdő és vég időponton keresztül, nem is értem a felvetést, miért ne lehetne?
sőt, automatikusan kezeli a listaárat, az eredeti árat (ha akciós ár időszakban van) az akciós időszakot, ha mennyiségi akció van háy darab felett hány százalék kedvezményt ad a rendszer és sorolhatnám..szállítási idő sem szállítótól függ, mert adott szállítón belül is van raktári, külső raktáros de hamar érkező, és az amit ő is rendel, így adott szállító adott termékcsoportjában sem azonos az idő
A címkékben igazat adok, csak "az úgy volt...." hogy utólag lett kitalálva anno, hogy kell, és így maradt
"Csík így hirtelen pongyolán ezek jutottak eszembe. A gond az, hogy elég lenne csak egy "ki mit csinált" kérdést feltenni a te szerkezetedhez, fel kellene tenned a kezed, hogy izé, az úgy volt."
Símán megmondom, miután teljes naplózás van, mint mondtam.fogalmatok nincs arról, ezen kívül hány és milyen táblával dolgozik a rendszer, a szerkezetét sem látjátok, csak a bedobott példára ráugrotok, mert hosszú volt az ünnep és jó valakit piszkálni.
Nem érdekel, kérem kimoderálni innen az összes beírásomat, aztán legyetek boldogok, hogy nem zavarok itt
nem érdekel igazán.persze, tegyek egy oszlopot külön táblába, csak azért, hogy mellé tehessem még egyszer a termékid-t, mert az jó? indok nincs, csak ködösítés. hogy csak azért szar, mert 30 oszlopos.
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
Sk8erPeter
nagyúr
Kicsit túlságosan felkaptad a vizet, senkinek nem az volt a célja, hogy itt kifejezetten téged fikázzon, nem a személyedet érte kritika, hanem azt, amit állítottál, és a tervezési/fejlesztési elveket, amiket alkalmazol - szakmai témázás során ez nagyon nem mindegy. Kezdjük ott, hogy először Te állítottad azt egy korábbi javaslatra, hogy az indexelés nem gyorsít látványosan (bullshit), és pluszban remek példaként akartad bemutatni a 30+ oszlopos szerkezetet, erre kaptad a reakciót, hogy egyrészt baromság, hogy az indexelés ne gyorsíthatna látványosan (egyébként már csak azért sem értem az állításodat, mert a Te példádban is 10+ másodperceket javított csak az index már önmagában is, az nem elég látványos? Egészen másképp hangzik, ha azt állítod, hogy önmagában egy oszlopra tett index nem biztos, hogy elég, mert ez így igaz is.), másrészt a 30+ oszlopos táblánál már felmerül a gyanú, hogy tervezési hibáról van szó. Mindkét érv meg lett indokolva, alátámasztva, nem csak levegőben röpködő nagy szavak voltak. Többfelől is kaptál reakciót, mert igen megdöbbentő dolgot állítottál, ami pont szembemegy az alapvető adatbázis-normalizálási elvekkel; erre nem az a megfelelő reakció, hogy "sok lúd disznót győz" (mintha azt üzennéd, hogy nálad van az igazság, csak mi nem értjük) - több emberrel miért ne lehetne szakmai vitát folytatni?
De könyörgöm, egy dolgot magyarázz már meg, mert nagyon kitartasz mellette: komolyan úgy gondolod, hogy az a megfelelő adatbázis-tervezési elv, hogy a termék nevével, leírásával, ehhez hasonló alapvető (ritkán változó) paramétereivel egy táblába dobod be az akciós és aktuális árat, szállítót, hasonlókat? Szerinted az a baj, ha termék_id szerint össze vannak kapcsolva a különböző adatok, és ezáltal a termék_id többször is szerepelni fog? Ezt írod: "akciók pedig símán összeköthetők ak ezdő és vég időponton keresztül, nem is értem a felvetést, miért ne lehetne?". Ez alapján komolynak tűnik, akkor viszont alapvető tervezési elveket sértesz meg, pedig ahogy már írták, ezek szétbontása tényleg az első pár adatbázis-kezelési és -tervezési lecke között van, és akkor ezek szerint az nagyon kimaradt.
Ha meg félreérthető, amit írsz, akkor próbálj meg nem úgy írni, mintha csetelnél, mert nagyon zavaró.Egyébként ezzel kapcsolatos hsz.-eket nem kell OFF-ba tenni, mert szakmai, MySQL-t érintő vitáról van szó, épp, ami a topic címe.
Sk8erPeter
-
válasz Sk8erPeter #1416 üzenetére
A gond szerintem ott lesz, hogy gyakorlatilag a PH!-n is hirdet, és, ha valaki meglátja a megkérdőjelezést, akkor elbizonytalanodhat. Mi kérünk elnézést?
-
biker
nagyúr
válasz Peter Kiss #1417 üzenetére
Kérlek mutasd meg a hirdetésem, mert az aláírásban lévő szöveg, ami nem is link, körítés nélkül nehezen értelmezhető szolgáltatás hirdetésként, fikaverseny győztese cím ezennel a tied
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
biker
nagyúr
válasz Sk8erPeter #1416 üzenetére
"akciók pedig símán összeköthetők ak ezdő és vég időponton keresztül, nem is értem a felvetést, miért ne lehetne?". Ez alapján komolynak tűnik, akkor viszont alapvető tervezési elveket sértesz meg, pedig ahogy már írták, ezek szétbontása tényleg az első pár adatbázis-kezelési és -tervezési lecke között van, és akkor ezek szerint az nagyon kimaradt.
Ne viccelj, miért ne lehetne kigyűjteni egy selecttel az összes terméket ami mondjuk a köv 10 napban akciós ?
Ugyanazzal a lekérdezéssel lehet, mint amivel külön tábla esetén tennéd, és joinolnád az id-khez a termékeket a termékek táblából, nem?Itt az az alap tézis részetekről, csak rossz lehet mert sok oszlopa van
Pont ugyanúgy és ugyanaz elvégezhető így isAz echo "hello world"; is leírható így is
<?php
class myClass
{
function sayHello()
{
echo "Hello there!";
}
}
?><?php
require_once('myClass.php');
$myClass = new myClass();
$myClass->sayHello();
?>
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
fordfairlane
veterán
válasz Peter Kiss #1417 üzenetére
Mi kérünk elnézést?
Jah, hát lassan ott tart a dolog.
x gon' give it to ya
-
fordfairlane
veterán
Itt az az alap tézis részetekről, csak rossz lehet mert sok oszlopa van
Nem az oszlopok számával önmagával van a probléma, hanem azzal a fajta adatszerkezettel, amivel letárolásra kerülnek a termékhez kapcsolódó adatok.
Jelen példa esetében a termékhez kapcsolódik egy akció, aminek vannak attribútumai, például kezdeti-, és végidőpontja. Ezt tranzitív függésnek hívják, és a probléma nem az, hogy egyben van, mert lekérdezés szempontjából ez az adatszerkezet kvázi "kész" van, csak ki kell íratni a mezőket, amire épp szükség van
A probléma a következők lehetnek:
1. beszúrási anomália
Addig nem tudsz létrehozni akciót, amíg nincs készen felvíve legalább egy termék, amihez hozzácsatolod.
2. módosítási anomália
Az akciók paramétereit az összes termékrekordon egyszerre kell végrehajtanod, különben inkonzisztens lesz az adatbázis (új akció keletkezik a semmiből, ha valami probléma folytán nem hajtódik végre minden termék rekordján a módosítás)
3. törlési anomália
Ha törölsz minden terméket, akkor az akció is törlődik magától. (Mellékhatás, amit ebben az adatszerkezetben nem tudsz megkerülni)
Ezek olyan nem várt mellékhatásai, amik problémát okozhatnak minden ilyennél, nem csak az akcióknál.
A normalizálás erről szól. Nem véletlenül találták ki több évtizede, és használják mindenhol.
És igen, ez azt eredményezheti, hogy akár egy mezőt is külön táblába kell tenni adott esetben, majd ellátni a megfelelő foreign key-jel, ( és persze erre majdhogynem automatikusan mehet rá az index, így a JOIN gyakorlatilag "költségmentes" lesz). Viszont így az adatszerkezet sokkal karbantarthatóbb lesz.
[ Szerkesztve ]
x gon' give it to ya
-
biker
nagyúr
válasz fordfairlane #1421 üzenetére
az alapoktol zavaros amit irsz
Egyaltalan Te erted?1: letrehozok egy termekre vonatkozo akciot mikor nincs ilyen termekem? Hogy? Miert? Es ha ez kulon tablaban van mitol jobb, ha nincs ilyen termek?
Ugyanez arra, hogy ha torlom a termeket akkor megmarad az akcioEz szamomra ertelmezhetetlen
Mert hiaba irom ki holnaptol -10% a sörre ha nincs sör
Ezt ertelmes, eletszeru peldan mutasd be kerlek
Mert nalunk ugy megy, hogy kitalaljuk melyik termekunk mettol meddig akcios, nem pedig kitalaljuk holnap valami akcios lesz, de nem tudom mi
[ Szerkesztve ]
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
fordfairlane
veterán
Mert nalunk ugy megy, hogy kitalaljuk melyik termekunk mettol meddig akcios, nem pedig kitalaljuk holnap valami akcios lesz, de nem tudom mi
Máshol meg másként megy. Minnél nagyobb a kereskedelmi egység, annál inkább jellemnző, hogy az akciózás termékcsoportosító módon kerül kivitelezésre. Például úgy, hogy nem egy termék lesz akciós, hanem egy termékek csoportja. Majd ebbe az akcióba bevonódhat újabb termék. Aztán az akció meghosszabbodhat. Aztán kerül bele újabb termék. Aztán kikerülhet belőle bizonyos termék, mert pl. elfogy. Aztán kiderülhet, hogy túl jól sikerült az akció, ezért az összes termékre csökkenteni kell a mértékét. Vagy épp ellenkezőleg, nem sikerült túl jól, sok termék továbbra is készleten, megromlik pl. ezért növelni kell a kedvezményt az összes terméken.
x gon' give it to ya
-
fordfairlane
veterán
Egyébként nem arra akartam helyezni a hangsúlyt, hogy az üzletpolitika mit kíván meg, hanem hogy melyik a rugalmasabb adatszerkezet. Ez egyébként nagyon régi technika. A relációs adatbázisok, és a különféle normálformák használata nem épp mai találmány.
x gon' give it to ya
-
biker
nagyúr
válasz fordfairlane #1423 üzenetére
így lehet értelme, de ez nem webshop kategória már, hanem VIR, egy mezei webshopnál ez már ágyúval verébre.
Most hirtelen néztem 3 közkeletű webshop motort, mindenhol a terméklapon állítom be az akciós időszakot és árat, nem találok külön ilyen bonyolult megoldáson alapuló akció szerkesztéses dolgot. vagy csak elkerülte a figyelmem.Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
biker
nagyúr
válasz fordfairlane #1424 üzenetére
átlag usernek ez amit írsz bonyolultabb, mert neki az kell, ez a termék holnap ennyibe kerül, ma meg annyiba, nem akar külön akciót definiálni, majd termékkört dfiniálni, abba terméket bevonni, stb
Ugyanez a cimkére, igen, ez a helyes út
termékid;termék
1;alma
2;körtecimkeID;cimke
1;piros
2;sárga
3;lédús
4;édescimke_termék kapcsolatok
termékID;cimkeID
1;1
1;4
2;2
2;3
2;4pl, de ekkor a user ha később kedve szottyan átírni a pirost vörösre, mert a retek nem piros hanem vörös, akkor minden alma is vörös lesz, és idegeskedik majd, sajnos, van ilyen réteg, úgy a userek 70-80%-a
nekik jobb ha símán ömleszted és nem külön cimke kezelés, mert cak zavarja a sok cimkeElektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
fordfairlane
veterán
Igazad van, nem jó példa. Ágyúval verébre. Ez inkább egy-egy feltételes kapcsolat lehet a legtöbb esetben, vagyis hogy a termékek egy része akciós, a többi nem. Mondjuk ebben az esetben is külön táblába tenném az akcióparamétereket, mert már megszoktam, hogy a "dolgokat", amiknek önálló attribútumai vannak (kezdet - vége), önálló objektumoként kezelem, még akkor is, ha csak egy kapcsolódó rekord lehet egy termékhez. Aztán valami ORM könyvtár elvégzi a betöltést-mentést-rekordösszefűzést.
[ Szerkesztve ]
x gon' give it to ya
-
Sk8erPeter
nagyúr
"Ne viccelj, miért ne lehetne kigyűjteni egy selecttel az összes terméket ami mondjuk a köv 10 napban akciós ?"
Senki nem mondta, hogy ne lehetne kigyűjteni, de ezek szerint még mindig nem érted, hogy mi a probléma azzal az elvvel, amit alkalmazol, ami mondjuk elég szomorú. Tényleg ennyire nem vágod az alapvető normalizálási elveket?
A lényeg: az akciós és aktuális árnak, aktuális szállítónak és egyebeknek semmi keresnivalójuk ugyanabban a táblában, amiben a termékek alapvető, ritkán változó paramétereit tárolod. Most ugyanazt mondtam el másként, mint amit már korábban is leírtam."Itt az az alap tézis részetekről, csak rossz lehet mert sok oszlopa van"
Kezd tényleg fárasztó lenni. Tudtommal elég régóta vagy fejlesztő, ehhez képest bevált alapelveken vitatkozol, mint aki az évek során jól begubózott, és a saját jól megszokott tervezési elvein kívül mást nem is hajlandó elfogadni, kritikát meg aztán végképp nem. Pedig ha előveszel akármilyen jobbféle adatbázis-kezelős könyvet, ami a kezdő szinttől indít, hidd el, hogy ezekkel az elvekkel elég hamar találkozol...
fordfairlane amúgy előttem már leírta nagyvonalakban az alapvető problémákat, de erre azt reagáltad neki, hogy "az alapoktol zavaros amit irsz Egyaltalan Te erted?" - most azon kezdtél el kattogni, hogy de hiszen az akció termék nélkül nem is létezhet, de azon még mindig nem gondolkoztál el, hogy vajon miért állítjuk többen is már régóta, hogy alapvető, nem változó paraméterek egyszerűen nem tehetők egy táblába állandóan változó - és például megőrizendő - paraméterekkel (ismét leírtam, hátha átjön), mert az rengeteg kellemetlen problémát szül (átnevezési, törlési, beszúrási probléma, esetleges inkonzisztencia, és az összes többi dolog, amiről már vakerásztunk, vagy amiről még nem). Megdöbbentő ez a vita. Olyan, mintha nem lenne tiszta számodra, mire valók a kapcsolótáblák, az idegen kulcsok, egyáltalán mik azok a normálformák, miért használják manapság ezeket... Ha nem tudod, akkor inkább kérdezz vissza, miért is lenne jobb ezeket használni, de ne úgy pattintsd le magadról az egész témát, mintha még mi lennénk a korlátoltak, hogy nem fogjuk fel, hogy a Te szerkezeted milyen csodálatos (nem az). Kissé türelmetlenné teszed az embert ezzel a stílussal.=====
(#1417) Athlon64+ :
"Mi kérünk elnézést? "
Jaja, nagyon úgy tűnik. Ne haragudj, biker.Sk8erPeter
-
biker
nagyúr
válasz Sk8erPeter #1428 üzenetére
ok
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
fordfairlane
veterán
válasz Sk8erPeter #1428 üzenetére
A lényeg: az akciós és aktuális árnak, aktuális szállítónak és egyebeknek semmi keresnivalójuk ugyanabban a táblában, amiben a termékek alapvető, ritkán változó paramétereit tárolod.
Ha ez a tranzitív függőség bennmarad, az még nem olyan nagy tragédia ( 3NF helyett csak 2NF ).
x gon' give it to ya
-
Sk8erPeter
nagyúr
válasz fordfairlane #1431 üzenetére
Ja, de érted, ez tipikusan olyan, hogy valamelyik pontnál kénytelen lesz elkezdeni gányolni, mert nem kényelmesen, külön kezelhetők ezek az alapvetően nem szorosan egybetartozó adatok (bár tény, olyan szempontból "kényelmes", hogy nem kell joinolni, így talán a query rövidebb lesz, de kábé itt meg is áll az előnye), ezért sokkal jobban jár, ha különválasztja.
Sk8erPeter
-
fordfairlane
veterán
válasz Sk8erPeter #1432 üzenetére
Utólag refaktorálható az adatszerkezet. Egyébként az ilyen függőséget nem kell feltétlenül tankönyvszerűen kezelni. Ha nincs túl sok mező, amit érint a dolog, a NULL használata is korrekt megoldás.
x gon' give it to ya
-
biker
nagyúr
válasz Sk8erPeter #1430 üzenetére
nem, csak fáradt vagyok.
írtad, nem bírom a kritikát. de bírom, de kritizálni azt lehet, amit ismerünk, nem hallottunk róla.
tegnap el is kezdtem nézni Alföldi István a királyát, de rá kellett jöjjek, tényleg szar, előre nem írtam le a cuccot, hátha csak a kritikusok azok, de nem, tényleg az volt.a jelen állapotában lévő webshopom egy 2006-os, akkor kb 3 tábla összesen 30 oszlopából fejlődött egy 13-14 táblából, azokban összesen vagy 120 oszlopos szörnyeteggé, 7. verzió, toldozva foldozva, és nem volt kedvem modernizálni, mert nincs akkora kereslet fizetős webshopra, hogy dolgozzak és töltsem az időt, mert csak fizetős időm van, szabad időm 4 éve nincs, hogy hobbira magamnak fejlesszek.
A rendszer "működőképes", és nem "optimális" és nem "szent". Nem is állítottam soha, hogy csak így lehet, és ez a jó út, azt mondtam, működik, és nem értem, miért CSAK másképp lehet, ahogy ti mondjátok
(jut eszembe, várom a hirdetésem linkelését a kollégától még)Majd ha ez emberek nem a woocommerce féle ingyen sz@rokat keresik, lehet ki lesz fejlesztve a modern verziója, addig nem.
az akciós kérdésben nem értünk egyet, a többiben igen
és nem hinném, hogy ettől, hogy itt szétszedtetek darabokra, bármi hibát elkövettem volna az utóbbi pár év fejlesztéseiben (nem 2006-ban meg előtte, mikor még tapasztalat nem volt) mivel minden azóta írt egyedi rendszerem (szerintem) okosan szét van szeparálva, legyen az a fitness szoftver, aminél a tagokat, bérleteiket, vásárlásaikat kezeli a rendszer, sok sok táblában sok sok XY_ID kapcsoatokkal, joinokkal, vagy legyen az a szerviztámogató program, ahol tagok-kapcsolattartók-címek-klímák-események-munkalapok rendszerezése és kezelése folyik, ugyanígy, és azon kell vitatkozzak a kedves megrendelővel, hogy nem, qrvára nem kellene egy munkalap szám alá 4 klíma javítást felvinni, mert nem releváns infó, egyik gépen ezt csináltam, másikon azt, ha 1 év múlva csak X klíma érdekel, ne hozza már le munkalap kapcsolat miatt Y Z klímákat is, de nem akarja megérteni, mert szerinte 15 lapot nem lehet borítékbe tenni, mert nem látott még L6-ná nagyobb borítékot.
az ok azt jelentette, olvastam, köszönöm, nincs mondanivalóm, mert nem érek rá ontani a szót, és nem mosdatni akarom magam.
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
fordfairlane
veterán
Amikor szóvátették az adatszerkezet problémáit, nem arra hivatkoztál, hogy nem éri meg vele foglalkoznod, hanem hogy akkor redundáns lesz, meg lassítja a lekérdezést, és ehhez hasonlók. Márpedig ezek fals indokok, mert nem attól lesz redundáns az adatbázis, ha a relációkat a megfelelő elvek mentén feldarabolod, hanem attól, ha egyben tárolsz nem egybe tartozó adatmezőket. Ez abszolute szakmai dolog, szakmai téma, és te szakmai alapon kérdőjelezted meg a jogosságát.
Az igaz, hogy az nem igazán jó érv, hogy így "nem szép", meg hogy "nem eléggé tankönyvszerű", én ezért is próbáltam gyakorlatiasabban megközelíteni a témát, de a te indokaid pl. a sebességre vagy a lekérdezés bonyolultságára sem igazán állják meg a helyüket.
[ Szerkesztve ]
x gon' give it to ya
-
Sk8erPeter
nagyúr
válasz fordfairlane #1433 üzenetére
Nem is azt írtam, hogy minden esetben tankönyvszerűen kellene kezelni, inkább logikusan szeparálva a felelősségeket, meg kényelmesen kezelhetően, persze az hozzátartozik, hogy nem véletlenül tanítják így, mert ezek bevált alapelvek, de igazából Te is nagyjából ezt írtad (leírtad Te is az okokat, amik miatt ezek hosszabb távon jól használható adatszerkezetek).
Sk8erPeter
-
Sk8erPeter
nagyúr
Ahogy előttem leírták, a kiindulási pont az volt, hogy megkérdőjelezted az indexek jelentőségét, meg a táblák szétválasztásának elvét (amit nem véletlenül szokás alkalmazni), nem pedig az, hogy "szétszedjünk darabokra". Nyilván a fejlesztésben vannak pontok, amikor az újrastrukturálás nehézkes, és az ember a határidő tartása érdekében csúnyább megoldásokra kényszerül, de ettől még az elv nem hibás. Ebben alakult ki a vita, ezekről próbáltunk győzködni, nem az volt a cél (de sztem ez egyértelmű), hogy csak azért is kritizáljunk.
"az akciós kérdésben nem értünk egyet, a többiben igen"
Eddig úgy tűnt, azt írtad le, hogy a termékek alapvető adataival egy táblában kezeled, mikor kezdődött, és zárult le egy bizonyos időszakban bevezetett akció, meg mi az akciós és korábbi ár, és hasonlók, és ezeket kell mindig felülírni módosításkor, de ha utólag ki akarnál egy kimutatást készíteni arról, hogy melyik időszakban milyen áron, milyen akció keretében, mekkora kereslet volt az adott termékre, akkor gondban lennél, mivel nincs history-szerűen nyilvántartva, korábban milyen árakon futott a termék (és mikor), csak felül van csapva a korábbi érték, aztán kész. De lehet, hogy ebben félreértés volt, és nem így kell elképzelni, abból indultunk ki, amilyen információkat leírtál.Sk8erPeter
-
biker
nagyúr
válasz Sk8erPeter #1439 üzenetére
"az akciós kérdésben nem értünk egyet, a többiben igen"
Eddig úgy tűnt, azt írtad le, hogy a termékek alapvető adataival egy táblában kezeled, mikor kezdődött, és zárult le egy bizonyos időszakban bevezetett akció, meg mi az akciós és korábbi ár, és hasonlók, és ezeket kell mindig felülírni módosításkor, de ha utólag ki akarnál egy kimutatást készíteni arról, hogy melyik időszakban milyen áron, milyen akció keretében, mekkora kereslet volt az adott termékre, akkor gondban lennél, mivel nincs history-szerűen nyilvántartva, korábban milyen árakon futott a termék (és mikor), csak felül van csapva a korábbi érték, aztán kész. De lehet, hogy ebben félreértés volt, és nem így kell elképzelni, abból indultunk ki, amilyen információkat leírtál.Van egy ömlesztett napló, amiben minden módosítás benne van, ebből kikereshető a kérdésre a válasz, de mondtam azt is, nem a legrugalmasabb, de ott van.
nyilván, ha külön helyen van kezelve, ez jobban követhető, van akinek még ez a naplózás is felesleges.Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
Jim-Y
veterán
sziasztok, mivel nem működik az sqlfiddle jelenleg, ezért a példa sémát belinkelem ide:
create table t1(
number INT PRIMARY KEY
);
insert into t1 values(150);
insert into t1 values(250);
insert into t1 values(350);
insert into t1 values(450);
insert into t1 values(1150);
insert into t1 values(3050);
insert into t1 values(3100);
create table t2(
range_id INT AUTO_INCREMENT PRIMARY KEY,
range_from INT,
range_to INT
);
insert into t2(range_from, range_to) values(0,999);
insert into t2(range_from, range_to) values(1000,1999);
insert into t2(range_from, range_to) values(2000,2999);
insert into t2(range_from, range_to) values(3000,3999);Jelenleg azt csinálom, hogy
SELECT
B.range_id
,B.range_from
,B.range_to
,COUNT(1)
FROM t1 A, t2 B
WHERE
A.number >= B.range_from AND
A.number <= B.range_to
GROUP BY B.range_id;Ez azt csinálja, hogy a t2-ben lévő rangekhez megszámolja, hogy hány t1-beli szám tartozik. A példánál maradva
id | range_from | range_to | count(1)
1 0 999 4
2 1000 1999 13 2000 2999 0
4 3000 3999 2Valami ilyesmit kéne kapni. A gondom az, hogy azok a sorok, ahol a count(1) nulla lenne, nem jelennek meg az eredményben. Hogy kéne módosítanom az összegzés, hogy azok a rangek is szerepeljenek, amiben 0 szám van? üdv
-
Jim-Y
veterán
válasz Apollo17hu #1442 üzenetére
Közben úgy próbálkozom, hogy
left outer joinnal hozzákötöttem a ranges (t2) táblát, majd megírom az eredményt, de cca 45 perc míg lefut a procedureSELECT
R.range_id
,R.range_from
,R.range_to
,IFNULL(S.numbers,0) as numbers
FROM t2 R LEFT OUTER JOIN
(SELECT
...
FROM t1, t2) S ON S.range_id = R.range_id;[ Szerkesztve ]
-
martonx
veterán
Ha ez úgyis tárolt eljárás (amire persze egyesek szerint úgy sincs semmi szükség), akkor tedd meg azt, hogy az alselect-et bedobod egy temp táblába, a temp tábla range_id-jére pedig teszel egy index-et (amivel egyesek szerint úgyse gyorsul számottevően semmi). Ezzel, ha minden igaz, drasztikusan le tudod redukálni a futásidőt.
Én kérek elnézést!
-
martonx
veterán
Múltkor szó volt itt arról, hogy a helyes indexelés mennyire jó, mennyire nem számít. Jelentem, az előbb egy egészen szimpla MySQL query-t találtam, ami 100%-on járatta a disk-et, és annak ellenére, hogy nem nagy tábláról volt szó (csak 1.5 millió sor, 240Mb-nyi a tábla), mégis egy egyszerű select 70 másodpercig futott rajta.
Javított indexeléssel ez lement 0,25 másodpercre. Tovább finomított indexeléssel lement 0,18-ra. Szóval végeredményben a 70 másodpercből lett 18 század másodperc. Még mindig lehetne rajta szépíteni, de innen már sokat úgyse lehetne nyerni. A disk pedig éppen csak megrebben 1-2%-on, amikor fut a select.
Én kérek elnézést!
-
fordfairlane
veterán
válasz martonx #1446 üzenetére
Indexelés nélkül a nem kulcs mezőkön, nem gyorsítótárazott forráson a keresés-rendezés full table scant igényel, így nem csoda.
x gon' give it to ya
-
biker
nagyúr
válasz Sk8erPeter #1447 üzenetére
haha, szólj ha felnőttél...
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
Új hozzászólás Aktív témák
- Kerékpárosok, bringások ide!
- Szevam: Érzelmi magabiztosság/biztonság - miért megyünk sokan külföldre valójában?
- Hogy is néznek ki a gépeink?
- Luck Dragon: Asszociációs játék. :)
- Samsung Galaxy A54 - türelemjáték
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: MárkaLánc
- Készülőben a Xiaomi 2021-es csúcsmodelljeinek HyperOS frissítése
- A pápa egyre jobban tart a romlott AI veszélyeitől
- Székesfehérvár és környéke adok-veszek-beszélgetek
- További aktív témák...