Új hozzászólás Aktív témák
-
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 ]
-
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!
-
pittbaba
aktív tag
Itt a BKK GTFS db, csak hogy ne kelljen keresgélni:
[link]Példák:
stops:
stop_id,stop_name,stop_lat,stop_lon,location_type,parent_station,wheelchair_boarding
F00001,"Mihály utca",47.486079,19.034561,,,2stop_times:
trip_id,arrival_time,departure_time,stop_id,stop_sequence,shape_dist_traveled
A651191,03:46:00,03:46:00,F04679,010,0trips:
_id,service_id,trip_id,trip_headsign,direction_id,block_id,shape_id,wheelchair_accessible,trips_bkk_ref
6100,A65119ASZGPP-021,A651191,"Örs vezér tere M+H",1,A65119ASZGPP-021_10A,1226,2,61001A gps koordináta kerekítés elve megvan, de mivel az szerintem még lassabb lesz, egyelőre megálló névre keresek rá:
SELECT stop_name,stops._id,stop_times._id,trips._id FROM "+MYDATABASE_TABLE+" JOIN stop_times ON stops.stop_id= stop_times.stop_id JOIN trips ON stop_times.trip_id = trips.trip_id WHERE stops.stop_name LIKE '%"+searchstr[0]+"%' GROUP BY stop_times.stop_id"
Ha azt kérem: Deák tér, meg is kapom vissza, szóval megleli, de kb 10 perc alatt, mert a stop_times tábla nagyon nagy és végig kell nyálazza. Olvastam, hogy létre lehet hozni index-et a tábla oszlopaihoz, milyen oszlopokhoz érdemes? Ez után az eredeti lekérdezést kell használni továbbra is, csak az adatbázison gyorsít valamennyit?
Nem tudtam jól megfogalmazni a módosítással mit akartam mondani. A lényeg, hogy lenne olyan megoldás is, hogy a három táblából csinálok egy leegyszerűsítettet, melyik GPS koordinátákhoz mely járatok tartoznak, viszont mivel az alapformátum CSV és a célformátum mysqlite db fájl, nehéz olyan scriptet írni ilyen sok sorú fájlnál, ami nekem ezeket összemergeli egy táblába logikusan. A kész db táblákból csinálni egy újat is lassú, mert ugyanúgy soronként kell haladni.
UI: A GPS koordináták kerekített lekérdezését így oldom meg, hogy legyen hibahatár:
SELECT * FROM "+MYDATABASE_TABLE+" WHERE ( stop_lat > '"+latstart+"' AND stop_lat < '"+latend+"' ) AND (stop_lon > '"+lonstart+"' AND stop_lon < '"+lonend+"')Egyszerű, működik, de gondolom bazi lassú lesz :S
[ Szerkesztve ]
PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM
-
pittbaba
aktív tag
Wow! Köszönöm a rengeteg infót, átrágom rajta magamat részletesen is.
Első körben annyit, hogy azért lenne jobb a három tábla összekapcsolása, mert nekem GPS alapján az lenne jó, ha a a lehetséges járatnevek jönnének ki, ne kelljen megállót választania külön. Általában az ember azt tudja mire akar, mire kell felszállni és nem a megálló pontos nevét.A group-ban teljesen bizonytalan voltam, azt köszönöm hogy tisztáztad a fejemben.
Az indexelésekkel kezdem, majd a stop_times feldarabolása lesz következő lépés az optimalizálás terén, én is azt találtam jónak,ha stop_id alapján szedem széjjel.Még egyszer nagyon köszönöm! Ha bármilyen ötleted van még ,írd meg.
PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM
-
pittbaba
aktív tag
Szia!
Igen, pont ezzel kísérleteztem az elmúlt órában, hogy külön vettem a lekérdezéseket megnézem mi mennyi idő, de sajnos egy sima alap select is 10-30mp míg lefut a fájlban, nincs más választás.
Az indexel kapcsolatban sajnos nem értem a kérdésedet? Betöltöttem az adatokat? (Azok benne vannak már az indexelés előtt )
Hogy érted ezt?PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM
-
pittbaba
aktív tag
szerintem semmit sem gyorsított, valószínűleg ezért.. nem is értettem hogy működhet ilyen gyorsan az indexelés.. most már értem
tábla létrehozáskor kell indexelni és úgy nyomni a konvertálást. Akkor belepötyögöm a konverter appba, hogy indexeljen és lefekvés előtt elindítom, hátha gyorsabb lesz a db.Szerinted ha csinálok egy selectet where nélkül, összejoinolva a táblákat, majd a kimenetet feldolgozom úgy, hogy építek belőle egy újabb összegző táblát az nagyon gáz lesz, vagy az is egy lekérésnyi időt vesz majd igénybe? Nem tudom ez a része hogy működik.
PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM
-
pittbaba
aktív tag
Nem sokkal lőttél alá a teljesítménynek, nincs alám pakolva egy erőmű, és mivel a stop_times tábla 2,5 millió soros ( mint kiderült..
), még azt is megizzasztja. Helyi szerveren annyi előnyöm van, ha csinálok egy 10 perces lekérést, le tudom lőni az sql szervert, és nem kell várnom timeoutig minden alkalommal A szolgáltatóm phpmyadminja nem tud ilyet sajnos, én is ezt kerestem volna
Tudom, hogy csv-t is tud fogadni, viszont nem vágja hogy az első sorából táblát kéne csinálni, így gyorsabb az sql, mint megint kézzel megcsinálni a táblákat...PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM
-
pittbaba
aktív tag
Nem szükséges, csak kísérletezek ha már ..
Most egyelőre ott tartok, hogy négy lépésben egyszerűsítem a táblákat:
CREATE TABLE xy AS (SELECT col FROM a JOIN b .... )Minden szépnek és jónak tűnt, de valami mégsem jó, pl a Blahánál nem jár a 7-es busz az én adatbázisom szerint
Még át kell gondolom ezt kicsit...
PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM
-
martonx
veterán
de te nem is egy 600Mhz-s arm-os szörnyetegen futtattad a lekérdezést. Néha ledöbbenek, amikor egy ilyen kis procinak még egy komolyabb html weboldal renderelés is nehézséget okoz, akkor mire számítasz egy 2,5 millió soros, SD kártyán lévő adatbázis futtatásakor?
Én kérek elnézést!
-
pittbaba
aktív tag
Köszi mindenkinek az indexelés miatti nyaggatást, végig azt szúrtam el, tiszta lappal újra kezdtem, indexelve, végre tök gyorsan lefutnak a lekérdezések!
Kaptam a GTFS fórumon egy okosságot, arra a kérdésemre a választ, hogyan lehet kiszedni a GTFS formátumból azt, hogy egy megállón milyen járatok haladnak át (Az összes járat összes megállóját), megosztom veletek:
create table rstops as
select route_id, direction_id, a.stop_id, stop_name from
(select distinct route_id, direction_id, stop_id from stop_times as st, trips as t where st.trip_id=t.trip_id)
as a, stops as b where a.stop_id=b.stop_id order by 1,2;PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM
-
pittbaba
aktív tag
Az most fog eldőlni, majd reportolom. Egyébként ha nem is lesz gyorsabb, de legalább létre tudtam hozni egy jóval kisebb táblát, amiben benne vannak azok az adatok amik nekem kellenek. Az indexelés segített, hogy egyáltalán bármit tudjak kezdeni az adatbázissal 10-es limit nélkül
Kérdés:
Indexelésnél van e különbség, melyik a helyesebb:Új tábla hozzáadásánál KEY `stop_id` (`stop_id`),
vagy a tábla létrehozása után a CREATE INDEX trips_tripid_idx ON trips(stop_id) ?
PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM
-
bambano
titán
ezt az ötletet a Chomsky féle normálformákról és az adatbázis normalizálásról szóló vizsgán ne vezessétek elő, mert megbuktatnak
átfogalmazva: az ötlet rossz, nem denormalizálunk adatbázist.
a helyes megoldás, hogy felveszel egy kulcstáblát, és abba belerakod a szövegeket, azonosítóval.
amikor az adatbáziskezelés elveiről van szó, akkor a disk io nem számít szerintem.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
ha egy táblában van ötezer sor, aminek egy mezőjében 10 stringből található 1, akkor az denormalizált.
a string rendszerű tárolással meg az a baj, hogy könnyű elgépelni, mikor hivatkozol rá, esetleg van benne ékezet is, amitől fejreállnak a kliensek, meg hasonlók. persze mondhatod erre, hogy nem, de abból az lesz, hogy most nem, és később?
az egész sql bagázs arról szól, hogy a hatékonyságot feláldozzuk más erények érdekében. merthogy az sql masszívan nem hatékony akár a hálós adatbáziskezelőket nézed, akár a nosql-t, vagy ilyeneket.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Ispy
veterán
Semmiképp sem tárolnék fix értékeket szövegként, vagy csinálnék egy Aktiv mezőt, ami bit, vagy egy Statusz mezőt, ami kódot tartalmaz, amihez egy másik táblában van letárolva a kódok tartalma.
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
bambano
titán
ha csinálsz egy személyzeti nyilvántartást, a település nevét ott se rakod be karakteresen, hanem csinálsz hozzá egy szótár táblát és integer azonosítóval "linkeled".
pontosan ugyanezért denormalizálás, amiről beszélsz.azok után pedig, hogy azt állítottam, az sql-ben a teljesítményt feláldozzuk más célok elérése érdekében, ez a link mennyiben releváns?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
PazsitZ
addikt
és kódban egy enumhoz kötöm
Pont kérdezni akartam, kód szinten hogy kezeled az értéket.
Viszont akkor már magadnak sikerült ellentmodani.
mert ha nekem az adatbázisban kell kotorásznom, nem fogom fejben visszafejtegetnem, hogy melyik numerikus azonosító mit jelent <-> és kódban egy enumhoz kötömHa kódban enum, akkor hol miért kellene kotorászni, fejtegetni?
[ Szerkesztve ]
- http://pazsitz.hu -
-
Ispy
veterán
Tároljuk a település nevét szövegként a személy táblában, vagy egy numerikus kódot és joinoljuk egy településeket tartalmazó táblával mindig?
Igen, pontosan, erről szól a relációs adatbázis kezelés, ettől még persze nem muszáj így csinálnod, de megerősítésre itt ne várj.
(12 éve dolgozok SQL-lel, megírni egy joint, olyan mint levegőt venni, fel sem tűnik)
"könnyebb elírni": miért, a numerikus azonosítót nem könnyű elírni?
Ha van numerikus mezőm, nem kézzel kell megadni az értéket, hanem listából választani, így elírni nem lehet (max. rosszat választani).
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
#2086
fordfairlane
veterán
modder
#2083
fordfairlane
veterán
Tároljuk a település nevét szövegként a személy táblában, vagy egy numerikus kódot és joinoljuk egy településeket tartalmazó táblával mindig?
Ha a település neve egyedi, akkor a név lehet kulcsmező. Szövegként tárolni a települések közt, és idegen kulcsként is felhasználható egyidejűleg.
x gon' give it to ya
-
Ispy
veterán
1-2 eset, amikor szerintem hasznos a numerikus tárolás:
- megváltozhat a neve
- többnyelvűség szempont
- listából választás
- kapcsolódó információk tárolásaKódból meg ha kell ugyanúgy csinálok rá egy enumot és máris olvashatóvá tettem, szóval szerintem nem az a kérdés, hogy mi szól a stringként tárolás ellen, hanem szól-e egyáltalán valami mellette?
Visszatérve az alap kérdésre, kis adatbázisok esetében semmi jelentősége a szöveges vagy numerikus tárolásnak teljesítmény vagy méret szempontjából, de más szempontok miatt kell végiggondolni, hogy mit érdemes törzsbe kiszervezni és numerikus értékként tárolni a kulcsot (ami egyébként lehet autonumber is, szóval +1 érv a numerikus mellett).
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
bambano
titán
"Ez úgy hangzott, mintha az SQL használatával nagyságrendekkel rosszabb teljesítményt érnénk el": ez valószínűleg azért hangzott úgy, mert igaz, feltéve, hogy nem az eredeti szövegkörnyezetéből kiszakítva értelmezed a mondatot. az eredeti szövegkörnyezetben nem az volt az állítás, hogy egyik sql lekérdezés a másik sqlhez képest milyen, hanem az, hogy egy adott sql lekérdezés egy nem sql rendszerű, itt konkrétan hálós volt emlegetve, adatbáziskezelőhöz képest milyen. hát lassú.
Az eredeti mondat ez volt: "merthogy az sql masszívan nem hatékony akár a hálós adatbáziskezelőket nézed, " és igen, az sql rohadtul nem hatékony egy hálós adatbáziskezelőhöz képest, pláne, ha a lekérdezés olyan, amire a hálóst tervezték.
a személy meg a város kérdéskör meg akkor lesz érdekes, ha egy városból több személy van, pláne, ha nem egyszerre töltik be az adatokat, és akkor elkezdik a t. userek mindenféle néven illetni a településeket. ez még városoknál nem annyira nyilvánvaló, de én még nem láttam olyan adatbázist, ahol az utcaneveket képesek lettek volna egységesen írni. az meg, hogy ilyenkor nyakonvágjam a t. usert, kívánatos, de nem lehetséges megoldás
no mindegy, járod a magad útját, oszt jónapot.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
martonx
veterán
Mivel semmi konkrétumot nem írtál, nyilván én se tudtam mit írni azon kívül, hogy még a felvetés is hülyeség. No, de közben jött itt egy példa a településnevekkel.
Szerinted melyik megoldás a rövidebb? Egy 16 - 32 bit hosszú mezőben eltárolni egy numerikus adatot, vagy egy 50X16 bitnyi mezőben eltárolni egy szöveges adatot.
"- index sebessége: annyival lassabb egy pl. 30 karakter hosszú CHAR vagy VARCHAR mezőn az index használata?"
Jelzem, amikor erre a mezőre indexet húzol, az indexed is pont ilyen méret differenciákkal fog létrejönni.
Aztán nézzünk még egy érvet. A processzorok leggyorsabban számok feldolgozásával működnek. Persze-persze, minden mást is fel tudnak dolgozni, ami binárisan leírható, de akkor is minden CPU alapja a "számolás".
Számszerűsítve a dolgot, olyan több mint 50-szeres sebességkülönbség simán lehet a két megoldás között. Azt persze aláírom, hogy kis tábla méreteknél ez észrevehetetlen, de ha egy táblában van 2-3 ilyen szarul megoldott indexed, és a tábláid több százezer sorosak, netán valami gyenguc hoszting gépen vagy többtized magaddal ugyanazon az adatbázison, akkor ez máris másodperceket, akár perceket jelenthet.Egyébként amit felvetettél, abszolút nem eretnek gondolat. Tegyél fel egy MongoDb-t, vagy bármilyen NoSql-t, toljál a hoszting gépedbe pár 10 Gb memóriát, és máris bármilyen lehet az adatbázisod, és még csak lassú se lesz.
Én kérek elnézést!
-
PazsitZ
addikt
Nekem a problémám megint csak ott van, h ellentmodnást érzek.
Szóval mégis csak szükséged van egy másik táblára.
Ahol mondjuk település adatokat tárolsz. Ekkor viszont már minek a string?
String join amúgy is lassabb lesz feltehetőleg, persze biztos elmegy úgy is, de végül akkor amúgy is lesz szükséged join-ra.
Nagyon egyszerű tesztelésen kívül pedig nem látom még mindig a rációt a kézzel túkálok a táblában érv mellett. De ekkor is én nem kézzel turkálnék, hanem query-vel populálnék be minta adatot is talán.Egyébként a karakterkódolásra bár azt mondtad, nem lehet gond, én mégis idegenkedek ilyen-olyan spec. karaktereket használni (bár konkrét példa most nem jut eszembe), az int index az viszont biztos, h teljesen egyértelmű és hibamentes lesz.
A hatékonysági kérdésekkel csak akkor érdemes ilyen mélyen foglalkozni
Feljebb még te linkeltél performance eredményeket a sztring tárolás védelmében, akkor fontos volt. Ha valaki negatív performance eredményt említ akkor már nem fontos?U.i.:
Most téynelg nem kötözködni akarok, csak még mindig nem látom a hasznot. De persze ettől még nyugodtan tárolhhatod így, nincs ezzel gond, engem legalább is nem zavar.Nem zavar, amíg nem kell más ilyen DB-jét migrálnom. Sajnos kellett már, nem volt jó
[ Szerkesztve ]
- http://pazsitz.hu -
-
#2096
fordfairlane
veterán
modder
#2095
fordfairlane
veterán
Egyébként én először olyan információt akartam szövegként tárolni, ami tipikusan egy enum (SQL) típus lenne, és a mező "kardinalitása" olyan 10 db érték körül mozog. Enummal az a baj, hogy nem elég dinamikus, ha új értékre van szükségem az alkalmazásban, akkor módosítanom kell az elérhető enumok listáját, ami MySQLnél azt is eredményezheti, hogy újragenerálja az egész táblát. És az enumra lett volna alternatíva a numerikus vagy szöveges érték, ahol én arra szavaznék, hogy legyen csak szöveges pl.
Státusz = {"active", "inactive", "suspended", "deleted"} ahelyett, hogy 1,2,3,4-t tennénk a mezőbe. És szerintem ez tényleg nem nagy eretnekség.Már miért lenne eretnekség, sehol nincs előírva, hogy felsorolás mezőnek INT-nek kell lennie. Enum mehet a fix készletnek, CONSTRAIN-es kapcstábla a variábilis jellegűnek. Felindexelve egy varchar is gyors, és csak emiatt fölösleges egy plusz INT-re absztrakciót beemelni a táblaszerkezetbe.
[ Szerkesztve ]
x gon' give it to ya
-
martonx
veterán
- az egyik, amiből az egész kiindult, hogy ha a lekérdezéseket szerkesztem valamilyen kliens programban, akkor jobban esik az agyamnak, ha a konkrét információt látom a mezőben, ha ellenőrzöm, jó lekérdezést írtam-e meg. Ide tartozik még, ha valaki (vagy én) évek múlva hozzá akar nyúlni a szoftverhez és adatbázishoz, leegyszerűsödik a dolga.
Ez evidens, de ha ez így lenne, akkor mindjárt eljutunk oda is, hogy minek relációs adatbázist használni. Ennyi erővel eltárolod egy text file-ban az egészet, és nincs is miről beszélnünk.- a városos példánál maradva nincsen szükség joinra, ami egy kicsit le tudja egyszerűsíteni a lekérdezést, ha egyébként az nagyon összetett; sok másik jointot is tartalmaz.
Erre lennének valóak a view-k, tárolt eljárások.- ha szoftverben valamilyen ORM frameworkot használunk, közvetlenül benne lehet a város neve a személyek entitásban, ahelyett, hogy egy varos entitason keresztül kéne hozzáférnem az értékhez. (Elképzelhető, hogy egy-egy kapcsolatnál be lehet süllyeszteni a személy entitásba a várost, de most nem jut eszembe, hogy pl. JPA-nál lehet-e)
Hogy jön ide az ORM? Olyan view-t, vagy selectet, vagy tárolt eljárást írsz, amilyet akarsz, és az lesz benne, amit akarsz. Végül az ORM-et arra húzod rá, amire jólesik (legalábbis NHibernate, Entity Framework-ös tapasztalataim alapján).Szerintem maga a kérdés feltevés értelmetlen volt, hiszen ha ilyen bagatell a dolog a részedről, ilyen pici a projekt, ilyen minimális adattal, meg különben is ennyire értesz hozzá, akkor minek kérdezted meg? Úgy kókányolsz vele, ahogy akarsz. Ha viszont igényes munkára törekszel, akkor meg miért nem fogadod meg a tanácsokat?
Én kérek elnézést!
-
Ispy
veterán
Jaja, praktikus. Aztán majd mikor kiderül, hogy:
a) a státuszoknak meg is kell jelennie vizuálisan több nyelven is,
b) a státuszoknak ne adj isten előbb-utóbb folyamatokat is kell vezérelnie,
c) és még akár hierarchia is van közöttük,
d) ja és most még csak egy táblában van, de holnapután még 2-ben is használni kéne,akkor majd lehet szétszedni a remek kódok és megcsinálni rendesen.
Mondhatod, hogy neked ezek nem szempontok és áááá soha nem lesz ilyen és 1000 évig elleszel ezzel a 4 stringgel, de attól még szerintem nem ez a jó megoldás (és igen, nem lesz így sem lassabb, nem lesz így sem nagyobb az adatbázis, viszont neked jó lesz, mert kényelmes).
Egyébként meg ha már itt tartunk mégis mitől másabb egy szöveget látni, mint egy kódot, ha abból csak 4 darab van és soha nem is lesz több? Kb. 3x ránézel és már kód alapján is tudni fogod, hogy melyik mit jelent. Egyébként is manapság nagyon elkényelmesedett minden programozó, mert hát van sok terrabájt, meg gigabájt, meg sokmag és a hardware elfedi a nem hatékony programok hiányosságait, aztán amikor meg pár év múlva esetleg hirtelen megnő a program kihasználtsága, akkor az ilyen kis atombombák szépen elkezdenek felrobbanni.
Csak az idők során kezdek rájönni, hogy érdemesebb a legpraktikusabb megoldások felé menni
Volt jónéhány kollégám akik szintén ezt vallották, de sajnos mindig nekem kellett a végén visszalapátolni a lóba a sz@rt. Hidd csak el, ezeket a dolgokat nem azért találtak ki sok-sok éve, mert annyira rosszak lennének.
Peace!
"Debugging is like being the detective in a crime movie where you're also the murderer."
.
tábla létrehozáskor kell indexelni és úgy nyomni a konvertálást. Akkor belepötyögöm a konverter appba, hogy indexeljen és lefekvés előtt elindítom, hátha gyorsabb lesz a db.
Új hozzászólás Aktív témák
- Óra topik
- (nem csak) AMD FX / Ryzen tulajok OFF topikja
- Milyen egeret válasszak?
- Vodafone mobilszolgáltatások
- PlayStation 5
- Energiaital topic
- Python programozás
- LED világítás a lakásban
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- További aktív témák...
