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.

Köszönöm a tapasztalat megosztást. Most úgy gondolkodom, hogy ez egy folyamat. Viszont sokótok negatív véleménye miatt nem ásom magam mélyre az Access-ben.

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.

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.

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

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.

É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.

USE master;
GO
IF DB_ID (N'mytest') IS NOT NULL
DROP DATABASE mytest;
GO
CREATE DATABASE mytest;
GO

Ezzel megvolnánk, mit lehet még tudni?!

[ Szerkesztve ]

mondjuk excellel óvatosan, néhány exportált xls fileomat a mai napig nem lehet megnyitni memóriatúllépés miatt.

Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.

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....

[ Szerkesztve ]

"Debugging is like being the detective in a crime movie where you're also the murderer."

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?

https://500px.com/stevetailor https://www.flickr.com/photos/128564341@N08/

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.

Én kérek elnézést!

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.

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.

Ü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 feb

legyen

név jan feb
a 1 11
b NULL 2
c NULL 3

Arra 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.

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.

[ Szerkesztve ]

--= Zalán =--

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

Xbox One: bandymnc

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)

[ Szerkesztve ]

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.

[ Szerkesztve ]

=Kilroy was here============================ooO=*(_)*=Ooo=======

Igazából annyi adatot kell tárolni amennyit írtam, a legfontosabb csak hogy mennyiért vette, és mikor, ezért gondoltam, hogy elég 2 tábla

Xbox One: bandymnc

"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.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Így van, azért van ott a termék ára a VÁSÁRLÁS_TÉTEL-ben.

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

Xbox One: bandymnc

many-to-many kapcsolat [link]

[ Szerkesztve ]

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ő.

de mitől szerepel adott sorban egy érték?

ha valamilyen kritérium alapján fix a sorrend, akkor megrankolod mindkét nézetet és a rank alapján lehet joinolni.

szerk: vagy row_number.

[ Szerkesztve ]

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Persze, mert ez a szorzatát adja vissza.

MS SQL-ben UNION-t használnék, az összefésüli a két selectet:

select oszlop1 from view1

union

select oszlop2 from view2

"Debugging is like being the detective in a crime movie where you're also the murderer."

uniont a postgresql is ismer, csak ez nem az ő problémájára megoldás.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Az nem baj, hogy nincs közös mező, a CROSS APPLY (vagy OUTER APPLY mindig keverem őket, legalábbis MS SQL-ben ezek léteznek) éppen erre való.
Ez pont azt csinálja, ami neked kell: mindent mindennel összekombinálva, jeleníti meg az összes sort.

Én kérek elnézést!

Azt szabad tudni, hogy milyen probléma vezetett odáig, hogy erre keresed a megoldást?

Nem a CROSS JOIN kulcsol mindent mindennel? A CROSS APPLY is hasonlóan működik, de annak van még valami egyéb tulajdonsága, csak nem emlékszem pontosan, hogy mi.
Vagy rosszul tudom?

Tényleg.

"Debugging is like being the detective in a crime movie where you're also the murderer."

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

Én kérek elnézést!

Mindenképpen kell valami kapaszkodópont (említett row number), utána lehet:
- union + pivot
- sima join is vinni fogja
- temp table megoldással, ha nagyon akarom

De egyébként biztosan nem ez a probléma, hanem ahogyan mondtad a schema vagy más.