Hirdetés
- Luck Dragon: Asszociációs játék. :)
- GoodSpeed: Aquaphor Modern víztisztító
- sziku69: Fűzzük össze a szavakat :)
- hcl: Kelj fel komám, ne aludjál
- Fogkefe: elektromos vagy manuális?
- Geri Bátyó: Agglegénykonyha 3 – Paradicsomos káposzta (amit amúgy utálok)
- ldave: New Game Blitz - 2025
- Geri Bátyó: Agglegénykonyha 2 – Főzés: szabályok, vagy szabadság?
- bambano: Bambanő háza tája
- eBay-es kütyük kis pénzért
Új hozzászólás Aktív témák
-
válasz
kezdosql
#4097
üzenetére
Esetleg a játékosoknak, ha készítesz egy törzstáblát, hogy melyik, mettől meddig tartozik egy csapatboz az segítene?
Rekord_id
Jatekos_id
Jatekos_nev
Csapat_id
Tagsag_kezdete
Tagsag_vege (az aktuális csapatánál 9999.12.31)Ugyanezt elkészíteném a sérülések-re:
Rekord_id
Jatekos_id
Serules_kezdete
Serules_vege (ez mindaddig 9999.12.31., amíg sérült a játékos) -
#4098
kezdosql
tag
Apollo17hu
#4095
kezdosql
tag
válasz
Apollo17hu
#4095
üzenetére
Indoklassal, hogy miert minosited annak, informaciot adott volna.
Ismetlem, en nem erzelmi alapon irok, nem a szemely, hanem a tema es a megoldas az erdekes szamomra.
-
kezdosql
tag
válasz
kezdosql
#4094
üzenetére
Amin most tepelodok, amit Apollo irt, az esemenytabla, mert azt valahogy be kell illeszteni az elemzesbe, a szezonon beluli torteneseknel szakaszolni kell - pl. egyik csapat edzoje a masikhoz igazol, vagy amit korbban irtam, hogy december kozepen lecserelik a csatarsort es "uj csapat" jelenik meg.
Sehogyansenem jutok elobbre, mert egy esemeny tul sok mindent erint.
Elvileg jo lenne indulasnak:
Esemeny tabla
es_id
datum-ido
megnevezes
erintett - es itt bukok el, pl. 3 jatekos atigazol masik csapatba, minimum a 3 jatekost es a 2 csapatot erinti.Elvileg leszukithetek mindent "csapatok" es "szemelyek"-re, es a szemelyeknel van egy leosztas, hogy az illeto az adott idoszakban jatekos, edzo, biro, partjelzo, stb. de akkor is ket csoportom van, es azon belul is tobb erintett lehet.
Eddig jutottam:
Esemeny tabla
esemeny_id
datum-ido
megnevezes
csapat_id
szemely_idHa felveszek egy segedtablat, az megoldas lehet?
segedtabla
esemeny_id
csapat_id
szemely_idNagyon M : N -szeru, nehezen kezelheto megoldasnak tunik:-(
-
#4096
user112
senior tag
Apollo17hu
#4092
user112
senior tag
válasz
Apollo17hu
#4092
üzenetére
Ebből leesett, hogy a CASE nem tartalmazhat aliast. Ha behelyettesítem a kifejezést, akkor már jó lett.
Ahány CASE, annyi Hiba mező lett, így végül is jó lett a lekérdezésem.
Köszönöm.
A belső Select-ben mit jelent az "a", 20,30 stb.? -
kezdosql
tag
Igen, hasonlora jutottam korabban en is, a biroknal kell egy ujabb segedtabla, mert csak a neveket lehet megadni, a meccsekkel egyutt van ertelmezve, hogy biro vagy partjelzo volt, a jatekosoknal is, hogy adott meccsen jatszott, kispadon ult vagy serult volt, stb.
Amin most tepelodok, amit Apollo irt, az esemenytabla, mert azt valahogy be kell illeszteni az elemzesbe, a szezonon beluli torteneseknel szakaszolni kell - pl. egyik csapat edzoje a masikhoz igazol, vagy amit korbban irtam, hogy december kozepen lecserelik a csatarsort es "uj csapat" jelenik meg.
-
#4093
kezdosql
tag
Apollo17hu
#4088
kezdosql
tag
válasz
Apollo17hu
#4088
üzenetére
Erzelmi toltes nelkul irtam, tenyszeruen.
Adatbazis ertelemszeruen a sok tabla, minimum harmadik normal formaval.
Az "egytablas" megoldas a ket dimenzios tablazatot jelenti, aminek semi koze az adatbazishoz - legfeljebb adatforraskent. -
#4092
Apollo17hu
őstag
user112
#4091
Apollo17hu
őstag
válasz
user112
#4091
üzenetére
Ez a két módszer:
SELECT t.azon
,t.c1
,t.c2
,CASE
WHEN t.c2 ! = 0 THEN
t.c1 / t.c2
END AS arany
,CASE
WHEN t.c1 > 10 AND CASE
WHEN t.c2 ! = 0 THEN
t.c1 / t.c2
END > 50 THEN
'x'
END hiba
FROM (SELECT 'a' azon
,20 c1
,30 c2
FROM dual
UNION
SELECT 'b' azon
,20 c1
,0 c2
FROM dual
UNION
SELECT 'c' azon
,40 c1
,NULL c2
FROM dual
UNION
SELECT 'd' azon
,500 c1
,3 c2
FROM dual) tSELECT u.*
,CASE
WHEN u.c1 > 10 AND u.arany > 50 THEN
'x'
END hiba
FROM (SELECT t.azon
,t.c1
,t.c2
,CASE
WHEN t.c2 ! = 0 THEN
t.c1 / t.c2
END AS arany
FROM (SELECT 'a' azon
,20 c1
,30 c2
FROM dual
UNION
SELECT 'b' azon
,20 c1
,0 c2
FROM dual
UNION
SELECT 'c' azon
,40 c1
,NULL c2
FROM dual
UNION
SELECT 'd' azon
,500 c1
,3 c2
FROM dual) t) u -
#4091
user112
senior tag
Apollo17hu
#4090
user112
senior tag
válasz
Apollo17hu
#4090
üzenetére
Sajna pont ez a beágyazás nem megy. Ott nem enged hivatkozni az Arany-ra (invalid identifer) .
(zéró osztás kezelva van) -
#4090
Apollo17hu
őstag
user112
#4089
Apollo17hu
őstag
válasz
user112
#4089
üzenetére
Bele tudod agyazni az arany case when-jet egy masik case when-be. Vagy fogod a lekerdezesed, allekerdezesbe rakod, es ennek az allekerdezesenek az arany mezojere szinten tudsz hivatkozni.
Ha osztassal generalsz uj mezot, akkor tanacsos kivetelkezelest is alkalmazni a nullaval valo osztas hibalehetosegenek elkerulese erdekeben.
-
user112
senior tag
Sziasztok!
Az alábbi lekérdezéshez (Oracle) szeretnék hozzáadni egy számított mezőt (Hiba) :
Select azon, c1, c2,
(case when c2! =0 then c1/c2 end) as Arany, Hiba
...A Hiba mező attól függően változna hogy mekkora a c1 és az Arány értéke (több felzétel is lenne).
Pl. ha c1>10 and Arany>50 akkor kapjon valamilyen értéket.
... következő felfétel stb.Hogyan tudom ezt megcsinálni?
(nvl és raund is van a selectben de ezt nem írtam ide) -
Ispy
nagyúr
válasz
kezdosql
#4086
üzenetére
A kerdes az, hogyan lehet kozottuk a kapcsolatokat felepiteni.
Nem kérdés, relációs adatbázis...
Dimenzió táblák:
- csapatok
- szezonok
- játékosok
- bírók
- tökömtudjamégmiTénytáblák:
- meccsekpl:
Csapatok tábla:
- név
- alapítás éve
- tulajdonos_id
- címadatok
stb.Szezonok tábla:
- szezonok_id
- megnevezés
- kezdete
-vegeMeccs tábla:
- meccs_id
- szezon_id
- dátum
- hazai_csapat_id
- vendeg_csapat_id
- mikor
- eredményAmikor le akarsz kérdezni, akkor ahol id van, ott bejoinolod a törzsadatokat:
SELECT
szezonok.megnevezes,
meccsek.datum,
hazai.nev,
vendeg.nev,
meccsek.mikor,
meccsek.eredmeny
FROM meccsek
inner join szezonok on meccsek.szezon_id=szezonok.id
inner join csapatok hazai on meccsek.hazai_csapat_id=hazai.id
inner join csapatok vendeg on meccsek.vendeg_csapat_id=vendeg.idkábé, ezt most csak összeírtam gyorsan, de így kell elképzelni.
-
#4086
kezdosql
tag
Apollo17hu
#4069
kezdosql
tag
válasz
Apollo17hu
#4069
üzenetére
Csinálhatod azt is, hogy mindent, de mindent egyetlen táblában tárolsz.
Ez marhasag.
Ertelemszeru, hogy kulon tablakra van szukseg, a kerdes a koztuk levo kapcsolatok.
Minimalisan kell harom tabla, csapatok, szezon es meccsek.
A kerdes az, hogyan lehet kozottuk a kapcsolatokat felepiteni.Ertelemszeru, hogy adott szezonban vannak adott csapatok, de ez valtozhat - esemeny tortenik.
Ertelemszeru, hogy minden csapat minden mas csapattal jatszik - de nem mindig, itt is esemeny tortenik.
Ertelemszeru, hogy minden csapat egyszer otthon, egyszer idegenben jatszik - de nem mindig, itt is esemeny tortenik.A szezon az "x ev/x+1 ev" neven fut, allandoan valtozo kezdesi es befejezesi datumokkal, cask a sorszama biztos.
A meccsek minden szezonban vannak meghatarozva, mindig valtozo napokon, itt datum es ido mezo kell a
pontos beazonositasra.A korabbi javaslatod jo otlet volt, kell egy "szotar" segedtabla, amivel a fentiekhez meg lehet egy esemenyek mezot is felvinni, ahhoz is datum es ido kell, igy barmi tortenik a szezonban, jon egy esemeny, es kesobb annak alapjan lehet az elemzeseket megoldani es az esemenyeket "datum-ido" tipusu mezovel lehet kezelni.
.
Lehet, hogy az lesz a magoldast, hogy minden adathoz kell egy datum-ido mezot csatolni es az alapjan lehet megtalalni a rendezesi szempontokat a kesobbi elemzesekhez, de akkor meg kell oldani, hogy pl. az adott szezon az nem egy adat, hanem ketto, van kezdete es befejezese, mindketto datum-ido mezovel, es a szezon a kozottuk levo idosavra vonatkozik.Ez viszont nekem azt veti fel, hogy nem tudom a harom fenti tablat kozvetlenul osszekapcsolni, hanem valahogy mindig be kell iktatnom kozejuk ezt a "szotar" segedtablat, mert abban vannak a mindenhez kapcsolodo datum-ido mezok, ezzel akadtam el, tul sok a kapcsolat.
-
#4085
Ispy
nagyúr
david199801
#4083
Ispy
nagyúr
válasz
david199801
#4083
üzenetére
Az upperben el van írva a vm_rendeles_id? Ottan alul ki is írja.
-
#4084
tm5
tag
david199801
#4083
tm5
tag
válasz
david199801
#4083
üzenetére
Hát így első blikkre szerintem nem egészséges, ha az eljárás paraméternevek megegyeznek az oszlopnevekkel. Valahogy különböztesd meg őket.
Bár ez valszeg nem hiba, de engem kiráz a hideg azoktól a magyar ékezetes táblanevektől.
-
#4083
david199801
tag
david199801
tag
Elkezdtem próbálgatni előre megírt procedúrákat és tesztelgetni/javítani ha hibás. Ennél az egynél nem tudok rájönni hogy mi lehet a baj. Valaki aki jártasabb ebben tudna segíteni?
A választ előre is köszönöm
-
#4082
updog
őstag
david199801
#4081
updog
őstag
válasz
david199801
#4081
üzenetére
(#4079) doeeg második bekezdés. A SYSTEM user alá vagy bejelentkezve, ami nagyon nem jó. Nem azokat a táblákat kéne kitörölni (
tényleg szólj az oktatónak ha ő javasolta hogy ezzel lépjetek be), hanem saját user alatt kéne csinálni a játékot 
De hogy segítsek is a konkrét kérdésnél: ha jobb gombbal kattintasz a Tables (filtered)-re, lesz egy Apply filter menüpont, klikk oda. Itt egyesével hozzá tudod adni, hogy milyen táblákat akarsz látni, praktikusan NAME = VEVŐ, NAME = KÖNYVEK stb. feltételeket állíts be (upper/lowercase-re lehet hogy figyelni kell (ha pl. egyikféleképp nem működik), az ékezet se túl szerencsés a táblanevekben), "Match any" beállítással. + gombbal tudsz hozzáadni. Így nem fog látszani, csak az a tábla, amit te akarsz.
De attól hogy nem látod, még ott lesznek, továbbra sem javasolt a SYSTEM alatt garázdálkodni
-
#4081
david199801
tag
david199801
tag
Még egy kérdésem lenne hogy az sqldeveloper miért generálja le azt a sok táblát ott bal oldalt? Hogy tudnám azokat kitörölni?
-
#4080
velizare
nagyúr
david199801
#4078
válasz
david199801
#4078
üzenetére
legkönnyebben úgy, hogy ráteszel egy unique constraintet.
ALTER TABLE VEVO
ADD CONSTRAINT VEVO_R_NEV_unique UNIQUE(R_NEV);
commit;ez persze kizárólag technikai megoldásnak tekinthető, mert így nem lehet két ugyanolyan
nevűcímű vevőd ebben a táblában, ami azért üzletileg nem feltétlenül elfogadható. azaz ha én lennék a megrendelő, ezt a megoldást nem fogadnám el.ja és szólj nyugodtan a tanárnak, hogy hibás az anyag (legalább látja, hogy foglalkoztál vele).
-
#4079
updog
őstag
david199801
#4078
updog
őstag
válasz
david199801
#4078
üzenetére
Nézd meg, van-e valami ID a vevő táblában, és referálj arra (ha nincs, adj hozzá, trigger+sequence töltheti).
A screenshotból adódóan egy megjegyzés: a SYSTEM user alá nem nagyon illik semmit csinálni kézzel
Készíts egy játszós usert (google: oracle create user) vagy használd a sample sémákat (hr, oe, ilyenek).oracle.com tele van jobbnál jobb tutorialokkal (ha kifejezetten Oracle-t kell használni), nem nagyon lehet megúszni ha nem adják le szájbarágósan (nem szokták). Pl. [link]
-
-
#4077
velizare
nagyúr
david199801
#4076
válasz
david199801
#4076
üzenetére
a hibaüzenet elég egyértelmű. csak olyan mezőre lehet használni a referencest, amelyik unique a saját táblájában, vagy primary key (és emiatt unique).
-
#4075
velizare
nagyúr
david199801
#4070
válasz
david199801
#4070
üzenetére
az utolsó előtti sorba nem kell vessző.
CREATE TABLE Rendeles(
k_rendeles_id INT primary key,
r_tipus VARCHAR(50),
r_ar VARCHAR (10),
k_nev VARCHAR (100) references Könyvek(k_nev),
r_nev VARCHAR (10) References Vevő(r_nev)
);a képen jelzi is az sql developer, van utána egy hullámos piros vonal.
-
#4073
updog
őstag
david199801
#4070
updog
őstag
válasz
david199801
#4070
üzenetére
Létezik-e már Könyvek tábla, annak k_nev oszlopa, illetve Vevő tábla és/vagy r_nev oszlopa?
-
#4071
bambano
titán
david199801
#4070
bambano
titán
válasz
david199801
#4070
üzenetére
k_nev-nek nem adtál meg méretet.
-
#4070
david199801
tag
david199801
tag
Hali!
sqldeveloperben szeretném az adott táblát megcsinálni de nem engedi a hibakód
RA-00904: : érvénytelen azonosító
Ez lenne a parancs:
CREAT TABLE Rendeles(
k_rendeles_id INT primary key,
r_tipus VARCHAR(50),
r_ar VARCHAR (10),
k_nev VARCHAR references Könyvek(k_nev),
r_nev VARCHAR (10) References Vevő(r_nev),
); -
#4069
Apollo17hu
őstag
kezdosql
#4068
Apollo17hu
őstag
válasz
kezdosql
#4068
üzenetére
Csinálhatod azt is, hogy mindent, de mindent egyetlen táblában tárolsz.
Esemény dátuma, szezon, esemény megnevezése, eseményhez kapcsolódó játékos, játékos csapata, játékos lábmérete stb. Minden rekord rengeteg attribútumot (mezőt) tartalmazna, de az adattáblára írt lekérdezések az elvárthoz képest sokkal lassabban futnának, mert a tábla nem lenne normalizált.
Normalizáláshoz adatmodellt kellene kialakítani, ami viszont nem ott kezdődik, hogy az egyes mezőknek megmondjuk az adattípusát. Hanem megnézzük, hogy az ismétlődő értékek közül melyeket lehet dimenziótáblában tárolni. Ilyenek pl.: [dátumok] tábla, [csapatok] tábla, [játékosok] tábla, és ezek kapcsolódhatnának a ténytábláddal, amiben ezekre a táblákra csak hivatkozol, nem tárolod a bennük lévő összes mezőt.
-
#4068
kezdosql
tag
Apollo17hu
#4064
kezdosql
tag
válasz
Apollo17hu
#4064
üzenetére
Koszonom, talan valami ilyesmi lenne a megoldas, osszegyujteni egy tablaba mindenfele esemenyt es valahogy ahhoz igazitani a dolgokat.
-
martonx
veterán
válasz
kezdosql
#4063
üzenetére
például:
season from to
51 2016-09-01 2016-12-31
51 2017-01-01 2017-03-31Látod, mihelyst értelmeset, konkrétat kérdezel, már jönnek is a válaszok. Amíg csak általánosságban puffogtatod a hülye kérdéseket, addig ne lepődj meg, hogy általánosságban kapod a hülye válaszokat.
-
#4064
Apollo17hu
őstag
kezdosql
#4063
Apollo17hu
őstag
válasz
kezdosql
#4063
üzenetére
Csinalhatnal egy calendar tablat, amiben felveszed az osszes datumot. Teszel bele egy mezot, ami megmutatja, hogy az adott naptari nap melyik szezon.
Es lenne a tenytablad, amiben a konkrrt esemenyeket rogzited datumokkal. Ha rogzitettel egy esemenyt, akkor az esemeny datuma menten a calendar tablabol megtudod, hogy melyik szezont erinti.
-
kezdosql
tag
válasz
martonx
#4061
üzenetére
Folyamatosan lekezeltek, mikozben azt se ertitek meg, hogy ahhoz, hogy a program kodot megirjam, eloszor az adatstrukturat kell tisztazni.
Itt egy pelda:
Sport szezon 2016 osz/2017 tavasz - ez karakteres
ez az 51. szezon - ez numerikus
A csapat gyenge szereplese miatt 2016.12.10-en ket uj jatekost igazolnak le, amivel nyerove valnak.Hogyan osztod fel az 51. szezont (numerikus) 2016 osz/2017 tavasz (karakteres) idoszakot datumok szerint ket reszre?
-
-
-
kezdosql
tag
válasz
sztanozs
#4057
üzenetére
Date-vel vagy evet, vagy pontos napot kell megadni.
Az esemeny ev/ho szovegben szerepel idoszak cimen, karakteresen tol-ig savonkent, numerikus hivatkozassal a sorbaallitashoz.
Utobbival az esemeny megadhato.
Na de hogyan oldod meg, hogy a vizsgalt idoszak az par honap, es az esemeny kozben jelentkezik?
Aranyositod az idoszakot napra?
Akkor a savos idoszakokat at kell irni from-to datum mezokre, es ahhoz tartozhat a numerikus mezzo? -
martonx
veterán
válasz
kezdosql
#4053
üzenetére
"Korabbiakra nem jot semi valasz, ezert gondoltam, hogy mar cask en irok ide egy ideje." - korábban nettó hülyeségekkel traktáltál minket, kérdezés címszó alatt, nem csoda, hogy egy idő után már senki se válaszolt
Most hogy remélhetőleg elkezdesz normális, értelmes, konkrét kérdéseket feltenni, hidd el jönni fognak a válaszok is. Eddig se mi voltunk a helikopterek, még ha egy bizonyos szempontból ez úgy is tűnhetett
-
kezdosql
tag
válasz
martonx
#4052
üzenetére
Koszonom a gyors valaszt.
Korabbiakra nem jot semi valasz, ezert gondoltam, hogy mar cask en irok ide egy ideje.Most nem tudok semmit telepiteni es nincs is ra idom, plane, hogy megtanuljak uj programok kezeleset.
Amint irtam, a problemam lenyege az, hogy adatok neha bizonyos naptol megvaltoznak, igy ezt kellene valahogy kezelni, de korabban azt tapasztaltam, hogy datumot nehez bevonni az indexelesbe.
Igaz, regen csinaltam, raadasul, ahogy latom a fiddle MySQL alatt megy, nem tudom, az hogyan kezeli a datumokat, de majd jatszok vele.
-
martonx
veterán
válasz
kezdosql
#4051
üzenetére
Miért lenne döglött a fórum? http://sqlfiddle.com/
Itt tudsz játszani SQL engine-ekkel. Viszont nem egy mai darab ez az oldal.
Én a helyedben feltennék egy lokális SQL-t (PostgreSql / MySQL / MSSql / Oracle) és leginkább azon játszanék, ráadásul könnyen lehet localban backupolnod is, és bármikor visszaállítani.
Az SqlFiddle előnye pedig, hogy az alapján könnyen tudsz tőlünk segítséget kérni, ha megakadsz valahol. -
kezdosql
tag
Ha nem doglott a forum, akkor lenne ket kerdesem:
1. keresek olyan weboldalt, ahol kiprobalhatnek elesben egy pelda alkalmazast, ugy tunik, harom table es par segedtabla kell hozza, viszont bonyolult lekerdezeseket kell megoldani.
2. keresek valkit, aki segitene a tablak "idogepesiteseben", mert esetenkent naponta valtozo tartalmat kell egysegesen kezelni idoszakon belul.
-
kezdosql
tag
Bocs az off-ert, mashova nem tudom irni.
Meglepve hallottam, hogy volt magyar kezdemenyezes is Textar neven szoveges adatbaziskezelesre, de leszukult a celpiac a konyvtarakra es mas volt a favorit.
Erdekelne a szoveges adatbaziskezeles, kiprobalnek parat, ha tud valaki ingyeneset, vagy proba verziot ajanlani.
-
#4049
Peter Kiss
őstag
martonx
#4048
-
martonx
veterán
Ok, lehet hogy CROSS JOIN. Meg van még a FULL OUTER JOIN is. Viszont szerintem a JOIN-hoz az kell, hogy egyértelműen megadhasd, mit mivel kötsz össze. De most lusta vagyok utánuk olvasni, csak ötleteltem, hogy hátha segítek vele.
Ebben az esetben meg biztos, hogy vagy emberünk a béna, vagy a DB séma nevetséges, hogy ilyen kulcs nélküli mindent mindennel esetet kell lekezelni -
-
kw3v865
senior tag
Sziasztok!
PostgreSQL-ben a következő kérdésre keresem a megoldást: adott két view 1-1 oszloppal és azonos számú sorral. A cél az lenne, hogy egy új view-ban szerepeljen ez a két oszlop. Hogyan lehet ezt megoldani? Simán így, hogy SELECT * FROM t1, t2 nem megy, mert nagyon sok sort ad vissza. Nyilván a cél az lenne, hogy ne legyen duplikátumot. Azaz, ami az egyes tábla első sorában szerepel, mellé a másik view első sorában szereplő adat kerüljön, magyarul egymás mellé kerüljön a két oszlop. Van erre valami ötletetek? Joint nem lehet csinálni, mert nincs közös mező.
-
bandi0000
nagyúr
köszönöm,.végül is csak lenne még1 kérdésem
ha pl hirdetéseket tárolok, de minden hirdetésnél lehet több fajta tag, akkor azt hogy szokták tárolni? Legegyszerűbb példa
hirdetések táblába van azonosító, meg valami hirdetés cím, de ehhez meg lehetne adni több fajta cimkét
-
bambano
titán
"Ennyi erővel az árat és a darabszámot is ki lehetne tenni külön táblába, mert lehetséges, hogy különböző termékeknek ugyanannyi az egységára és ugyanannyi darabot vásároltak belőle ugyanakkor.": ez így nyilván csak a példa kedvéért került elő.
a termék árát akkor kell kivenni a vásárlásból, ha az minden vásárlásnál ugyanaz. tehát ha a bukóhullámú homálytizedelő mindig 3 gombba kerül, akkor a termék törzsben az ár helye, ha vásárlásonként változik az ára, akkor meg a vásárlás táblában. ilyenkor úgyis az lesz a vége a történetnek, hogy lesz ilyen-olyan vevő, más és más árengedménnyel, stb, és az ár marad a vásárlás táblában.
-
rum-cajsz
őstag
válasz
bandi0000
#4032
üzenetére
Ha jól értem a problémádat, akkor nem a dátumot/időt kell kitenni a külön táblába, hanem a vásárláshoz tartozó termékek listáját.
Tehát a te logikád szerint:
TERMÉK (termékid, terméknév, stb)
VÁSÁRLÁS (vásárlásid, eladó, vevő, dátum, fizetendő, stb)
VÁSÁRLÁSTÉTEL (id, vásárlásid,termékid, db, stb.)táblák kellenek.
-
bpx
őstag
válasz
bandi0000
#4032
üzenetére
Ennyi erővel az árat és a darabszámot is ki lehetne tenni külön táblába, mert lehetséges, hogy különböző termékeknek ugyanannyi az egységára és ugyanannyi darabot vásároltak belőle ugyanakkor.
Ezt pl. úgy szokták csinálni, hogy külön táblába kerül a vásárlás és annak a tételei, hogy milyen termékeket vettek. Pl.:
VÁSÁRLÁS(vásárlás_id, dátum+idő)
VÁSÁRLÁS_TÉTEL(vásárlás_tétel_id, vásárlás_id, termék_id, db, ár) -
bandi0000
nagyúr
sziasztok
Lenne egy elméleti kérdésem
Gyakorlatilag el kellene tárolnom egy vásárlás adatait
milyen termék, mennyit, mikor(dátum+idő),mennyiért
Az adatokat egyszerre tárolnánk el, tehát előfordulna, hogy több külön álló termékhez is tartozna pontosan ugyan az a dátum
gond ott kezdődik, hogy nyilván a Terméket kiteszem egy külön táblába, viszont a többi adat mehetne 1 táblába?
pl így:
TERMÉK(ID,Név);
VÁSÁRLÁS(termék_id, dátum+idő,db,ár)Mert a többiek szerint a dátumot is ki kellene rakni egy külön táblába, hogy ne legyen az, hogy minden egyszerre vásárolt, de különálló termékhez pontosan ugyan az az időpont tartozna, viszont itt egyszerre kellene írni 2 táblát, vagyis minden vásárlásnál a dátumot bele kellene rakni a dátumok közé, utána ennek az azonosítójával írni bele a vásárlás táblába
TERMÉK(ID,Név);
VÁSÁRLÁS(termék_id, dátumidő,db,ár)
DÁTUM(id,dátum+idő)Remélem érthetően fogalmaztam meg a problémát
-
Ispy
nagyúr
válasz
kezdosql
#4026
üzenetére
Kaptál értelmes választ, legalább is a kérdésedhez mérhetőt, de azóta is jöttek megoldások a problémádra.
szubjektiv kategoria
Nos, ennek a szakmának pont az a lényege, hogy ki kell szűrni egy nagy halom adatból, hogy mi releváns és mi nem az és ezek milyen kapcsolati hálót alkotnak. Ezt a tudást egy könyvből sem fogod elsajátítani, csak hosszú évek tapasztalatával, ha ebben a szakmában dolgozol.
-
Zalanius
tag
válasz
Siriusb
#4028
üzenetére
CASE-hez van egy példa fent a #3905-ben.
Ha csak az utolsó 3 hónap kellene, akkor esetleg az eredeti select is lehetne már előre így filterezve. A nem szükséges hónapoknál csak null fordulna elő. T-SQL-ben például ilyen most a [mar] oszlop, az eredeti soraid szerint:
DECLARE @t1 TABLE (col1 char(1), col2 int, col3 varchar(10));
INSERT @t1 VALUES ('a', 1, 'jan'),('a', 11, 'feb'),('b', 2, 'feb'),('c', 3, 'feb');
SELECT * FROM
(select col1 as [név], col2, col3 FROM @t1) AS src
PIVOT (SUM(col2) FOR col3 IN ([jan],[feb], [mar])) AS pvt;Ha mármost ez egy dinamikus menet lesz, és az IN ( ) részt valamilyen distinctből szedjük ki előre, a jan - feb - mar sorrendért eléggé meg kell majd küzdeni. Akkor már inkább lehetne simán sorszám.
-
Siriusb
veterán
Üdv urak!
Ne ijedjetek meg, de SQL-lel kapcsolatos kérdésem lenne. Sajnos olyan régen foglalkoztam ezzel, hogy a komplexebb ismeretek teljesen kiestek mára a fejemből. Na jó, az alapvető is. Amit megvalósítanék, hogy a sorokban tárolt adatot oszlopokba rendezve kérdezném le. Tehát:
col1 col2 col3
a 1 jan
a 11 feb
b 2 feb
c 3 feblegyen
név jan feb
a 1 11
b NULL 2
c NULL 3Arra már rájöttem, hogy a CASE lesz a barátom, viszont az a kérdésem, hogy egy menetben meg lehet-e valósítani, hogy a col3 értékei oszlopok legyenek?
Vagy először lekérdezem a col3-t, és ezen adatok segítségével dinamikusan először legenerálom az sql kifejezésemet egy string-ben, majd futtatom?
Az sajnos nem játszik, hogy fixen megadom az oszlopokat, mert csak az utolsó 3 hónap kéne. -
tm5
tag
válasz
kezdosql
#4026
üzenetére
A válasz amit hallani szeretnél:
- Írd be a Google keresőbe, hogy adatbázis tananyag. Az első 5 link az pont azokat a könyveket/tananyagokat hozza amit el kellene olvasnod, megértened és alkalmaznod, hogy valami kisüljön abból amit szeretnétek.A válasz amit a kollégák mondanak:
- Ahhoz, hogy ebből a kezdeményezésből legyen valami életszerű cucc, akkor ennél komolyabb hozzáállás kell. Kellene egy un. rendszerszervező aki leül a kollégáiddal és összeszedi, hogy milyen közérdekű és hasznos adat van amit meg lehetne osztani másokkal. Rendszerezi ezeket és összeül egy (adatbázis)fejlesztővel/rendszertervezővel és összeraknak egy rendszertervet (benne egy adatbázistervvel) amivel már lehetne menni pénzt kuncsorogni a megvalósításra.Hidd el, ha nem lenne itt segítőkészség, akkor ez a fórum évekkel ezelőtt kihalt volna.
-
kezdosql
tag
Nem tudom, mit vártál?
Empatiat, segitokeszseget, ertelmes valaszokat.
Sok konyv van adatbazisokrol, de egyet se talaltam arra, hogyan jutunk el az adatbazisokig.
Ugy tunik, ezzel a terulettel senki se foglalkozott, nincsen feldolgozva, nincsenek kategoriak, szakszavak, definiciok se, egyszeruen "adat"-rol beszel mindenki.A kommunikacios semaban van egyedul emlites "informacio es zaj" parosrol, de ott is szubjektiv kategoria, hogy mi az informacio es mi a zaj.
Adatnal is csak szubjektiv emlitesek vannak, hasznos, hasznalhato, felesleges, stb. ami mind-mind szubjektiv kategoria.
az adatbaziskeszitesnel is csak annyi szerepel, hogy elofeltetel az adattisztitas, ami az o ertelmezesukben azt jelenti, hogy mar megvan az adatsor, amibol - szinten szubjektiv modon - ki kell szedni az "oda nem valokat".
Ugy tunik, erre a teruletre nincsenek szakkonyvek, publikaciok, amit erosen furcsallok, mert mindenhol az elvaras, hogy legyen egy hasznalhato adatbazis, csakhogy azt nem a sult galamb hozza, ki kell alakitani.
Furcsa, hogy ennek meneterol egyikotok se ismer konyvet, amit ajanlhatott volna.
-
martonx
veterán
válasz
csurgoi
#4024
üzenetére
Kedves csurgoi!
Ebben itt nem fogunk tudni segíteni neked, helyi rendszergazdával, vagy az említett cég supportjával kell valahogy zöld ágra vergődnötök, hogy vajon miért nem sikerül a pdf generálás. A dolog innen távolról nézve elég egyértelmű, ha a pdf-ek generálódnak, akkor nem a külsős cég a ludas. Ez gondolom valami mappába belenézve látszódik. Ha nem generálódnak, akkor meg a külsős cég a ludas.
Tippre, a mappa jogosultságai állítódtak el, ahová a rendszer ezeket a pdf-eket mentené.ui. Nincs olyan hogy Adobe Raider, hanem Adobe Reader.
-
csurgoi
aktív tag
Kedves fórumozok!
Ide is írok hátha...
Segítséget szeretnék kérni a következő problémában:kisvállalkozásunk bérszámfejtését az Infotéka Kft Infoteka.Ber.Net programjával végzi.
A különféle listákat a program létrehozza és külső programként Adobe Raiderral lehívja.
A program egyik napról a másikra nem volt hajlandó ezeket a listákat létrehozni, hosszas homokórázás után a program egyszerűen kiugrik(bezár)
A suportosok fél napot távmunkáztak a gépen, eredménytelenül.
Azt mondják a bérszámfejtő programmal semmilyen gond nincsen, a hozzáférési jogok adottak, az Acrobat Raider biztonsági funkciói(ezek szoktak még zavart okozni) ki lettek kapcsolva.
Az utóbbi napokban semmilyen változtatás nem történt a gépen.
Win 10 Home van rajta, a bérszámfejtő program SQL adatbázis alapú.
Valakinek esetleg ötlete, vagy netán véletlenül ilyen esete? -
I02S3F
addikt
válasz
martonx
#4022
üzenetére
hanem mert ennyi infóval a kezünkben több értelme lenne az időjárásról beszélnünk, mintsem a konkrét problémáról
- A mérnöki gyakorlatban a probléma megoldás második lépése úgy szól "Szedj össze annyi információt , amennyit bírsz".Ennyiben meg tudom érteni miért szükséges az infó, persze én egyébként is bizalommal fordulok a fórumtársakhoz, egymás segítése a cél. Gyakran kérdezek és örülök, hogy van ez a fórum!
Rengeteget tanulni itt. 
-
martonx
veterán
válasz
kezdosql
#4017
üzenetére
"Van kulonbozo adatsorod - hogyan csinalsz beloluk adabazist?"
Vannak különböző összetevőid, hogyan csinálsz belőlük ételt?
Érted már, hogy mi a bajom az általánosságokkal? Milyen összetevőkből, milyen ételt? Sütni kell, vagy főzni? És még kismillió kérdésre kellene ahhoz pontos választ tudni, hogy azt lehessen mondani, hogy na ha van kenyered, tojásod, és olajod, akkor hol van leírva a bundáskenyér receptje. De te egy konkrét receptet vársz tőlünk, anélkül hogy megmondanád mit akarsz készíteni és miből. Nyilván mert te se tudod, de érted ez nem lekezelés, hanem próbálom megértetni veled, hogy ez így teljesen parttalan, és nem azért mert bunkó parasztok vagyunk, akik lekezelnek másokat, hanem mert ennyi infóval a kezünkben több értelme lenne az időjárásról beszélnünk, mintsem a konkrét problémáról -
Ispy
nagyúr
válasz
kezdosql
#4017
üzenetére
Nem tudom, mit vártál?
Ez azért ennél egy pöppet bonyolultabb szakma, hogy így egy fórumon bárki is tudjon ennyi infoból értékelhetőt mondani.
Ha jól értem szegény embernek ingyen kell dolgoznia először, hogy később kiderüljön, hogy ér-e a munkája egy forintot is.
Welcome to real world.
És az lenne a szakmai válasz erre, hogy igen megéri vagy nem, nem fogja? Lehet, hogy neked ez arrogáns válasz, de az a szakmai véleményünk, hogy fingung sincs erről, sőt, tovább megyek a 16 évnyi sql tapasztalatommal és lehet, hogy egy hét után sem tudnám megmondani.
Ha az a kérdés, hogy hogyan csinálja, akkor induljon el az adatok csoportosításával, hozzon létre adatbázis táblákat, relációkat, azt ossza meg és kérdezzen, vagy bízzon meg egy szakembert, aki ért hozzá.
Vagy azt gondoltátok, hogy majd tapasztalat nélkül ezt csak úgy össze lehet hozni? Nem, ha nincsen sokéves tapasztalata ebben, akkor nem lehet, a létrán minden fokot végig kell mászni, és majd évek múlva kiderül megérte-e.
Én is szeretnék holnaptól amcsi izomautókat csinálni, láttam a tévében, tök jó, akkor hol induljak el, hogy 1 hónap múlva én is tudjam csinálni? Kb. ilyen szintű volt a kérdésed....
-
tm5
tag
válasz
kezdosql
#4017
üzenetére
Én az általad leírt információk alapján és 30 éves adatbázisfejlesztői tapasztalattal azt javaslom, hogy kezdjétek el összerakni az adatokat egy Excelben. Bár táblázatkezelőként árulják, de nagyon sok üzleti adatkezelést (adatbázist) láttam már benne, vele elkészítve.
Rugalmas, egyszerű kezelni, bárki megtanulja, sok 100 000 sort lehet 1-1 oldalára rögzíteni. Hálózaton, felhőben (pl. Office 365) egyszerre többen is tudjátok párhuzamosan szerkeszteni.
Lehet benne lookup-okat (adatszótárakat) létrehozni és lehetne azt, hogy minden oldalra más adatokat (más rekordtípusokat) rögzítettek.Amikor eléritek az eszköz (Excel) korlátait, akkorra kialakul, hogy:
- tkp. milyen adatokat is akartok nyílvántartani
- mekkora adatmennyiségről van szó
- hányan férnének hozzá, milyen jogosultsággal
- és hogy mit is akartok kezdeni az összegyült adatokkal. (Pl. publikálni, weben megosztani, csak közigazgatás felé küldeni/fogadni).
Na ekkor kellene ezekkel a válaszokkal visszajönni ide a fórumba. -
kezdosql
tag
válasz
martonx
#4015
üzenetére
Remélem érzed a párhuzamot, minden arrogancia nélkül.
Erzem a maximalis elutasitast, hogy eszed agaban sincs megerteni a helyzetet, csak elvezed, hogy lekezelhetsz masokat.
Hihetetlenul egyszeru a tema:
Van kulonbozo adatsorod - hogyan csinalsz beloluk adabazist?Nem, nem a normalizalasrol van - arrol, hogyan jutsz el addig, hogy az adatokat ossze tudd kapcsolni, hogy elkezdhesd a normalizalast.
Remélem érzed a párhuzamot, minden arrogancia nélkül.
UI:
En se tudom, milyen palyazat, valami free sw vagy hasonlo nemzetkozi akcio, hogy mindenki ossza meg a meglevo adatait es hozzanak letre valami "big data" adatbazist es ebbol akarnak valami nagyot alkotni, mert a fejlett nyugaton mar minden adatot titkositanak vagy penzt akarnak a hasznalataert. -
#4016
kezdosql
tag
Peter Kiss
#4014
kezdosql
tag
válasz
Peter Kiss
#4014
üzenetére
Megirtam, hogy kozoltek vele, hogy alljon neki adatbazist csinalni, es ha kesz van, akkor lehet, hogy kapnak penzt, amivel nyugdijba meneteleig allast jelent szamara.
Mi az a generic cloud es hol talalhato?
-
martonx
veterán
válasz
kezdosql
#4013
üzenetére
De nézd:
1. nem tudjuk milyen pályázat
2. nem tudjuk milyen adatok
3. nem tudjuk mit jelent a feljavítani rajtuk
4. nem tudjuk mit kellene elérni a feljavítással
5. még csak az adatok formátumát se tudjuk, hogy mondjuk MS SQL vagy egy excel file, vagy papíron vannakCsak azt tudjuk, hogy pénz az nem lesz rá, illetve érteni se értenek hozzá. Mégis mit vársz? Belenézünk a mágikus gömbünkbe, és azt mondjuk, hogy van ez az XY könyv, ami pont azoknak az adatoknak a feljavításával foglalkozik laikusoknak, amikről nem írtad le, hogy mik azok
Fordítsuk meg a dolgot. Itt ülök, és épp egy program hibán dolgozok. Légyszi segítsetek már megtalálni, szépen kérlek titeket, tudom, hogy értetek hozzá. És kész, ennyi az összes infó.
Aztán amikor jönnek a hülye kérésre hülye válaszok, akkor meg besértődök, hogy mennyi arrogáns fasz van itt, értenek hozzá, de nem képesek megmondani, hogy hol van a hiba, mikor se azt nem írtam le, hogy milyen programnyelven, se azt nem hogy ez most egy mobil app, vagy épp egy webes rendszer, de még csak egy példa kódot se küldtem.
Remélem érzed a párhuzamot, minden arrogancia nélkül.
-
#4014
Peter Kiss
őstag
kezdosql
#4013
Peter Kiss
őstag
válasz
kezdosql
#4013
üzenetére
Egy dolgot nem osztottál meg: a pályázatot. (És esetleg a példákat, amiket emlegettél.)
Ráadásul önkormányzat + adatok? Ezekből semmit nem lehet igazán közzétenni csak úgy, illetve a nagy részének a kezelését viszi az ASP.
Ha meg igazából generic megoldás kell, akkor cloud, ott megtalálható minden eszköz bármire is.
-
kezdosql
tag
Ugy tunik, modositani kell a korabbiakat:
Az lehet, hogy szakertelem van, de a joindulat es az intelligencia mintha teljes mertekben hianyozna.Akkor egyben, roviden:
Igen, irhatnek regenyeket, de minek?
A lenyeget leirtam, egy szakertelem nelkuli kis onkormanyzat talalt egy palyazati lehetoseget, hogyha kozzeteszi az adatbazisat, akkor kaphat nemzetkozi tamogatast.Erre kertem segitseget, leiras, hogy milyen lepeseket kell vegrehajtani, biztosan van rola sok konyv es valahol sema is.
Sajnalom, hogy csak ostoba penzehesek reagaltak a nagy penzt latva a zsebben, semmi ilyesmirol ninics szo, egy szerencsetlen helyzetben levo onkormanyzat probal valahogy penzhez jutni, es az illetonek ingyen kell dogloznia, hogy hatha majd valamikor valaki ugy dont, hogy az o adatbazisuk is hasznalhato es attol kezdve bekerul a nemzetkozi projektbe.
Szamomra ez mezesmadzagnak tunik, es szegenynek ingyen kell dolgoznia sokaig, es varni arra, hogy valaki rabolintson, hogy van hasznahato adatbazisa.
Erzekeltettem a problemat, hogy lenyegeben csak adathalmazaik vannak, amiket erosen fel kell javitani, hogy hasznalhatoak legyenek adatbazisba bevitelre, ermeltem, hogy erre lesz legalabb egyetlen ertelmes valasz, hogy legalabb egy konyvet ajanl valaki.
Ehelyett lathato, hogyan reagaltatok, ami jobban minositi ezt a forumot, mint az en beirasom.
Azert nem adom fel a remenyt, hogy lehet meg ertelmes valaszt kapni.
-
Ispy
nagyúr
Tudod, sok pénz, kevés munka és gyorsan kész legyen, na ebből jó esetben kettőt választhatsz, rossz esetben meg egyett sem.
Hogy legyen egy kis segítség is: olyan nincsen, hogy egy idegen, aki tudja a gyors és sok pénz titkát az csak úgy jófejségből elárulja neked is, mert ő már gennyesre kereste magát és átment Teréz anyába. A többit a kérdező fantáziájára bízom.
-
GreenIT
tag
Kicsit off:
Emlekszik valaki, mi a neve egy autogyar altal elkezdett rendszernek - en a Bentley-re emlekeztem, de webes kereses nem adott talalatot - amit kesobb Unix alatt az IBM fejlesztett tovabb es repulogepgyartok hasznaltak, illetve hasznalnak a mai napig?
A lenyege az volt, hogy amikor modositottak egy modellen, akkor bizonyos alkatreszeket is modositani kellett, es miutan veglegesitettek a gepeszmernokok az uj alkatreszek parametereit, letrejott az uj alkatresz az elemlistaban. Ezert olyan nyilvantartas kellett, ami pontosan megmondta, hogy adott verzioju termekhez milyen alkatreszek illetve elemek kellenek es azoknak mik a parameterei.
-
kezdosql
tag
Olvasgatva a forumot komoly szakmai hatteret velek felfedezni sok hozzaszolas mogott, ezert merek kicsit off kerdest feltenni.
Egy ismerosomnek felajanlottak, hogy nyugdijas allasa lehet, ha letrehoz egy helyi adatkozpontot, "csak" egy kis elokeszito munkat kell vegeznie hozza. Amikor meglattam par peldat, akkor azonnal azt mondtam neki, hogy ezzel rengeteg munkaja lesz, ingyen kell dolgoznia, es utana varnia, hogy valaki elfogadja.
Lehet, hogy csak en vagyok negativ, ezert kernek segitseget,hogy a gyakorlatban mire kell figyelnie.
Elso lepesnek azt mondtam neki, hogy eloszor is tisztaznia kell az adatok tartalmat, majd csoportositani oket temakorok szerint, jo lenne cimkeket hasznalnia, hiszen egy adat sok mindenhez kapcsolodhat, igy kell egy katalogust csinalnia a meglevo adatokrol cimkek, vagy kategoriak szerint, es a vegen csak akkor tudja az ilyen adatbazisokat osszekapcsolni, ha azonos az idosor - de ez igy eleg pongyola.
-
GreenIT
tag
Azért kérdezem, mert utána olvasnék!
Maximalisan a sajat velemenyem, ezert teszem off-ba:
Sajat tapasztalatom, mert sajnos nekem anno access-t kellett tanulnom, hogy az csak arra jo, hogy nagyon gyorsan es egyszeruen ossze lehet kattintgatni vele egy adatbazis semat - amennyiben egyetlen szalra fel lehet fuzni oket. (Lasd: Kovácsné Cohner Judit · Kovács Tivadar · Ozsváth Miklós: Adatkezelés az MS Access 2000 alkalmazásával c. konyv kb. kozepen levo konyvtari kolcsonzesi peldat, ami elvileg latvanyos, csak amikor modositani kell a semat, akkor rajossz, hogy komoly gondok vannak, es nem igazan SQL szabvanynak megfelelo a mukodese.
Evekig szenvedtem utana, amig kezdtem megerteni, hogyan is kell SQL-ben gondolkozni.
tényleg szólj az oktatónak ha ő javasolta hogy ezzel lépjetek be), hanem saját user alatt kéne csinálni a játékot 
RA-00904: : érvénytelen azonosító
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Samsung Galaxy S24 Ultra Titanium Black Titán dizájn, 200 MP Pro kamera, S Pen
- Thinkpad T14s Gen4 14" FHD+ IPS i5-1335U 16GB 256GB NVMe ujjlolv IR kam gar
- iKing.Hu - Apple iPhone 16 Pro Natural Titanium Titán stílus, Pro teljesítmény - 2028. 07. 19
- Csere-Beszámítás! Macbook Air 13 2020! I3 / 8GB / 256 SSD. Akksi- 124 Ciklus
- iKing.Hu - HONOR 400 Lite 5G Velvet Grey Vékony, könnyű, AI-kameragomb 8/256 GB- 2027. 07. 01
- ÁRGARANCIA!Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RTX 3050 6GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! MSI Z390 i7 8700K 16GB DDR4 512GB SSD RTX 2060 Super 8GB Zalman N4 ADATA 600W
- Xiaomi 12T Pro 256GB, Kártyafüggetlen, 1 Év Garanciával
- LG 77CS6 - 77" OLED - 4K 120Hz & 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - Szupervékony
- Samsung Galaxy Tab A9+ 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest