- Apple iPhone 15 Pro Max - Attack on Titan
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Android szakmai topik
- Google Pixel topik
- Samsung Galaxy Watch6 Classic - tekerd!
- IFA 2025: Nem is látszik, hogy strapatelefon
- Fotók, videók mobillal
- IFA 2025: Telepcsere kikapcsolás nélkül
- Samsung Galaxy Watch8 - Classic - Ultra 2025
- iPhone topik
Új hozzászólás Aktív témák
-
#1500
PazsitZ
addikt
Apollo17hu
#1496
PazsitZ
addikt
válasz
Apollo17hu
#1496
üzenetére
Ha kevés field van akkor végül is mehwet a union is. De szvsz én akkor már nem join-olgatnék subquery-t.
(SELECT id , val1 FROM sample WHERE val1 IS NOT NULL AND val1<>'' ORDER BY id DESC LIMIT 1)
UNION
(SELECT id , val2 FROM sample WHERE val2 IS NOT NULL AND val2<>'' ORDER BY id DESC LIMIT 1)
UNION
(SELECT id , val3 FROM sample WHERE val3 IS NOT NULL AND val3<>'' ORDER BY id DESC LIMIT 1)result:
4 ló
5 3
5 12345 -
cidalain
veterán
válasz
cidalain
#1498
üzenetére
ha az átgondolt táblát használom akkor egy ilyen egyszerű lekérdezéssel meglennék:
SELECT MAX(date) AS last,type,value FROM `data2`
GROUP BY typeilletve dinamikussá is válna, hisz bármilyen típusú valuta bejöhet később ami most nincs, illetve ki is kerülhet ami már nem kell gond nélkül.
csak rohadtul sok adatom lesz így feleslegesen, attól félek.
-
cidalain
veterán
úgy kell elképzelni a feladatot, hogy például én egy pénzváltót csinálok.
árfolyamokat rögzítek a forinthoz képest.Tábla:
időpont | usd | chf | eur | .............és még sok másik is lehetnebizonyos időközönként valahol a nagyvilágba frissítik az árfolyamokat.
amikor változás van, akkor beszúrok egy időpontot, és azoknál ahol változás volt beszúrom az új árfolyamot.
ahol nem volt változás, ott nem akarok beszúrni semmit.és akkor a lekérdezésnek azt kellene ugye kidobnia, hogy egyes valutáknál melyek a legfrisebb árfolyamok
Az eddigi megoldások korlátosak, és nem igazán idomulnak automatikusan a valuták számának növekedésekornyilván elgondolkodtam egy teljesen másfajta táblaszerkezeten is
idő | valuta típusa | érték -> ahol az idő, és a valuta együtt lenne a PKde ebben az esetben minden időpontnál ahol több valuta is változik annyiszor többször szúródik be ugyanaz az időpont, illetve mindig be kell tennem a valutáknak is az azonosítóját. ettől meg úgy érzem hogy feleslegesen sok anyagot pumpálok az adatbázisba... 100000 adatnál itt már megabájtokat fog jelenteni. és több ilyesmi táblám is lenne még egy adatbázison belül...
-
#1497
cidalain
veterán
Apollo17hu
#1496
cidalain
veterán
válasz
Apollo17hu
#1496
üzenetére
"Ez a kimenet szerintem nem megvalósítható, mert a lastvalue mezőben eltérő adattípusok szerepelnének."
ezt nem értem, mert mindegyik val adat típusa VARCHAR(25).A másik jó, és azt csinálja amit gondolok, csak 6 darab select van benne.
annyiban különbözik ettől, hogy itt 3 result-ot kell feldolgozni, ott meg csak 1-et.SELECT id,val1 FROM sample
WHERE val1 <> ""
ORDER BY id DESC
LIMIT 1SELECT id,val2 FROM sample
WHERE val2 <> ""
ORDER BY id DESC
LIMIT 1SELECT id,val3 FROM sample
WHERE val3 <> ""
ORDER BY id DESC
LIMIT 1melyik optimálisabb? egy olyan adattáblán lenne használva amiben van 50-100.000 sor!
-
#1496
Apollo17hu
őstag
cidalain
#1491
Apollo17hu
őstag
válasz
cidalain
#1491
üzenetére
valid id lastvalue
val1 4 ló
val2 3 3
val3 5 12345Ez a kimenet szerintem nem megvalósítható, mert a lastvalue mezőben eltérő adattípusok szerepelnének.
Helyette a másik kimenetre egy megoldás:
SELECT s.id, s.val1, "" AS val2, "" AS val3
FROM (SELECT max(id) AS last_id
FROM sample
WHERE val1 <> "") t
,sample s
WHERE s.id = t.last_id
UNION
SELECT s.id, "" AS val1, s.val2 AS val2, "" AS val3
FROM (SELECT max(id) AS last_id
FROM sample
WHERE val2 <> "") t
,sample s
WHERE s.id = t.last_id
UNION
SELECT s.id, "" AS val1, "" AS val2, s.val3 AS val3
FROM (SELECT max(id) AS last_id
FROM sample
WHERE val3 <> "") t
,sample s
WHERE s.id = t.last_id -
#1494
cidalain
veterán
Apollo17hu
#1493
cidalain
veterán
válasz
Apollo17hu
#1493
üzenetére
igen
-
cidalain
veterán
eddig ezt úgy csináltam hogy lekérdeztem az utolsó egy napnyi adatot, php-ban feldolgoztam mindegyik adatot egy-egy tömbbe, és aztán kivettem mindegyikből az utolsó értéket meg az időt hozzá.
csak nyilván az alábbi problémák fordulhatnak elő:
- ha az utsó egy napban valamelyik adat mégsem kapna értéket, akkor az nem lesz meg
- a sql lekérdezés eredménye mondjuk 1440 sor, melyből nekem tulajdonképpen annyira van szükségem csak ahány adat oszlopom vana másik hogyha mindegyik adathoz külön lekérdezést csinálok, melyeknek 1-1 sor az eredménye
- ekkor viszont annyi lekérdezés van ahány adatmezőezt szeretném optimalizálni, hogy ne legyen felesleges sok adat, amit még utófeldolgozni kell, és ne legyen sok lekérdezés se.
-
cidalain
veterán
válasz
PazsitZ
#1490
üzenetére
nem
Az esetemben a val értékei nem összehasonlíthatóak egymással:
Átírtam a példát amit küldtél
[link]Fontos hogy nem mindegyik időpontban van kitöltve minden érték, vannak üres cellák is.
én a fennti átírt példához a következő kimenetet szeretném látni:
id val1 val2 val3
4 ló - -
3 - 3 -
5 - - 12345tehát mindegyik val-ból a legutolsó ID-jű nem üres értékűt
de inkább valami ilyen kimenet lenne a frankó:
valid id lastvalue
val1 4 ló
val2 3 3
val3 5 12345 -
cidalain
veterán
Sziasztok, kis help kellene
Adott egy tábla:
timestamp (PK) | adat1 | adat2 | adat3 | adat4Sok időpont van benne, de nem mindegyik időpontnál van minden adatsornak értéke, van olyan idő ahol valamelyik adat üresen van. és olyan időpont is van ahol több adat értéke is ki van töltve (olyan időpont nincs ahol mindegyik adat üres)
Olyan lekérdezést kellene készítenem, amely 1 lekérdezéssel visszaadja mindegyik adatsor legutolsó időpontját, és értékét (azaz a legutolsó nem üres értéket).
Azaz jelen példa szerint a lekérdezés eredményének 4 sorosnak kellene lennie (és persze ezek között előfordulhat azonos idő, ha az adatok elosztása pont úgy jön ki)a "SELECT adat1 FROM table ORDER BY timestamp DESC LIMIT 1" nyilván nem jó mert ezzel csak egy adatsor legfrissebb értékét kapom meg. a példában csak 4 adatsort írtam, de valójában persze ez sokkal több...
Köszi
-
cidalain
veterán
válasz
martonx
#1485
üzenetére
már megtaláltuk a hibát, sokat segített az programba épített extra logolás.
tulajdonképpen nem is abban az adatbázisban van a hiba, ahol kerestük, hanem egy másikban - backup, ezért nem értettük a problémát. most kiiktattuk a backupot, és minden oké, majd a hétvégén megvizsgáljuk hogy mi sérült meg a backupban.
-
cidalain
veterán
válasz
martonx
#1483
üzenetére
Az ID-n kívüli másik két mező értéke: timestamp, és egy másik táblára mutató azonosító. Egyik sem egyedi, értékük bármi lehet, lehet egyforma is. A programnál állítottunk be logot, hogyha exception van akkor printelje logfájlba a parancsot aminél bekövetkezett. Sima Insert into parancs, jó szintaxissal, és ide dobta a Duplicate Entry-t a mysql return-ja.
Nekünk is a progi a gyanús, de nem nagyon tudjuk pontosan belőni hogy hol. Most már az is gyanúnk hogy a hiba nem is ez, ez csak a következménye a dolognak.
Lehet a mysql-ben olyat esetleg állítani, hogy naplózza az összes queryt egy usertől?
Ezesetben be tudnánk kapcsolni a program által használt userre egy figyelést, és az összes adatbázisban végzett műveletét tudnánk ellenőrizni, és talán közelebb jutnánk a problémához.(sajnos azért is vagyunk tanácstalanok, mert az alap program már 3 éve működik hiba nélkül, és most meg kijött rajta ez a 3 milliomodik beszúrás után. új adatbázisra irányítva a probléma más 100ezernél jelentkezett, most meg már még hamarabb is ki tudjuk akasztani.)
-
-
cidalain
veterán
Üdv.
Érdekes problémával találkoztam, és nem jutok dűlőre:
Adott egy MySQL adatbázis, melynek van egy táblája:
-ID
-time
-akármiAz ID int 10 típusú, és auto increment.
Beszúráskor előjött egy olyan hibaüzenet hogy Duplicate Entry, és az ID-re hivatkozott. De hát az ID ugye auto increment!
Legelőször az ID típusát vizsgáltam meg hogy nem e túl kicsi, és elérte az adott adattípushoz tartózó maximális értéket, de nem: Int 10 típusú, azaz bazinagy szám is belefér, ellenben a kiakadás a 176874-ik ID-nél történt.
A beszúrásokat egy progi végzi, így a hiba keletkezése után több másik beszúrást is csinált volna, ami szintén nem sikerült, hasonló okok miatt.
Mintha a MySQL tudná hogy mi az utolsó érték, de nem inkrementálja...
Neten olvastam egy helyen ezt, azt javasolják hogy másoljam le a táblát és akkor megjavul, amiben igazából nem látom az összefüggést (persze olyan dögivel van hogy a 127-esnél akad meg a rendszer, de ott mindig kiderül hogy tinyint volt az ID típusa).
Annyit csináltam, hogy létrehoztam egy új táblát azonos szerkezettel, de üresen, visszaállítva az ID auto incrementjét 1-re, hogy kezdje elölről. A dolog működött is, de csak ideig óráig, ismét előjött a hiba, de sokkal korábban, már párezres ID érték esetén is.
Hallottatok már ilyenről, ha igen, tudjátok mi a megoldás?
Mysql DB verzió: 5.0.45 -
bbTamas77
aktív tag
Sziasztok!
MySQL-ben, van egy táblám amibe ismétlődő adatok szerepelnek.
pl::
Pistike 427337 másodperc
Pistike 137 másodperc
Pistike 2437 másodperc
Feri 236 másodperc
Feri 76555 másodpercMost egy olyan lekérést szeretnék megírni MySQL-ben, hogy megszámolni hányszor ismétlődik egy adat, és az ismétlődő adat közül a legnagyobbat kiválasztani.
Sima rendezés nyilván nem jó mert ott nem tudom megszámolni hányszor ismétlődik a sor.
-
#1478
Zedz
addikt
fordfairlane
#1477
Zedz
addikt
válasz
fordfairlane
#1477
üzenetére
Áhh köszi, én egybe írtam.
-
-
-
Zedz
addikt
Sziasztok!
Van egy problémám, amit nem nagyon tudok megoldani. Arról szól a dolog, hogy van 3 táblám.
user -> user-right <- right
User-right egy kapcsoló tábla, ahol a userek id-ja össze van kötve a jogkörük id-val. Szeretnék egy olyan táblázatot készíteni, ami a felhasználónevet és a hozzá rendelt jogkört kiírja. Például jelenleg úgy néz ki a dolog, hogy János - 1, de én ezt szeretném: János - Feltöltő.
Az első variációt meg tudtam oldani egy sima INNER JOIN-nal, de tovább már nem tudom írni a lekérdezésem. Jelenleg így néz ki:
SELECT * FROM `user` INNER JOIN `user_right` ON `user_id` = `id`
-
Jim-Y
veterán
Sziasztok.
Azt szeretném megoldani, hogy a táblámban két oszlop együttesen legyen unique. Tehát ne lehessen beszúrni még egy olyan sort a táblába, ahol elsooszlop és harmadik oszlop együttesen már van egy sorban. Ha csak az egyik, vagy csak a másik már szerepel egy sorban attól még be lehessen szúrni.
Elsőnek webes kereséssel kezdtem, találtam is egy használható posztot: [link]
És csak a felől érdeklődnék, hogy szerintetek is így kell-e megoldani a fenti problémát? üdv
-
#1468
martonx
veterán
Sk8erPeter
#1467
martonx
veterán
válasz
Sk8erPeter
#1467
üzenetére
Igazad van nem ildomos, de feladat függő, szóval ha jól értettelek, akkor ebben az esetben ez így jó lesz.
-
#1467
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
Hali!
Van egy tábla, amiben olybá tűnik, állandóan egy VARCHAR(32)-mező szerint kérdeznék le (amiben egy olyan string van, ami semmiképp nem tartalmaz whitespace-eket), ezenkívül egy INT-mező van, de ergo összesen 2 mezős a tábla, de pont a stringhez tartozó INT-értéket kérdezném majd le, így az INT-mező igazából másodlagos.
Úgy tudom, VARCHAR-mezőre primary key-t tenni nem túl üdvös megoldás például teljesítmény-tekintetben. Nektek mi a véleményetek erről, igazán gond-e primary key-ként használni egy VARCHAR-mezőt egy viszonylag kevés adatot tartalmazó táblában? Van tapasztalatotok/meglátásotok ezzel kapcsolatban? -
#1466
Jim-Y
veterán
fordfairlane
#1465
Jim-Y
veterán
válasz
fordfairlane
#1465
üzenetére
Köszi, A megoldás így akkor az lett, hogy átállítottam a dátum oszlopt unique-ra, és az insertbe betettem egy IGNORE-t. Köszönöm a segítséget
-
Jim-Y
veterán
válasz
martonx
#1462
üzenetére
Tárolt eljárás végén insertálok, a gond az, hogy többször is bekerült ugyanaz a sor a táblába, és ez összezavarja egy másik eszköz működését. Most ezzel próbálkozom de hibát dob.
Felveszek egy flaget, kezdetben beállítom nullára, majd lekérdezem, hogy a beszúrni kívánt táblában van-e már ilyen sor, ha van, akkor flag 1 lesz, és ez alapján insert, vagy sem.
Így néz ki kód szintjén:
DECLARE flag INT;
SET flag = 0;
...
...
SELECT 1 FROM tabla WHERE datum = multhet INTO flag;
CASE flag
WHEN 0 THEN (INSERT INTO tabla (datum, ertek) VALUES (multhet,myertek));
ELSE (SELECT 'row already in table');
END CASE;Sajnos erre ezt a hibát dobja:
Script line: 4 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'INSERT INTO tabla (datum, ertek) VALUES (multhet,myertek));
' at line 120Szerintem így case-en belülre nem lehet insertet rakni, mert sima selectet sikerült.
fordfairlane: a tábla ahova beszúrok egy 3 oszlopos tábla, id, datum, ertek
az id auto increment, és ez a kulcs.
Én tényleg csak azt szeretném elérni, hogy pl van egy ilyen sorom a táblában:22 2013-37 99.9999
akkor ne tudjak egy olyan sort beszúrni, ahol datum = 2013-37
-
#1463
fordfairlane
veterán
Jim-Y
#1461
-
Jim-Y
veterán
sziasztok, hogy tudok úgy insertet írni, hogy ha már szerepel ez a sor a táblában akkor ne szúrja be? üdv
ezzel próbálkoztam, de nem jó, beszúr egy újabb sort, nyílván más id-vel, de a többi ugyanaz:S
Példa:
INSERT INTO TABLA (DATUM, ERTEK) VALUES (multhet,ertek1) ON DUPLICATE KEY UPDATE DATUM = DATUM; -
#1460
PiXeL90
csendes tag
Sk8erPeter
#1456
PiXeL90
csendes tag
válasz
Sk8erPeter
#1456
üzenetére
Adatbázis-kliens verziója: libmysql - 5.5.32
PHPMyAdmin Verziószám: 3.5.8.1deb1
Apache/2.2.22 alatt fut.A lefutatott query így nézett ki:"INSERT INTO regiok(`kereslet_id`, `regio_id`)VALUES($kereslet, $regio)";
De egy másik táblában is lefuttattam és ott nem volt ilyen hiba.
-
#1459
bbTamas77
aktív tag
Sk8erPeter
#1458
bbTamas77
aktív tag
válasz
Sk8erPeter
#1458
üzenetére
Nagyon szépen köszönöm, így már menni fog.
-
#1458
Sk8erPeter
nagyúr
bbTamas77
#1457
Sk8erPeter
nagyúr
válasz
bbTamas77
#1457
üzenetére
Magyar leírás lehet, hogy nincs, de a hivatalos dokumentáció sztem elég érthető:
http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_inet-aton
INET_ATON(expr)
Given the dotted-quad representation of an IPv4 network address as a string, returns an integer that represents the numeric value of the address in network byte order (big endian). INET_ATON() returns NULL if it does not understand its argument.
mysql> SELECT INET_ATON('10.0.5.9');
-> 167773449
For this example, the return value is calculated as 10×256^3 + 0×256^2 + 5×256 + 9.
[...]http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_inet-ntoa
" INET_NTOA(expr)
Given a numeric IPv4 network address in network byte order, returns the dotted-quad representation of the address as a binary string. INET_NTOA() returns NULL if it does not understand its argument.
mysql> SELECT INET_NTOA(167773449);
-> '10.0.5.9'
[...]"Röviden: INET_ATON()-nak egy IPv4-címet adsz át paraméterül stringként, ez cserébe ennek a numerikus értékét adja vissza integerként, a számolás mikéntjét a helyiértékek szerint mutatja a képlet. Az INET_NTOA() pedig ugyanez visszafelé (IPv4-címnek megfelelő integer-értéket adsz át paraméterül, stringet kapsz válaszul).
-
#1456
Sk8erPeter
nagyúr
PiXeL90
#1455
Sk8erPeter
nagyúr
válasz
PiXeL90
#1455
üzenetére
Most ezt ennyi részletből elég nehéz lenne kitalálni... Azt sem tudjuk, bugról lehet-e szó (verziót sem írtál), nem mutattál egy nyomorék screenshotot sem, ezek szerint más adatbázis-böngészőben sem nézted meg (mint pl. a MySQL Workbench), plusz azt sem tudjuk, milyen query-t futtattál.
Szóval a válasz csak egy nagy kérdőjel.
-
PiXeL90
csendes tag
Sziasztok!
Az lenne a kérdésem hogy lefutattam egy insertet egy táblán és amikor megnéztem hogy mit vitt fel akkor láttam hogy felvitt minden adatot rendesen de lapozásnál phpmyadmin-ba több oldalt ad ki mint amennyi kellene. Pl.: Elég lenne összesen 10 oldal az összes rekord megnézéséhez de 15 oldalon lehet lapozni és az utolsó 5 oldalon nincs semmi.
Ez mitől lehet?
Segítségeteket előre is köszi! -
#1453
fordfairlane
veterán
fordfairlane
veterán
Egyébként pont erre való az EXPLAIN, query-optimalizálásra.
-
#1451
martonx
veterán
fordfairlane
#1449
martonx
veterán
válasz
fordfairlane
#1449
üzenetére
A kérdéses táblán 4 index is volt, csak éppen aki indexelt, béna volt.
Most kettő index van már csak rajta, de legalább azok jók. -
#1450
biker
nagyúr
Sk8erPeter
#1447
biker
nagyúr
válasz
Sk8erPeter
#1447
üzenetére
haha, szólj ha felnőttél...
-
#1449
fordfairlane
veterán
martonx
#1446
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.
-
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.
-
-
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.
-
#1443
Jim-Y
veterán
Apollo17hu
#1442
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 procedure
SELECT
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; -
#1442
Apollo17hu
őstag
Jim-Y
#1441
-
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
-
#1440
biker
nagyúr
Sk8erPeter
#1439
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. -
#1439
Sk8erPeter
nagyúr
biker
#1434
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. -
#1438
Sk8erPeter
nagyúr
fordfairlane
#1433
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).
-
#1435
fordfairlane
veterán
biker
#1434
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.
-
#1434
biker
nagyúr
Sk8erPeter
#1430
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.
-
#1433
fordfairlane
veterán
Sk8erPeter
#1432
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.
-
#1432
Sk8erPeter
nagyúr
fordfairlane
#1431
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.
-
#1431
fordfairlane
veterán
Sk8erPeter
#1428
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 ).
-
#1429
biker
nagyúr
Sk8erPeter
#1428
biker
nagyúr
válasz
Sk8erPeter
#1428
üzenetére
ok
-
#1428
Sk8erPeter
nagyúr
biker
#1419
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. -
#1427
fordfairlane
veterán
biker
#1425
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.
-
#1426
biker
nagyúr
fordfairlane
#1424
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 cimke -
#1425
biker
nagyúr
fordfairlane
#1423
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. -
#1424
fordfairlane
veterán
biker
#1422
fordfairlane
veterán
-
#1423
fordfairlane
veterán
biker
#1422
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.
-
#1422
biker
nagyúr
fordfairlane
#1421
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
-
#1421
fordfairlane
veterán
biker
#1419
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.
-
#1420
fordfairlane
veterán
Peter Kiss
#1417
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.
-
#1419
biker
nagyúr
Sk8erPeter
#1416
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();
?>
-
#1418
biker
nagyúr
Peter Kiss
#1417
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
-
#1417
Peter Kiss
őstag
Sk8erPeter
#1416
Peter Kiss
őstag
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?
-
#1416
Sk8erPeter
nagyúr
biker
#1415
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.
-
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.
-
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.
-
#1413
fordfairlane
veterán
biker
#1410
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.
-
#1412
Peter Kiss
őstag
biker
#1410
Peter Kiss
őstag
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.
. -
#1411
Sk8erPeter
nagyúr
biker
#1410
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. -
#1410
biker
nagyúr
Peter Kiss
#1408
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.
-
#1408
Peter Kiss
őstag
biker
#1407
Peter Kiss
őstag
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.
-
#1407
biker
nagyúr
Peter Kiss
#1406
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
-
#1406
Peter Kiss
őstag
biker
#1405
Peter Kiss
őstag
"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.
-
#1405
biker
nagyúr
Peter Kiss
#1403
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 box -
#1404
Drótszamár
őstag
Peter Kiss
#1403
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.
-
#1403
Peter Kiss
őstag
Drótszamár
#1402
Peter Kiss
őstag
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.
-
#1402
Drótszamár
őstag
Peter Kiss
#1400
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.
-
#1401
Drótszamár
őstag
Peter Kiss
#1400
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.
Nem csodálom, hogy rosszul esett. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
.
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.
Új hozzászólás Aktív témák
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- A fociról könnyedén, egy baráti társaságban
- World of Warships
- Apple iPhone 15 Pro Max - Attack on Titan
- PROHARDVER! feedback: bugok, problémák, ötletek
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Android szakmai topik
- Elektromos autók - motorok
- Google Pixel topik
- További aktív témák...
- LG 55C2 - 55" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - A9 Gen5 CPU
- Honor Magic6 Pro 512GB, Kártyafüggetlen, 1 Év Garanciával
- 14" Dell Latitude laptopok: 5400, 5480, 5490, 7480, E6410, E6440, E5450 / SZÁMLA + GARANCIA
- Bomba ár! Fujitsu LifeBook U939x- i5-8GEN I 8GB I 256SSD I 13,3" FHD Touch I HDMI I Cam I W11 I Gar
- Huawei Nova Y70 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest