Hirdetés
- Épített vízhűtés (nem kompakt) topic
- IFA 2025: Egy normál és papírvékony tábla a Samsungtól
- TCL LCD és LED TV-k
- VR topik (Oculus Rift, stb.)
- Home server / házi szerver építése
- Fejhallgató erősítő és DAC topik
- Bakelit, Vinyl lemezjatszó
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Azonnali fotós kérdések órája
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
Új hozzászólás Aktív témák
-
#1940
fordfairlane
veterán
B.A.T.
#1939
fordfairlane
veterán
A Visual C++ 2013-as redistributable csomagot még kipróbálom, bár sztem ha 2015-el nem ment jó eséllyel ezzel se fog.
Jó eséllyel menni fog a 2013-mal. Ezek a runtimeok nem felülről kompatibilisek, ezért is lehet belőlük több verziót feltelepíteni egymás mellé.
Egyébként igazad van, a 6.3.9-től kezdve nincs 32 bites letölthető bináris:
Changes in MySQL Workbench 6.3.9
- Windows: Zip packages and 32-bit binaries are no longer published. The .NET Framework version 4.5 is now required.
-
#1938
fordfairlane
veterán
B.A.T.
#1936
fordfairlane
veterán
Vagy rakd fel a Visual C++ 2013 redistributable csomagot [link], vagy használd a Mysql Workbench 6.3.9 változatát.
Requirements for Windows:
- Microsoft .NET Framework 4.5
- Microsoft Visual C++ 2015 Redistributable PackageNote:
The 2013 version was changed to 2015 with MySQL Workbench 6.3.9. -
#1862
fordfairlane
veterán
kezdosql
#1859
-
#1722
fordfairlane
veterán
TomyLeeBoy
#1721
fordfairlane
veterán
válasz
TomyLeeBoy
#1721
üzenetére
A / max regexp patterdefinícióknál okozhat gondot, sehol máshol. Elég elcseszett sztringkezelés lehetett abban a scriptben.
-
#1710
fordfairlane
veterán
Apollo17hu
#1707
fordfairlane
veterán
válasz
Apollo17hu
#1707
üzenetére
MySQL tud analitikus függvényeket?
Tudomásom szerint egyiket sem ismeri.
-
#1550
fordfairlane
veterán
Kommy
#1549
-
#1463
fordfairlane
veterán
Jim-Y
#1461
-
#1453
fordfairlane
veterán
fordfairlane
veterán
Egyébként pont erre való az EXPLAIN, query-optimalizálásra.
-
#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.
-
#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.
-
#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.
-
#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 ).
-
#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.
-
#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.
-
#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.
-
#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.
-
#1370
fordfairlane
veterán
martonx
#1369
fordfairlane
veterán
válasz
martonx
#1369
üzenetére
Nem a tárolt eljárások létjogosultságát vagy hasznosságát kérdőjeleztem meg, hanem azt, hogy minek kell azon köröket futni, hogy ki használta és ki nem (és jájjdeámátőr) Sokan nem használják, mert nem a klasszikus Oracle, Sybase, DB2 vagy MSSQL-en tanultak, a Mysql-be meg később került bele. Vagy azért nem használják, mert korlátozottak a lehetőségek és emiatt úgyis szükség van egy alkalmazásszerverre, és ha már van alaklmazásszerver, akkor azon implementálnak minden funkcionalitást. Vagy azért, mert a tárolt eljárások még annyira sem egységesek a különféle vendorok közt, mint az SQL lekérdezések. Nincs azon semmi meglepő, hogy ilyen körülmények közt csomóan nem nyúlnak hozzá, csak ha muszáj.
-
#1284
fordfairlane
veterán
spammer
#1280
-
#1224
fordfairlane
veterán
laracroft
#1223
fordfairlane
veterán
válasz
laracroft
#1223
üzenetére
Ha a két lekérdezés túl sokáig tart, akkor egy is. Át kéne nézni / gondolni a táblák-mezők indexelését, amivel gyorsítani lehet az ilyesfajta lekérdezéseken.
A másik lehetőség, hogy, jellemzően webes környezetben sokkal több a táblából olvasás, mint az írás. Ebben az esetben azokat az aggregált adatokat, amelyek csak írás esetén változhatnak meg, és a lekérdezésük időigényes, előre ki lehet számolni, majd valahogy letárolni. Kvázi gyorsítótárazni. Mondjuk ez jelen esetben nem igazán járható út, de talán részhalmazokat elő lehetne állítani, amiket aztán gyorsabb átfésülni.
-
#1180
fordfairlane
veterán
futár
#1177
fordfairlane
veterán
-
#1142
fordfairlane
veterán
#68216320
#1140
fordfairlane
veterán
válasz
#68216320
#1140
üzenetére
Ha a mysqli interfészt használod, akkor inkább a mysqli_stmt::bind_params-t célszerű használnod. A példa alapján szerintem egyértelmű, hogyan kell használni.
Új hozzászólás Aktív témák
- Samsung Galaxy A25 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- Samsung Galaxy A55 128GB, Kártyafüggetlen, 1 Év Garanciával
- GYÖNYÖRŰ iPhone 11 64GB Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3167, 100% Akkumulátor
- Azonnali készpénzes AMD Radeon RX 9000 sorozat videokártya felvásárlás személyesen/csomagküldéssel
- BESZÁMÍTÁS! MSI Z390 i7 8700K 16GB DDR4 512GB SSD RTX 2060 Super 8GB Zalman N4 ADATA 600W
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest