- 1520 mAh-val rövidíthetik meg Európát
- iPhone topik
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Most a Honor 400 Prón a sor
- Samsung Galaxy A56 - megbízható középszerűség
- Yettel topik
- Csak 15 ezret kérnek ezért az autós fejegységért - hát olyan is
- Megmutatta erejét a Honor 400 Pro
- Apple Watch Ultra - első nekifutás
Új hozzászólás Aktív témák
-
fordfairlane
veterán
válasz
FIREBLADE78 #3244 üzenetére
Remélem működik. Egyébként vállalati környezetben megszokott dolog a virtualizáció, részben az ilyen kompatibilitási okokból kifolyólag.
-
fordfairlane
veterán
válasz
FIREBLADE78 #3242 üzenetére
Nálam a VirtualBox simán tudja használni a host gép LAN adapterét.
-
fordfairlane
veterán
Ezt a logikát nem értem, hogyan oldják meg.
Amikor a kliens rákattint a következő oldal gombra, ugyanaz a lekérdezés lezajlik még egyszer, csak ilyenkor egy másik szeletét kapja az eredményhalmaznak. Az alkalmazáslogika jellemzően nem tárolja el a lekérdezés eredményét, csupán csak a lekérdezés paramétereit, például az url-ben, meg még azt, hogy a halmaz melyik szegmensét jelenítse meg.
-
fordfairlane
veterán
válasz
Thrawnad #3115 üzenetére
SELECT * FROM bejelentkezesek WHERE mikor IN (SELECT mikor FROM bejelentkezesek WHERE DATE(nap) = CURRDATE() AND honnan = '1' ORDER BY mikor DESC LIMIT 3)
(PHP alatt lehetőleg NE használd a mysql_query függvényt!)
-
fordfairlane
veterán
válasz
fordfairlane #2743 üzenetére
a simple esetén a logból a lezárult tranzakciók eltűnnek.
Ez egyébként sajnos nem ilyen egyszerű, de egy manuális checkpoint indítással úgy tűnik, megoldható. Sajnos ez már az a mélysége az MS SQL adminisztrációjának, amit sajnos nem ismerek eléggé.
-
fordfairlane
veterán
válasz
Khelben #2739 üzenetére
A tranzakciólog tartalma függ a beállított recovery mode-tól, a simple esetén a logból a lezárult tranzakciók eltűnnek. A fizikai törlés a log esetén a shrink művelet. A recovcery mode az egész adatbázisra vonatkozik, és kihatással van az egész backup folyamatra, ezért ha csak egy bizonyos táblánál vannak ilyen kritériumok, akkor azt érdemes egy külön adatbázisba tenni. Pluszban még meg lehet fejelni az egészet egy titkosítással.
-
fordfairlane
veterán
válasz
Sk8erPeter #2670 üzenetére
Az biztos, hogy belépési próbálkozásokat én nem user táblában tárolnám el, elvégre a user azonosítót is el lehet gépelni.
-
fordfairlane
veterán
-
fordfairlane
veterán
válasz
PumpkinSeed #2627 üzenetére
-
fordfairlane
veterán
válasz
Sk8erPeter #2499 üzenetére
Ismerni kéne a rendszert, hogy a vonalkód milyen értékeket vehet fel. Ha például betű csak valami hiba folytán kerülhet be, akkor decimal + validálás a megfelelő eljárás. Ha előfordulhatnak betűk és számok is, akkor a varcharral nincs semmi gond.
-
fordfairlane
veterán
válasz
Sk8erPeter #2496 üzenetére
Egyébként egyszerű a probléma: nem írta le, hogy a vonalkód milyen értékkészletű, és azt sem, hogy a DB séma milyen. Utólag megtudtuk, hogy double volt, de ezzel sem megyünk sokra, mert a varchar mindent elbír, tehát inkább csak elfedi a hibát, mint sem megoldja.
-
fordfairlane
veterán
válasz
Sk8erPeter #2491 üzenetére
Ha biztosan csak számok vannak benne, akkor miért is ne, teljesítmény-szempontból még jobb is lehet.
Kivéve, ha nullával vagy nullákkal kezdődő számsorról van szó. Arra a decimal vagy numeric típus való, nem a különféle méretű integerek, és persze a lebegőpontos ábrázolásmódok sem.
-
fordfairlane
veterán
Egyébként én először olyan információt akartam szövegként tárolni, ami tipikusan egy enum (SQL) típus lenne, és a mező "kardinalitása" olyan 10 db érték körül mozog. Enummal az a baj, hogy nem elég dinamikus, ha új értékre van szükségem az alkalmazásban, akkor módosítanom kell az elérhető enumok listáját, ami MySQLnél azt is eredményezheti, hogy újragenerálja az egész táblát. És az enumra lett volna alternatíva a numerikus vagy szöveges érték, ahol én arra szavaznék, hogy legyen csak szöveges pl.
Státusz = {"active", "inactive", "suspended", "deleted"} ahelyett, hogy 1,2,3,4-t tennénk a mezőbe. És szerintem ez tényleg nem nagy eretnekség.Már miért lenne eretnekség, sehol nincs előírva, hogy felsorolás mezőnek INT-nek kell lennie. Enum mehet a fix készletnek, CONSTRAIN-es kapcstábla a variábilis jellegűnek. Felindexelve egy varchar is gyors, és csak emiatt fölösleges egy plusz INT-re absztrakciót beemelni a táblaszerkezetbe.
-
fordfairlane
veterán
Tároljuk a település nevét szövegként a személy táblában, vagy egy numerikus kódot és joinoljuk egy településeket tartalmazó táblával mindig?
Ha a település neve egyedi, akkor a név lehet kulcsmező. Szövegként tárolni a települések közt, és idegen kulcsként is felhasználható egyidejűleg.
-
fordfairlane
veterán
válasz
csabyka666 #2049 üzenetére
Ha az áruház nevéből indulsz, és a termék(ek) nevéhez akarsz elérkezni, akkor szükséged lesz mind a három táblára. Három táblát meg két JOIN-nal tudsz összekapcsolni. (Nem mostanában volt pont ugyanerről téma errefelé?)
SELECT termek.nev
FROM termek
(INNER) JOIN kapcstabla
ON termek.id = kapcstabla.termekid
(INNER) JOIN aruhaz
ON aruhaz.id = kapcstabla.aruhazid
WHERE aruhaz.nev = "nagyesszep";Vagy valami ilyesmi. Ez csak két equi-join, semmi nagy varázslat.
Szerk: Az INNER-t azért tettem zárójelbe, mert opcionális. Vagy SQL kiszolgálófüggő.
-
fordfairlane
veterán
de ha ehhez a lekérdezéshez hozzáadok még egy join-t akkor már nem lesz eredménye a lekérdezésnek. (pedig van olyan id-jű versenyző)
Pedig sok variáció ezzel nincs, mivel egyértelmű, kit mivel kell összekapcsolni. Versenyzőket a nevezésekkel, azt meg a kategóriákkal, a megfelelő kulcsmezők mentén. Dupla Equi-Join. Versenyzo INNER JOIN Nevezett ON Versenyzo.id = Nevezett.versenyzoid INNER JOIN Kategoriak ON Nevezett.kategoriaid = Kategoriak.id
-
fordfairlane
veterán
Keresd meg a második left outer join részt:
Új hozzászólás Aktív témák
- Macbook Pro 15" - 2019 gyártás / Intel i9-9880H / 16GB ram / 512gb SSD / 4GB Radeon / RETINA
- Precision 7760 17.3" FHD IPS i7-11850H RTX A4000 32GB 512GB magyarított (lézerezett) vbill gar
- Google Pixel 9 Pro 256GB Obsidian, Karcmentes, Újszerű Állapotú, Fekete, Garanciális
- MSI Pulse GL76 11UEK 17.3" FHD IPS i7-11800H RTX 3060 16GB 512GB NVMe magyar vbill gar
- Samsung Galaxy S21 Ultra 12/128GB, Megkímélt, Kártyafüggetlen, Töltővel, 1 Év Garanciával!
- Lejárt a gyártói garancia? Mi tovább támogatjuk az IT infrádat!
- LG 27GR95QE - 27" OLED / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- Samsung Galaxy S23 Ultra 256GB, Kártyafüggetlen, 1 Év Garanciával
- AKCIÓ! ASUS PRIME Z390-P i5 8600K 16GB DDR4 512GB SSD RX 6600 8GB GDDR6 DEEPCOOL Matrexx55 630W
- HPE Apollo 4200 Gen9 2U rack szerver, 1x E5-2620v4, 64GB RAM, 24x3.5" 2U-ban! ÁFA-s számla, garancia
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest