Szigorú számadású bizonylatoknál az NAV nem örülne az ilyesminek .

a megfelelő szó: reuse
de én úgy látom (Google) nem tud ilyet, szóval vagy egyedi megoldás kell, vagy hagyod így ahogy van, mert felesleges ezen izgulni

"Pozitív kritikát szívesen fogadok."
Ezen nagyot nevettem. DE POZITÍV LEGYEN ÁM!!!

Egyébként nem jó a struktúra, de azt mondtad, csak pozitív kritikát fogadsz szívesen.

[ Szerkesztve ]

Sk8erPeter

Ja, nem jó.

A user_hirdetés kapcsolótáblában inkább user_id és hirdetes_id-nak kellene szerepelnie.

De teljesen fölösleges is a kapcsolótábla, mivel ez egy one-to-many kapcsolat a user felől a hirdetések felé: egy user több hirdetés. így elég csak user_id-t tárolni a hirdetés táblában, mit te hirdető_id-nak nevezel. Kapcsolótáblát csak a many-to-many relációknál használnak.

... Esetleg akkor, ha a kapcsolatnak külön tulajdonságot rendelsz, ami a kapcsolatra vonatkozik. akkor viszont érdemes egy unique constraint-et tenni a kapcsolótábla hirdetés_id mezőjére, hogy elkerüld, hogy egy hirdetést véletlenül több felhasználóhoz kapcsolj

Hirdető táblában nem kell a hirdetés_id. akkor minden hirdetőhöz csak egy hirdetés tartozhatna. a hirdető<-->hirdetést megadja a hirdetés tábla hirdető_id-ja.

teljesítményben annyit tudsz javítani, hogy indexeld a keresésben használt mezőket, vagy ha egyszerre több mezőt is használsz egy-egy fajta keresésben, akkor indexet megadhatsz több mezőre is.
Ha pedig többmillió rekordod lesz meg brutál forgalom meg istentudja, akkor táblaparticionálás. ez a két legfontosabb dolog teljesítményben

[ Szerkesztve ]

modder sok mindent leírt előttem, ami a megvalósítást illeti, tehát azzal a résszel egyetértek. Viszont én még annyit tennék hozzá, hogy bennem a hsz.-ed láttán egyből az a kérdés merült fel, hogy vajon miért feltételezed, hogy a hirdető egy külön állatfaj. A hirdető is egy regisztrált felhasználó, tehát egy user, akinek a helye a user táblában van. Tehát teljesen felesleges a "hirdető neve, hirdető kora, hirdető egyéb adatai", stb. adatokat külön táblában tartani. Ez a felhasználóhoz tartozó adat (user tábla, vagy esetleg egyéb adatok miatt ehhez kapcsolt tábla, de ez opcionális). Az már másik kérdés, hogy ez a felhasználó egyáltalán hirdethet-e, ad-e fel hirdetést, és ha igen, az adott hirdetésekhez milyen adatok tartoznak.
Itt most a hirdetés hozzákapcsolása szempontjából tehát mellékes, hogy szerepkör alapján hirdethet-e csupán a felhasználó, vagy bármilyen bejelentkezett felhasználó feladhat hirdetést. Nyilván egy expressz.hu-hoz hasonló oldalon az a fő profil, hogy bárki feladhasson hirdetést (mondjuk adott összeg befizetése után), tehát ott nem kell külön hirdető szerepkör (hacsak nem a fizetés után kapja meg a felhasználó a "hirdető" szerepkört, ami akár le is járhat, de még ezt a kérdéskört is lehetne boncolgatni).

Lényeg tehát: a hirdető is egy felhasználó. A hirdetés pedig külön adat, ami - ahogy előttem elmondták - egyértelműen egy felhasználóhoz tartozik (elég ritka az az eset, hogy több embert akarsz megjelölni hirdetés feladójaként...), tehát itt nem kell külön kapcsolótábla a hirdetés-user kapcsolathoz.

Sk8erPeter

Felesleges bonyolításnak tartom a külön hirdető, meg user táblákat. Miért nem megy egybe?
És akihez tartozik hirdetés az hirdető, akihez meg nem, az user Kb. úgyis ugyanazt kell letárolni mindkét csoportról.

Én kérek elnézést!

Akkor ezt folytatva: mindenki érti már szerintem, mit szeretnél, úgyhogy még egy ilyen csodás példa nem kell a magyarázat tisztázásához . Előbb linkelt cucc utsó hsz.-ében leírtam, hogy OK, minden hirdető júzer, de nem minden júzer hirdető.
Tehát akkor rövidre zárva a dolgot: nem kell az a kapcsolótábla. A hirdető egyéb adataiba egyszerűen bepakolod a user id-t.

Persze lehet ezt tovább bonyolítani, ha még tovább lenne bontva, hogy bizonyos hirdetőknek extra paramétereik lehetnek, és akkor megint előkerül a probléma, hogy NULL értékűek bizonyos paraméterek azoknál a hirdetőknél, amelyeknél nincsenek meg azok az extra paraméterek.
Akkor már egy táblába kéne pakolni a user id-t, paraméter id-t, paraméterhez tartozó egyik lehetséges value id-t, és így tovább... de gondolom nálad egyezne az összes hirdető plusz adata.

[ Szerkesztve ]

Sk8erPeter

Az idei tanév kezdetétől fogok járni a suliba emelt infó faktra (felkészítés az érettségire), és mondta egyik haverom, hogy fogunk SQL-ben programozni a Microsoft Acces használata során, adatbáziskezelésnél.
Egy kicsit konyítok hozzá, még a PHP+MySQL -es ügyködéseimről maradt meg valami.
Állítólag nagyon hasznos, ti mit gondoltok róla?
Valami tutorialt tudtok dobni, ami ezt a fajta használatát mutatja be az Accesnek?

:D Semmi :D

"Állítólag nagyon hasznos"
Ki szerint? És milyen célra hasznos?

"ami ezt a fajta használatát mutatja be"
Melyik fajta használatát?

Egyébként felejtsd el, hogy hasznos, igazán komoly célokra nem használják. Ezerszer hasznosabb, ha a MySQL-re fekszel rá (ha már amúgy is van valami előismereted), vagy MS SQL Serverre, Oracle-re, stb... na, ezek hasznosak.

Sk8erPeter

Ehhez pedig én is még annyit hozzátennék, hogy az access-t, mint platformot vagy toolt amire alkalmazást lehet írni, tényleg felejtsd el. arra viszont jó, hogy gyakorold vele az SQL-t. Ha pedig az SQL-t már nagyjából ismered, a szemlélet és a szintaxis már nem annyira különbözik az egyes relációs adatbázisoknál. persze mindig vannak bonyolultabb esetek, amikor mélyebbre kell ásnia magát az embernek egyes adatbázis gyártók megoldásaiba.
Ha pedig azt mondod, hogy gyakorolni szeretnél, arra én is inkább a MySQL-t vagy az MS SQL express-t ajánlom, mert azok legalább rendes, "production" környezetben használt adatbázisok, és ingyenesek.

Egy eset van, amikor az Access tényleg hasznos. Mindenhonnan magába tud fogadni adatokat, és ezekkel SQL szinten tudsz dolgozni.
Van pl. néhány klasszikus SQL szerveren futó táblád, meg van néhány rendszeresen frissülő TXT file-od, meg pár excel táblázatod. Ezeket SQL szerűen együtt kezelni, joinolni stb. MS Access-ben pár kattintás.
Nagyvállalati környezetben számtalan ilyen eset előfordul.
Persze meg lehet ezer más módon is oldani a fentebb vázolt problémát, de az MS Access-es megoldás a létező leggyorsabb, legegyszerűbb.

Én kérek elnézést!

Az SQL tudás mindennél többet ér (bár kitudja pár év múlva a NoSQL-ek felfutásával mire lesz jó a mostani SQL tudásunk ), az MS Access-ennek csak egy speciális vetülete. Az Access SQL meg különösen kilóg az SQL-ek sorából.
A fentebb hozott Access-es példámhoz egyébként SQL tudás kell. A kattitngatást nem arra értettem, hogy az Access designerével join-olod a táblákat, hanem az adatforrások Access-be behúzására. Személy szerint Access-ben is mindig kézzel írom az SQL kódot, a kód designert kb. soha nem használtam még benne.
És nehogy Access pártinak gondoljatok, csak próbáltam rávilágítani, hogy a világ nem szimplán fekete és fehér.

Én kérek elnézést!

Ezt nem tudtam, ez tényleg hasznos funkció

"Egyébként felejtsd el, hogy hasznos, igazán komoly célokra nem használják."
Ezt meg tudom érteni, de érettséginél Accest kellesz használni.
Igazából csak ezért kérdeztem rá, meg hogy ez mennyire elterjedt, mert korábban én még nem is hallottam róla.

:D Semmi :D

Mennyire eltrejedt-re csak megerősíteni tudom martonix megjegyzését - miszerint bár nem elsődleges rendszerek, de korábbi felhasználói automatizálásból itt-ott igen komoly összetett alkalmazások nőttek ki Excel / Access vonalon (főleg kockázatkezelés és pénzügyi tervezés területén). Ha szerencséd van (illetve ha nincs szerencséd), akkor fogsz ilyenekkel szívni még 5 év múlva is, mire oda jutsz, hogy ilyen helyen dolgozz... De még akár foxproval is találkozhatsz.

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

És ez szerinted jó?
Amúgy az Exceles+TXT-s+rendes adatbázisos összekattintgatós móka valóban egyszerűnek tűnik, bár ha normálisan egységesítve vannak a dolgok, akkor elvileg nem lenne szükség TXT-re és Excelre, de nem akarok naiv lenni, tudom, hogy ez soha nincs így. Tehát az a funkciója hasznos lehet.

Amúgy sorolhatnál pár ilyen pénzintézetet (!), ahol az Access a fő alap, tényleg érdekelne.

Sk8erPeter

Nem lehetne konkretizálni? Biztos nem fognak lenyakazni érte...

[ Szerkesztve ]

Sk8erPeter

Én 3 cégre látok rá, ezekből kettő az igazán nagyok között játszik (vagy legnagyobb? hm...) A harmadik is komoly tényező. Őszintén meglepődnék ha a többiek nagy részénél nem fordulna elő MS Access.

Én kérek elnézést!

Sziasztok!

Egyetemen az ingyenes SQL Developert használtuk adatbázis-kezeléshez. Szeretnék itthon is kisebb adatbázisokat létrehozni, a Developer segítségével pedig SQL-kódok formájában lekérdezéseket írni.

Mi szükséges ahhoz, hogy a PC-men mindezt meg tudjam valósítani (ingyen)? Van-e esetleg egyszerűbb/kezelhetőbb megoldás az otthoni adatbázis-kezelésre?

A hangsúly az SQL-lekérdezéseken van, nem kedvelem az Access-szerű varázslást...

ez most komoly kérdés volt?
Például a Dreamcoder for MySQL-hez na vajon mi kell? Segítek kell egy Dreamcoder, meg egy MySQL.
Töltsd le őket, és hajrá

Én kérek elnézést!

Nincs meg az elméletem hozzá, csak lekérdezéseket írogattunk, arról szinte semmit nem tudok, hogy mi a teendő a MySQL szerver telepítésekor, és hogy mire kell figyelni, milyen kapcsolatokat kell beállítani telepítéskor stb. Erről is szükségem lenne egy emészthető leírásra, ha akad.

Segítek. Next - next - finish. Közben mindent default-on hagysz. Nem bonyolult ez.

Én kérek elnézést!

Sziasztok,
SQL serveres kérdésem lenne:
bcp-vel hogyan lehet kapcsolódni lokális SQL serverhez?
A lényeg hogy szükségem van az összes tábla *fmt formátum fájljára.

Egy hasonló importhoz kellene a text szétparzolását segítő formátum file. Ezt szererném legenerálni a céltábla (pubs..authors2 ) segítségével
BULK INSERT pubs..authors2 FROM 'c:\new_auth.dat'
WITH (FORMATFILE = 'c:\authors.fmt')

[ Szerkesztve ]

lokális MSSQL szervernél az első kérdés az, hogy van-e BCP a gépeden?
Ha van, akkor kapcsolódni ugyanúgy tudsz, mint SSMS-el.
Nem nagyon használtam a BCP-t, a help-je hátha segít.

bcp.exe /?

Így kiadja a help-et.

[ Szerkesztve ]

Én kérek elnézést!

Van a gépemen.
Microsoft Windows [verziószám: 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Minden jog fenntartva.

C:\>bcp
usage: bcp {dbtable | query} {in | out | queryout | format} datafile
[-m maxerrors] [-f formatfile] [-e errfile]
[-F firstrow] [-L lastrow] [-b batchsize]
[-n native type] [-c character type] [-w wide character type]
[-N keep non-text native] [-V file format version] [-q quoted identifier]
[-C code page specifier] [-t field terminator] [-r row terminator]
[-i inputfile] [-o outfile] [-a packetsize]
[-S server name] [-U username] [-P password]
[-T trusted connection] [-v version] [-R regional enable]
[-k keep null values] [-E keep identity values]
[-h "load hints"] [-x generate xml format file]

C:\>bcp help
usage: bcp {dbtable | query} {in | out | queryout | format} datafile
[-m maxerrors] [-f formatfile] [-e errfile]
[-F firstrow] [-L lastrow] [-b batchsize]
[-n native type] [-c character type] [-w wide character type]
[-N keep non-text native] [-V file format version] [-q quoted identifier]
[-C code page specifier] [-t field terminator] [-r row terminator]
[-i inputfile] [-o outfile] [-a packetsize]
[-S server name] [-U username] [-P password]
[-T trusted connection] [-v version] [-R regional enable]
[-k keep null values] [-E keep identity values]
[-h "load hints"] [-x generate xml format file]

C:\>

[link]

-S [server_name[\instance_name]

"Specifies the instance of SQL Server to which to connect. If no server is specified, the bcp utility connects to the default instance of SQL Server on the local computer."

nem ez kell neked?

Próbáltam de egyszerűen ezzel nem akar csatlakozni. Nálam az instance üres valami miatt. Lehet telepítésnél valamit nem jól pipáltam majd ránézek holnap.

Az Instance leginkább csak SQL Expressnél játszik. Lehet teljes SQL szervered van, azaz nem feltétlenül kell az instance-t megadni. Expressnél, localDB-nél viszont kötelező.

Én kérek elnézést!

Az Instance leginkább csak SQL Expressnél játszik. Ez biztos?

SQLServer 2008 Enterprise verzió-nál akarom megoldani a problémát. (Production server nem dev server)

[ Szerkesztve ]

Úgy mondanám, hogy Expressnél biztosan kell instance a szerver névhez.
Enterprise verziónál, ha ugyanazon db szerveren nem fut több különböző instance, akkor elvileg nincs is külön instance jelölés. Kivéve, ha a DB admin direkt úgy állította be, hogy akkor is legyen.
De nem vagyok DB admin, így nem vagyok 100%-kig biztos ez utóbbiban.

Én kérek elnézést!

https://technetklub.hu/blogs/sqlserver2008/archive/2010/08/10/sql-server-alapvet-233-sek-ii-r-233-sz.aspx

"Sokan tudják, hogy az SQL Serverből több példányt (azaz instance-ot) is lehet telepíteni ugyanarra az operációs rendszerre. ...
Az instance-ok közül legfeljebb egy lehet az úgynevezett default instance, a többi named instance kell hogy legyen. A default instance-nak nincs külön neve, azaz ő a futtató host nevével megegyező nevet visel, az SQL1 szerveren a default instance neve SQL1 lesz. A named instance-ok a host neve után backslash-sel elválasztva viselik a nevüket: SQL1\WEB, SQL1\TESZT stb. "

Igazából az Express beállíta magának alapból egy Instance nevet (nem hagyja defaulton). Nagy cégeknél meg azárt nem használják az instance nevet (vagy inkább nem szokták) - mert álatlában az a policy, hogy egy szerveren egynél több DB instance nem lehet. Inkább virtualizálnak.

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

Nagyon köszi sokat segítettél. Már még nem jutottam el a megoldásig.

Szerintem erre nincsen igazán jó szakirodalom. Esetfüggő, hogy mikor mennyire érdemes normálformára hozni, milyen táblastruktúrát érdemes létrehozni, mennyire kell teletömni indexekkel egy-egy táblát stb...
Egy-két SQL optimalizálás problematika elég szokott lenni, hogy felnyissa az ember szemét a DB tervezés alapjaira.
Nagyon általánosságban beszélve: 1. - 2. normálforma elég szokott lenni. Láttam olyan DB-t, ahol még az Igen/Nem is normalizálva volt külön paraméter táblába. Nos, ez már a ló túlsó oldalára átesés.
Ugyanez a helyzet az indexelésekkel. Egy bizonyos szintig nagyon jó, hogy van mindenféle joinokban használt index-ed. Aztán mikor már mindenen index figyel és szegény db motor egy-egy insertnél nem győzi az indextáblákat frissíteni, akkor ez már kontraproduktív.
Nagyon nincs, és nem is lehet általános érvényű tanácsot adni SQL adatbázis tervezéshez.

Én kérek elnézést!

Sziasztok!

Segítséget kérnék mert rekurzívban nem vagyok otthon.
1
2
3
4
5
6
7
8
9
10
Legyen adott ez az egyszerű táblázat, ebből kellene nekem egy ilyet csinálni:
1 1
2 3
3 6
4 10
5 15
6 21
7 28
8 36
9 45
10 55
Azaz az oszlop első két számát (nem id, csak egyszerű példát akartam) összeadom, ez összegét az oszlop következő számával adom össze, majd ennek az összegét a következővel és így tovább.
Aki vágja a rekurzívat annak kisujjból. Én egyszer írtam életem során egyet, egyszerű volt de megizzadtam vele, ez a része nem megy sajnos.
T-SQL nyelven kellene.

Üdv
ZoL

Life is too short to stay stock!

Ez mitől rekurzív?

Én kérek elnézést!

Szerintem Kovács László könyve nagyon jó a témában. Ha ezen végigrágod magad, akkor meg lehet az elméleti háttered az adatbázisok professzionális használatához, tervezéséhez.
[link]

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

Egyébként bármilyen csúnya is SQL-ben ilyet használni, de egy While ciklus szerintem erre pont megfelel.
Második sortól kezdve végiglépdelsz rajta, mindig kiveszed az eggyel előző számot, és azt hozzáadod egy 0-ról induló változóhoz.
És továbbra sincs ebben semmi rekurzió.

Én kérek elnézést!

Uhh ez szuper kis könyv. Sajnos még nem olvastam.

[ Szerkesztve ]

Ez is hasznos, és naprakész kis olvasmány TSQL vonalon.

[link]

Én kérek elnézést!