Új hozzászólás Aktív témák
-
sztanozs
veterán
válasz jocomen #2224 üzenetére
Számított mezőnek nem lehet része más tábla mezője.
Query-t viszont össze tudsz dobni, ahol egy mező több forrásmezőből számítódik.SELECT t1.t1_ID, t1.a, [t1].[a]*[t2].(c) AS b
FROM Table1 AS t1 INNER JOIN Table2 AS t2 ON t1.t1_ID = t2.t2_ID;(/C)[/M][ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
csabyka666
addikt
válasz jocomen #2253 üzenetére
Próbáltam mindenféle sorrendben, sehogy sem engedi. Marad a favágó módszer, vagy pedig DROP-olom a táblákat, és létrehozom újra.
Ágdarálást, kaszálást, területtisztítást vállalok profi gépekkel! Elsősorban Zala megye és vonzáskörzete, de minden megkeresést meghallgatok. +36305633091
-
Sk8erPeter
nagyúr
válasz jocomen #2358 üzenetére
Első felére: phpMyAdminban is összeállíthatsz query-ket.
"Több adat (rekord) bevitele megoldható 1 utasításban? És az hogy néz ki?"
Úgy érted, egyazon táblába?
Például így érted?
INSERT INTO `táblád_neve` (`egyik_mezo`, `masik_mezo`, `harmadik_mezo`)
VALUES
(1, 'masodik_adat', 'harmadik_adat'),
(2, 'masodik_adat', 'harmadik_adat'),
(3, 'masodik_adat', 'harmadik_adat');Sk8erPeter
-
-
PumpkinSeed
addikt
válasz jocomen #2466 üzenetére
Nem lehetséges, mert már kész táblákról van szó. Esetleg az, hogy a location_log tábla törölve volt, és újra létrehozva majd most, hogy változtatni akarok a recycle_bin (vagy mi van itt) beleszól a változtatásba?
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
PumpkinSeed
addikt
válasz jocomen #2468 üzenetére
A törölt tábla kavart be, mert miután létrehoztam más néven engedte, furcsa is volt hogy valami ls234k23 ilyen típusú táblára akar hivatkozni.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
PumpkinSeed
addikt
-
Sk8erPeter
nagyúr
válasz jocomen #2490 üzenetére
Hát ha pl. betűk és számok egyaránt előfordulnak a vonalkódban, akkor nyilván nem kéne integerként tárolni. Ha biztosan csak számok vannak benne, akkor miért is ne, teljesítmény-szempontból még jobb is lehet. A kollégától azért kérdeztem vissza, mert nem igazán értem, hogy jönnek ide a tizedesvesszők/-pontok, amikor egy vonalkódról beszélünk.
Sk8erPeter
-
martonx
veterán
válasz jocomen #2567 üzenetére
A join-ok szvsz átláthatóbbak, és talán (ez persze nagyban függ az sql motortól) jobban lehet őket optimalizálni, mint egy rakás where paraméterbe rejtett subquery-t.
Elméletileg az sql motor ugyanazt a végrehajtási tervet kellene, hogy készítse mindkét esetben, gyakorlatilag pici apróságokon is tud múlni, egy - egy sokkal optimálisabb terv felbukkanása.Én kérek elnézést!
-
jocomen
aktív tag
válasz jocomen #2835 üzenetére
Bocsánat!
Ezek voltak eredetileg, kapcsolatok nélkül (így kellett lekérdezéseket írjanak):PACIENS
p_id
nem
szuldat
KATEGORIA
hely
fog_nev
kategoria_nev
DIJSZABAS
kategoria_nev
muvelet
osszeg
BEAVATKOZAS
id
p_id
irany
szint
hely
orvos
muvelet
datumVagyis semmi sincs kőbe vésve, csak legyen jó a szerkezet és a kapcsolatok.
[ Szerkesztve ]
-
bambano
titán
válasz jocomen #2833 üzenetére
engem az zavar, hogy a dijszabas táblából a kategória_id és a művelet_id varchar mezők int mezőkhöz kapcsolódnak.
szerk: meg ha rajtam múlna, minden összeg mellé tennék egy áfa kulcs és egy pénznem mezőt, a beavatkozások mellé sz.j. szám mezőt is.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Szmeby
tag
válasz jocomen #2840 üzenetére
Talán azért van ez így, mert nincs különösebb oka a beavatkozás és a számla tétel táblák szétválasztásának. Vagy mégis?
Például a díjszabás forintban kerül megállapításra, a beavatkozás ezen leíró tábla alapján egyértelműen beárazható (szerintem a lehető leghamarabb érdemes jelölni a kiszabott árat). Viszont az ügyfél eurós számlát kér, vagyis a számla tételben már euróban kell szerepelnie az összegnek. Az meg már tiszta sor, hogy a számla fejen lévő összeg a számla tételeket összegzi.
És ha már a valutakonveziónál járunk, ahhoz asszem illene egy teljesítés dátuma mező, ami alapján meghatározható, hogy melyik napi árfolyam alapján történt a konverzió.
Ha jól látom, a rendszer jelenleg nem kezeli a sztornó és helyesbítő számlát sem, ehhez is elkelne majd pár új mező (pl. számla típusa, számlák egymásra hivatkozása, ilyesmi).
Vagy a proginak nem lesz köze a számlázáshoz?Formailag nekem pl. nem tetszik, hogy bizonyos táblanevek egyes számban, mások meg többes számban szerepelnek, és nem látom az okát. Kevés olyan tábla van egy adatbázisban, amiben csak egy sor van, totál felesleges belekeverni a számosságot a táblanévbe, bátran lehet mindegyik egyes számú.
Ha nagyon zavar a kerülő útvonal, hát egyesítsd a táblákat. Pl. úgy, hogy eltörlöd a kategóriát (az legfeljebb a fogon szerepel mint plusz információ), a díjakat pedig foganként adod meg. Nincs olyan sok fogunk, hogy ez drasztikus mértékben rontaná a teljesítményt. Persze ha igény van arra, hogy kategóriához adunk meg árat, akkor ne tedd.
Megjegyzem, hogy mindig is utáltam a normalizálós feladatokat a suliban, és nincs is benne gyakorlatom, ezért csak módjával hallgass a hülyeségeimre.
Új hozzászólás Aktív témák
- Samsung Galaxy A54 - türelemjáték
- Épített vízhűtés (nem kompakt) topic
- Milyen notebookot vegyek?
- VR topik (Oculus Rift, stb.)
- Kerékpárosok, bringások ide!
- Microsoft Surface
- Milyen légkondit a lakásba?
- Samsung Galaxy S24 - nos, Exynos
- Call of Duty: Modern Warfare III (2023)
- Tarr Kft. kábeltv, internet, telefon
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen