Új hozzászólás Aktív témák
-
Lacces
őstag
Köszönöm a válaszokat!
Másik kérdés, inkább adatbázistervezéshez kérnék segítséget . Webalkalmazásról van szó, felhasználó és felhasználói csoportok. (És ahogy gondolkoztam magamban, ez inkább adatbázis lenne).
Az elképzelésem az, hogy vannak különböző felhasználói csoportok. De minden felhasználót 1 táblában tárolok, és aki hirdető, vagy tag, annak külön táblában tárolom az egyéb adatait., nem pedig a felhasználó táblába minden, vagy másikban.
User tábla
- id
- username
- password
- email
- tipus
(esetleg aktiv-e)User_Hirdetés kapcsoló tábla:
- user_id
- hirdető_idHirdető tábla:
- Id
- Hirdető neve
- Hirdető kora
- Hirdető egyéb adati
....
- Hirdetés_idHirdetés
- Id
- Hirdető_id
- Hirdetés címe
- Hirdetés leírása
- Hirdetés egyéb adati.
...Erről az adatbázis tervezésről mi a véleményetek? Ki mit tanácsol. Pozitív kritikát szívesen fogadok. Ez lenne az első amit magamtól csinálnék, és szeretném jól csinálni, nem pedig "betanulni" a rosszat
Ez teljesítménybe mennyire jó? -
modder
aktív tag
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 ]
-
Lacces
őstag
válasz Sk8erPeter #1354 üzenetére
jó, rosszul fogalmaztam . Építő jellegű kritika... nem pedig, hogy ez, milyen sz***, inkább menj el vasútasnak stb... Na, halljam te hogy csinálnád
-
Sk8erPeter
nagyúr
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
-
Lacces
őstag
és Sk8erPeter és martonx, köszönöm a választ.
Picit tovább boncolgatom. A User_Hirdetés tábla az lett rontva névre, az valójában User_Hirdető kapcsoló tábla akart volna lenni.Ez csak egy elméleti gyakorlat... Na várj kitalálok valamit. Ez eszembe jutott és elgondolkoztam rajta.
Zsír, van egy példám .
Van egy weboldal, ahol mesehősök vannak rajta, és meg lehet rendelni az ő szolgáltatásukat.
Például.: (Ennél jobb példa nem jutott eszembe) Super Mario hirdet, mint hirdető. Én, mint oldal tulajdonos, a hirdetőtől szeretnék kérni vezeték nevet, kort, számlázási adatokat! (ezért kezelem külön, mert a sima felhasználótól ilyet nem kérek). A felhasználó, pedig tud üzenetet küldeni Super Marionak, hogy vezetéket kellene szerelni, vagy aranyat gyűjteni. Illetve tudom értékelni Super Mario hirdetését: Hogy hüm, ő egy nagyon jó vezetékszerelő.
Ahhoz hogy valaki hirdést adjon fel, az-az hirdessen, ahhoz regisztrálnia kell magát.És így a user_táblával eltudnám azt intézni, hogy ez a felhasználók beléptetéséhez kell és ennyi. És nem lenne egy csomó null, érték.
Felhasználó, tábla most is annyi adat, amennyi. Mit tud a weboldalon, csak regisztrált felhasználó tud üzenetet küldeni a hirdetőnek, esetleg kommentálni a hirdetésben látható terméket!(De egy mezei felhasználótól nem kérem, hogy adjon meg szállítási címet, keresztnevet, ezért tekintem őt, mint külön típus.). És egy nem regisztrált felhasználó nem tudja értékelni Super Mariot, meg üzit küldeni neki.
Akkor ezért szedném külön, hogy user tábla, hirdetés tábla, és hirdető_adatai tábla. (és akkor a hirdetőtáblában lenne: user_id, számlázási adatok stb.)
[ Szerkesztve ]
-
Sk8erPeter
nagyúr
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
-
Dave-11
tag
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
-
Sk8erPeter
nagyúr
válasz Dave-11 #1361 üzenetére
"Á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
-
modder
aktív tag
válasz Sk8erPeter #1362 üzenetére
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. -
martonx
veterán
válasz Sk8erPeter #1362 üzenetére
Tudok több olyan nagy pénzintézetet mondani Magyarországon, ahol jelentős programok MS Access-ben vannak megvalósítva.
Én kérek elnézést!
-
martonx
veterán
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!
-
PazsitZ
addikt
válasz martonx #1364 üzenetére
De azért abban talán megegyezhetünk, hogy többet ér az alapvető sql tudás, mint az access kattingatási tapasztalat.
Mert egy sql-es feltételezem megoldja az access-ben is a feladatot, addig fordítva már talán nem biztos, hogy ennyire triviális a dolog...
Bár lehet tévedek, bevallom, talán egy évtizede nem láttam már access-t[ Szerkesztve ]
- http://pazsitz.hu -
-
martonx
veterán
válasz PazsitZ #1366 üzenetére
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!
-
Dave-11
tag
válasz Sk8erPeter #1362 üzenetére
"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
-
sztanozs
veterán
válasz Dave-11 #1369 üzenetére
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...
-
Sk8erPeter
nagyúr
válasz martonx #1364 üzenetére
É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
-
sztanozs
veterán
válasz Sk8erPeter #1371 üzenetére
Én kettőről is (biztosan) tudok - mind a kettő benne van az első ötben a saját kategóriájában...
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...
-
martonx
veterán
válasz Sk8erPeter #1373 üzenetére
É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!
-
Apollo17hu
őstag
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...
-
martonx
veterán
válasz Apollo17hu #1375 üzenetére
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!
-
Apollo17hu
őstag
válasz martonx #1376 üzenetére
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.
-
martonx
veterán
válasz Apollo17hu #1377 üzenetére
Segítek. Next - next - finish. Közben mindent default-on hagysz. Nem bonyolult ez.
Én kérek elnézést!
-
lakisoft
veterán
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 ]
-
-
lakisoft
veterán
válasz martonx #1380 üzenetére
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:\> -
martonx
veterán
válasz lakisoft #1385 üzenetére
Ú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!
-
bpx
őstag
válasz lakisoft #1383 üzenetére
"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. " -
sztanozs
veterán
válasz martonx #1386 üzenetére
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...
-
lakisoft
veterán
Sziasztok,
Aki hasonló témában dolgozik várom szeretettel:
MSSQL, SQLSERVER, T-SQL, SYBASE adatbázisfejlesztők, DBA-k, üzemeltetők ide -
Lacces
őstag
Mivel olyan jól sikerült a JOIN-os témámmal berobbani MySql topicba, így jönne ide kérdésem.
Megbízható szakirodalmat, online anyagot tudnátok ajánlani adatbázis tervezéshez? (Mivel úgy nézz ki, hogy meló helyen nem tudok kitől kérdezni, így egyedül próbálnék belejönni)
Igényem lett, a profizmusra. -
martonx
veterán
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!
-
zolynet
addikt
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
ZoLLife is too short to stay stock!
-
-
martonx
veterán
válasz zolynet #1395 üzenetére
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!
-
martonx
veterán
Ez is hasznos, és naprakész kis olvasmány TSQL vonalon.
Én kérek elnézést!