- One mobilszolgáltatások
- Samsung Galaxy XCover7 Pro - burokban született One UI
- Xiaomi 14T - nem baj, hogy nem Pro
- iPhone topik
- Fotók, videók mobillal
- Android alkalmazások - szoftver kibeszélő topik
- Okosóra és okoskiegészítő topik
- Az Oppo Find X8 Ultra lett a legvékonyabb kameramobil
- Motorola Edge 40 - jó bőr
- WayteQ blog: Megérkezett az x995 androidos GPS
Új hozzászólás Aktív témák
-
rikxjeee
tag
válasz
kezdosql
#4272
üzenetére
"Az altalatok istenitett sqlfiddle mogott valodi szimulacio van?"
...
http://sqlfiddle.com/about.htmlAzt pedig, hogy melyik rendszerben hogy működik az ilyesmi, az adott dialektus dokumentációjában keresd, az sqlfiddle nem erre való.
-
martonx
veterán
válasz
kezdosql
#4251
üzenetére
Igen, profi vagyok, de ettől még nem én írtam az sqlite-ot. A lekezelő válaszaim pedig magadnak köszönheted mert folyamatosan kavarogsz, és össze-vissza kérdezel. Megkérdezted, hogy miért stringben tárolja az sqlite a dátumokat, miközben így utólag meg már azt kérdezed, hogy oké, de hogy kell kezelni sqlite-ban a dátumokat (ezzel kapcsolatban én is csak google-özni tudnék, mert sose használtam sqlite-ot). Nagyon nem mindegy a kérdés, mert hülye kérdésekre nyilván csak hülye válaszok tudnak érkezni.
És a drupal most komolyan hogy jön ide? Igen CMS-esekkel könnyen beleszalad ilyenbe az ember, de mi köze ennek bármihez, amiről eddig szó volt?
Azt látom, hogy csak kötözködni jössz ide, nem pedig tényleges tanácsokért. Én amikor már nincs min kötözködnöd, akkor bedosz, egy de szar a drupal kijelentést, fogalmam sincs miért
Mindenestre engem szórakoztatsz, szóval állok rendelkezésedre.
-
martonx
veterán
válasz
kezdosql
#4245
üzenetére
Szvsz rajtam kívül is mindenki fennakadt ezen, maximum leszarták annyira, hogy ne tegyék szóvá
![;]](//cdn.rios.hu/dl/s/v1.gif)
A nekem címzett kérdésed félre ment, talán ezt a kérdést az sqlite fejlesztőinek kellene feltenned, nem én készítem az sqlite-otHa olyan adatbázis kezelőt keresel, amit egy szál file másolásával el tudsz a cél user gépére juttatni, és az magán belül oldjon is meg mindent, akkor arra valóban az annyit ócsárolt MS Access a legalkalmasabb.
Milyen verziókkal vannak a gondok?
-
martonx
veterán
válasz
kezdosql
#4230
üzenetére
Te mekkora erővel írod a hülyeségeid.
Egyrészt a C# az nem C
C#-ot meg 3 éve már .Net Core-al szokás használni, ami teljesen platform független, linuxon, osx-en, és windowson is fut. A grafikus megjelenítés persze más tészta, csak a konzolos megjelenítés cross-platform, ha szép ablakokat akarsz minden platformon, akkor az is megoldható, de az pár fokkal macerásabb.
A C# fejlesztői csicsák, ahogy te fogalmaztál szintén ingyenesek, és szintén cross-platformok.
-
martonx
veterán
válasz
kezdosql
#4211
üzenetére
Nem értettem félre
Exe készítésre megvannak a bevált módszerek, erre valók az installer készítő programok, amiknek megadod a forráskódod, és a végén kapsz egy szép nagy exe-t.
Én C#-ot használok, az jelen verziójában imád a végső exe mellé egy csomó kis dll függőséget pakolni, bezip-eled, a user kizipeli egy mappába, és máris ott az exe, amit kattintgathat. Ha a zip nem tetszik, akkor jön a setup készítők tömkelege, válassz egy szimpatikusat, és az csinál egy szép setup varázslót, amit a user next-next-finish-el végignyom.A 3.0-ás verziójától kezdve (ami várhatóan szeptemberben jelenik meg), viszont már out-of-the-box tud a .net core is egy szál óriás exe-t csinálni neked: [link]
-
Ispy
nagyúr
válasz
kezdosql
#4212
üzenetére
Az adatbáziskezelő szoftverek így működnek: van egy valamilyen backend (SQL server pl.) és van a frontend (.net pl.), ami lekérdez, megjelenít, keres stb., de ezt konyhakészen nem kapod meg, meg kell csinálni, erre vannak a programozók.
A legegyszerűbb megoldás, amivel egy laikus is eltud kezdeni dolgozni, az mondjuk egy MS Access, az összes többi megoldás ettől fényévekre van. De ahhoz meg office kell....
-
bambano
titán
válasz
kezdosql
#4202
üzenetére
egyrészt a clipper nagyon jól fut dosemuban.
másrészt létezik, flagship néven.szerk: persze lehet, hogy félreértettelek. ha az az elvárás, hogy egy exe legyen, ami clipper kompatibilis adatbázisokat kezel, akkor flagship. ha az az elvárás, hogy egy exe, akkor beépíthető, külön telepítést nem igénylő adatbáziskezelő van kilószám, akár firebird, akár más.
-
martonx
veterán
válasz
kezdosql
#4112
üzenetére
Ember, ezért küldtem konkrét sql scriptet, amiben a végdátum NULLABLE. Azaz nem kell megadni, majd akkor megadod, amikor valóban végetért.
Könyörgöm, tanulj már meg végre SQL-ezni, és tereld már a szakmaiság, és a konkrét megoldás felé magadat, a rózsaszín ködben papíron rajzolgatás helyett, mert ez így borzalmas.
Idióta vádaskodások, belemagyarázások helyett. -
#4114
Apollo17hu
őstag
kezdosql
#4112
Apollo17hu
őstag
válasz
kezdosql
#4112
üzenetére
Mindkét megoldásnak van létjogosultsága. A te verziód akkor lenne használható, ha minden egyes napra generálnál egy rekordot, ami a napra vonatkozó aktuális állapotot mutatja. Intervallumok használatával viszont egy csomó erőforrást megspórolsz. Csak akkor van szükség új rekordra, ha valamelyik mező adattartalmában változás történik.
-
válasz
kezdosql
#4112
üzenetére
A végdátum mindaddig 9999.12.31,amíg adott személy, adott szervezethez tartozik, ha átigazol, akkor ezen a rekordon kap egy végdátumot, majd egy új rekortban a végdátum +1 nap kezdeti dátummal kerül a másik csapathoz (ha nincs szünet a két csapattagság között). Így egy mérkőzésnél pl. elég csak a mérkőzés dátumát, és a játékosok ID-ját megadni, a fenti törzstáblából már levezethető, hogy melyik csapat mérkőzött egymással.
-
martonx
veterán
válasz
kezdosql
#4109
üzenetére
Te meg beláthatnád, hogy segíteni próbáltam, de akkor inkább hagyom. Hidd el, lehet papíron rajzolgatni, meg azt mondani, hogy ez, az lényegtelen, aztán a papíron rajzolt valamiket úgyis SQL-ben kell megvalósítanod - ha egyáltalán megvalósíthatóak (persze csinálhatod papíron is, csak az senkit nem fog érdekelni, ez esetben ebben a topikban is kár az időnket rabolnod tovább).
Eddig az volt a baj, hogy semmi konkrét segítséget nem kaptál, most meg az a baj, hogy kaptál. Részemről én itt szálltam ki. Sok sikert!
-
martonx
veterán
válasz
kezdosql
#4105
üzenetére
Ez így totál parttalan. Megmutatom miről beszélek, most hogy legalább minimum konkrétumot már kihúztunk belőled. A HELYEDBEN én valahogy így állnék neki az egész beszélgetésnek:
Sziasztok, foci mérkőzéseket, meg egész szezonokat, bennük minden létező eseménnyel szeretnék adatbázisban lemodellezni. Jelenleg itt tartok: sqlfiddle példa (egyszerűség, és a példa adatok minimális száma miatt nem szórakoztam Foreign keyekkel)
Az a problémám, hogy...
Amíg nem sikerül a kérdéseidet ilyen formában megfogalmazni, kár is a fentieknél konkrétabb válaszokat várnod.
-
Ispy
nagyúr
válasz
kezdosql
#4105
üzenetére
A csapatok, ugy latom, egyertelmuek szamodra.
Számomra az egész egyértelmű, csak arra próbálunk rávezetni, hogy jó lenne ezt az egészet, ami már megvan SQL táblákba foglalni és azt felrakni ide.
Az elso ket kategoria mindig adott csapathoz tartozik, az utolso mindig fuggetlen.
Igazából tökmindegy. Kell egy személyek tábla, aminek szintén van ID-ja (meg egyébként minden táblának rendelkeznie kell elsődleges kulccsal). Kell egy csapat tábla és kell egy csapattagok tábla, ami tartalmazza, hogy melyik személy meddig volt a csapat tagja, vagy melyik csapatnak még a tagja.
En a "flag"-et nem ertem, meg sose hallottam rola.
Egy szimpla bit, igen/nem, mindegyiknek egy: játékos, edző, bíró.
Én itt kiszálltam, amíg nincsenek kész táblák és azok kapcsolatai felrakva ide...
-
Ispy
nagyúr
válasz
kezdosql
#4101
üzenetére
Szerintem azért vagy bajban, mert nincs olyan, hogy "Az esemény".
Esemény lehet egy mérkőzés, egy átigazolás.
Tehát kell egy olyan tábla, hogy:
- mérkőzések
- átigazolásokMindegyiknek más a struktúrája, de mindegyikből ki lehet nyerni egy dátumot, egy esemény megnevezést, így össze tudsz rakni egy queue-t ami dátum szerint sorba rendezve mutatja a mérkőzéseket és eseményeket.
Ezt a sok csapat és sok személy dolgot meg nem értem vagy te nem érted a relációs adatbázis működését.
Egy mérkőzéshez max. 2 csapat tartozhat, 1 bíró, 1 tartalék bíró és 2 partjelző.
Viszont mivel a játékosok, bírók és partjelzők között bármilyen átfedés lehet, ezért a személyek táblába kellenek flagek, amikkel be lehet állítani, hogy az adott személy melyik halmazoknak a tagja.
Itt már írtam róla bővebben...ezt kell kiegészíteni pár dologgal, elég egyszerűnek néz ki nekem.
Sokkal egyszerűbb lenne az élet, ha feldobnád ide a táblákat, amik már készen vannak, és azok mentén raknád fel a kérdéseket, mert arra lehet gyorsan válaszolni, nincsen időm és kedvem az egészet megtervezni helyetted.
-
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) -
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:-(
-
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.
-
#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.
-
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.
-
-
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
-
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. -
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.
-
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.
-
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. -
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.
-
#3322
PumpkinSeed
addikt
kezdosql
#3270
PumpkinSeed
addikt
válasz
kezdosql
#3270
üzenetére
Szerintem neked pont egy Elasticsearch Kibana párosra van szükséged, ahol a már meglévő adatokat egy interpreter segítségével CSV-ből átteszed az Elasticsearch-be amit azután a Kibana segítségével szépen meg tudsz jeleníteni és minden látsz a webes felületen, mikor mi hogyan lett hozzáadva. Itt egy kis ismertető a Kibana-ról Illetve a full Elastic-stack itt van leírva.
-
Ispy
nagyúr
válasz
kezdosql
#3282
üzenetére
Egyrészt a nevem Ispy, másrészt szövegértelmezésből sem vagy túl jó, én azt írtam, hogy hozzá létre egy sql adatbázist, és oda told fel az excel tábláidat, harmadrészt nem vagyok zseni és nem is képzelem magam annak, negyedrészt rohadtul nem értem miért szemeteled tele az SQL topikot olyan dolgokkal, aminek semmi köze az SQL-hez.
-
PazsitZ
addikt
válasz
kezdosql
#3270
üzenetére
Valahol érthető, h frusztrált vagy,m ert a feladat amit kaptál nehéz fárasztó és időigényes. De épp ezért is dedikáltak hozzá egy külön embert.
Az viszont nem sokat segít, ha mindenkit lehülyézel, aki segítene, részben azért mert nem érted, amit mondanak.
Ennek fényében az arcoskodás és lenéző modort el lehetne hagyni.A feladat már csak azért is nehezített, mert ha igazán használható adatépítéshez nem árt tudás is a dologhoz, mondjuk olyasmi, amelyeket külön kurzusokon oktatnak egyetemeken.
A másik oldal a specifikus domain tudás, ami az adatok azonosítását könnyítené meg.A leginkább hasznos szerintem az, ha entitásokat határozol meg a lehetséges attributumokkal, és a köztük lévő relaciókkal. [link]
[link]Majd feltehetőleg ezeket az attributumokat tudod az adatforrások soraihoz oszlopaihoz rendelni.
Még fontos lehet, h az adat kötelező vagy sem?
Az adatokat milyen formátumban adottak és milyenben akarjátok tárolni? (milyen típusra mappelhető)
Ezeket a konverziókat a migráció során konvertálják a fejlesztők vagy te magad, mondjuk excel makrókkal?
... -
Ispy
nagyúr
válasz
kezdosql
#3270
üzenetére
Lehet, hogy kaptam egy nyugdijas allast.
Te írtad, de nekem meg úgy tűnik, hogy kaptál egy olyan melót, amiről lövésed sincsen. Szerintem menekülj amíg lehet. Túl nagy falat lesz ez.
Egyébként meg válaszoltam én is, mások is, ha ennyiből nem megy, akkor ne rajtunk kérd számon.
Én meg nem szoktam taposni sehova és nagyfomeltosagu sem vagyok, de ha valaki ad egy specifikáció nélküli excelt, akkor visszab@szom neki, mert se időm, se kedvem találgatni, egyébként ez meg alapkövetelmény egy bármilyen importnál/interface-nél.
-
DNReNTi
őstag
válasz
kezdosql
#3270
üzenetére
Komolyan egyre inkabb nem ertem, hogy kapcsolodik ez az SQL topikhoz. Arrol nem beszelve, hogy te "mindossze emberi hozzaallast varsz", azoktol az emberektol, akik "azt se tudjak, mit kene csinalni" es "egyikojuknek sincs fogalma se rola, mert ok csak abban gondolkoznak, hogy vannak adattablak, amiket csak ossze kell kapcsolni es kesz", illetve nem kis cinizmust felfedezve "nagyfomeltosagu programozo urak", raadasul ok "lefele taposnak, elvarjak, hogy pontosan azt az adatot kapjak, amire szukseguk van".
Kabare ez az egesz kerem. -
DS39
nagyúr
válasz
kezdosql
#3264
üzenetére
Nem, egyikotoknek sincs fogalma se rola, mert ti csak abban gondolkodtok, hogy vannak adattablak, amiket csak ossze kell kapcsolni es kesz.
ja, csak ennyiből áll az sql...de igazad van a te feladatot sokkal nehezebb, én tuti nem csinálnám, adminisztratív munka, engem az adatok információ tartalma sosem érdekelt. (az a megrendelőt érdekli, ehhez kell előállítani a megfelelő adatbázis-környezetet)
viszont nem is tudom miért írtál az sql topicba, hiszen a feladathoz maximum excel szükséges.
-
DNReNTi
őstag
válasz
kezdosql
#3261
üzenetére
Szerintem itt a tobbseg eleg jol tudja mit kellene csinalni egy ilyen feladattal, en inkabb azt erzem, hogy te nem tudod, hogy egyaltalan mit akarsz csinalni / csinaltatni, mi a cel, a specifikacio roppant feluletes, totalis fogalmi zavar van, es a faradtsagot sem veszed arra, hogy rakeress a kulcsszavakra amik itt mar elhangoztak.
Nem bantasnak szanom, csak nem ertem ezt az oszto dumat, a fent leirtak es annak figyelembevetelevel, hogy vagy harman probaltak segiteni hasznalhato otletekkel. -
DNReNTi
őstag
válasz
kezdosql
#3254
üzenetére
Gondolom CSV lesz az a CSS.
Egyebkent egy ilyen tok altalonos import rendszert megirni nem egy trivialis feladat. Ilyenkor a legjobb talan az, ha elmondod hogy fog kinezni a bemenet (altalnossagban, tehat: formatum, kotelezo fejlecek, max oszlopszam, stb), es te a vegen mit szeretnel latni. A 60 oszlop egyebkent nem szamit orulten soknak. Sot.
-
martonx
veterán
válasz
kezdosql
#3226
üzenetére
Majd idővel ez a tapasztalat is megérik benned, minden munkánál vannak jelek, amikből könnyű következtetni, hogy van-e értelme foglalkozni a dologgal. Az Acess2000-ről (még most is röhögök ahogy leírtam) szinte már üvölt, hogy kerüld el minél messzebbre azt a céget, aki ezt használja, és nem is hajlandó másra.
-
DS39
nagyúr
válasz
kezdosql
#3224
üzenetére
A, leirnad, hogyan nez ki egy kapcsolotabla es mivel kossem ossze?
a felhasználó id-t összekapcsolod a pozíció id-val.B, ugy erted, hogy logikai adatok legyenek, amiket vegig kell pipalni minden egyes alkalommal?
attól függ milyen sql-ben csinálod, de az adatbázisban ez kinézhet úgy hogy 1 az igaz, 0 a hamis értéke.az általad írt program felületén bármelyik megoldást használod, mondjuk a checkbox-okat pipálgatnia kellene annak, aki kezeli a dolgozók adatait, utána nyilván lekérdezed és nem kell ismét bepipálni mindig, hanem kitöltődik az az érték amelyik igaz rá. (persze meg lehetne oldani listbox-szal is, ahol többet is lehet választani egyszerre, de a lényege ugyanaz)
a kérdéseid alapján kicsit távolinak érzem a szükséges tudást és a bevállalt/rád kiosztott feladatot.
-
DS39
nagyúr
válasz
kezdosql
#3222
üzenetére
hát ezt kétféleképp is meg lehet oldani. egyik sem bonyolult.
A) két tábla, felhasználók és pozíciók, és csinálsz egy kapcsolótáblát amiben összekötöd, őket, ebben a táblában értelemszerűen lehetne többször ugyanaz a személy, más-más pozícióban.
B) megoldás: felhasználók táblát kibővíted plusz oszlopokkal, amik a pozíciók nevei, és vagy igaz vagy nem az adott emberre az a tulajdonság.
az amit jelenleg csináltál nem igazán járható út, főleg mivel felületet is kell hogy csinálj mindehhez, ahol nyilván látni szeretnék majd az összes ember adatait, amit ha 8 táblában vannak szétszórva, eléggé macerás lesz majd lekérdezést írni, meg adatokat módosítani a felületről.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Kabare ez az egesz kerem.
Új hozzászólás Aktív témák
Hirdetés
- Mielőbb díjat rakatnának a görögök az olcsó csomagokra az EU-ban
- Egyre csak fejlődik az AI, emberek tízezreit rúgja majd ki a BT
- Tomasz72: Ventilátor upgrade
- Kerékpárosok, bringások ide!
- Kuponkunyeráló
- Spórolós topik
- Zyxel NAS326
- Minecraft
- Dell notebook topic
- Forza sorozat (Horizon/Motorsport)
- További aktív témák...
- BESZÁMÍTÁS! Asus A520 R5 3600 16GB DDR4 500GB SSD RTX 2060 8GB Rampage SHIVA CoolerMaster 700W
- BESZÁMÍTÁS! MSI B550 7 5800X 16GB DDR4 512GB SSD RTX 3070 8GB Rampage SHIVA Enermax 750W
- BESZÁMÍTÁS! MSI B450M R7 2700X 32GB DDR4 512GB SSD RTX 3050 8GB Rampage SHIVA Thermaltake 500W
- BESZÁMÍTÁS! ASRock B460M i5 10400 16GB DDR4 512GB SSD RTX 2060 Super 8GB Rampage SHIVA TT 500W
- Xbox Series S 512gb 2 kontroller
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! Gigabyte A620M R5 7500F 32GB DDR5 512GB SSD RX 6700 XT 12GB ZALMAN S3 TG CM 700W
- BESZÁMÍTÁS! MSI B550M R7 3700X 16GB DDR4 512GB SSD RTX 3060Ti 8GB NZXT H5 Flow RGB 650W
- BESZÁMÍTÁS! SAPPHIRE VEGA 64 8GB HBM2 videokártya garanciával hibátlan működéssel
- Honor 200 Pro 512GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged