Melyik programozási nyelvvel lehetne ezt a programot megcsinálni (legegyszerűbben)?

#19

"Nem mindent, csak egyet"

Meg amiről még menet közben kiderül hogy "jó lett volna". Pl a szó töredékre keresés. Oké, nem egy nagy művészet akár egy sima reguláris kifejezéssel végigszaladni az elemeken, de miért írjunk meg valamit ami már létezik és egész hatékony? -> "LIKE = '%alma%'"

Ha a NoSQL-ből a kulcs-érték adatbázisra gondoltál (mert ugye sokféle van) akkor arra azt mondom: talán! (Bár eddig én csak cache-re használtam ezeket és bevallom, nincs tapasztalatom benne, hogy érték alapján lehet-e kulcsot és ha igen milyen hatékonysággal keresni, mert elsősorban kulcs alapján szoktunk értéket, fordítva még nem próbáltam soha.)

Továbbra is RDBMS-t javaslok.

1) Hol van az kőbe vésve, hogy egy szónak biztosan csak egy jelentése lehet? De oké, a fenti példa alapján tételezzük fel, hogy csak 1:1 összerendelés megengedett. Ha nem, akkor gyakorlatilag definiáltuk a relációs adatbázis fő felhasználási módját.

2) Oda-vissza kell tudni keresni: tehát mindkét elem kulcs is és érték is. <- itt picit elbizonytalanodok a NoSQL-t illetően (de mint mondtam erről majd nyilatkozik az aki kompetensebb a témában)

3) Szótöredékre is tudnia kell keresni.

4) "ha netán elgépeli...adna (pár) lehetőséget" erre többféle megoldás létezik, pl: [link] (nekem mikor erre volt szükségem, akkor levenshtein távolságot használtam. van ettől jobb megoldás is, de ez volt a legegyszerűbb és kellően hatékonynak tűnt)

5) "Weboldalba szeretném beépíteni" Ha nem dockerezel vagy VPS és azt nézzük mihez találsz könnyebben szolgáltatót, akkor MySQL. (NoSQL-t nem sok helyen támogatják.. CouchDB vagy MongoDB tárhelyet itthon nehéz találni, de pl nekem Redis kellett volna és lasszóval se tudtam fogni erre szolgáltatót. Tudom. Ha ilyen "extra" igényeim vannak, használjak VPS-t.)

szóval összességében (bár ezek egy része valószínűleg NoSQL-el is simán megvalósítható lehet) de szerintem pro-kontra inkább valami RDBMS szerencsésebb lenne a fenti okokat figyelembe véve.

Végül pedig:

"Sorry, de éppen te vagy az, aki kontárkodik."

Nem. Te azt mondod ne lőjünk ágyúval verébre, közben észre sem veszed, hogy beigazolódott a feltevésem (#16) hogy nem veréb az hanem minimum egy vaddisznó és a megoldás amit javasoltam az sem egy ágyú (pl nem rögtön egy PostgreSQL-t javasoltam, pedig ott van pár beépített függvény ha nem csak pontos találatot szeretnénk megjeleníteni: [link] tehát az új információk ismeretében még ez sem lenne eltúlzott akár, továbbfejlesztés szempontjából több a lehetőség)

Ellenben egy sima sqlite-ot javasoltam kezdésnek, mert biztos voltam benne hogy a "csak egy apróságot szeretnék" az a végére nem apróság lesz, mindig jönnek új ötletek és nincs "kész" program, amit ne lehetne továbbfejleszteni, így a megoldásod nagyon hamar újraírásra szorulna. Ráadásul mennyivel egyszerűbb egy csv-vel, index építéssel és egyebekkel bohóckodni, mint valami kész megoldást használni, amit kb erre találtak ki? Bonyolultság szempontjából semmivel sem könnyebb/gyorsabb elkészíteni, sőt, és mindezt miért? Mert bizonyos adatmennyiség alatt gyorsabb lenne pár miliszekundummal és talán picivel kevesebb memóriát használna? És ez is csak addig igaz, míg az eredeti feladatnál maradunk és nem is akarjuk SOHA továbbfejleszteni...

szerk(#21):

*like után nyilván nem kell = jel. elgépeltem, csak nem tudom utólag javítani.*

(Mielőtt valaki szőrszálat hasítana.. :))

Jószerivel több időbe került a szótár file-t összeállítani mint a programot megírni.

Plain txt /csv/ file az adatbázis, nincs index, és szándékosan nem írtam meg a prediktív szövegbevitelt sem, hogy lehessen időt mérni.

[link]

#de most őszintén. ezzel mit szerettél volna bizonyítani?

- hogy meglehet írni rdbms nélkül is?

nyilván. mindent meglehet.

- hogy gyorsabb mint az adatbáziskezelő meghívása?

egy 16 elemű tömbről van szó :D lehet gyorsabb (de ki fogom próbálni csak a te kedvedért). viszont nézzük a valóságos példát. ez a 16 elem 8 egyedi indexhez tartozik, tehát gyakorlatilag 8 szónak a fordítása. jelenleg az angol nyelvben pedig ~1 millió különböző szó létezik. magyarban több. természetesen extrém példa, hiszen nem fog mindenhez egyedi fordítás készülni, de azért realisztikusabb lett volna mondjuk egy 700.000 szó esetén (ha a példádat alapul véve) olyan 1.4 millió elemű tömb. <-nyilván most nem azt várom el, hogy generálj akkor egy ilyen adatbázist, csak próbálok rávilágítani a logikai hibára

egész egyszerűen nekem olyan, mintha megpróbálnád bebizonyítani, hogy sikerült egy gyorsabb és hatékonyabb kódot írnod, mint pl a mysql. pár elem esetén amúgy igaz is lehet. (nyilván erre még indexet sem épít senki.) de ha nagy mennyiségű adatnál is igaz, akkor sürgősen jelezd az oracle-nek, hogy dobják ki az elmúlt 25 év munkáját :)

-egyszerű volt a programot megírni?

elhiszem. de egy db kapcsolat felépítése is csak egy sor a legtöbb nyelvben

viszont nézzük meg a te példádat, a mintaadatokkal, hogyan is néz ki egy mysql-ben, ráadásul (amúgy pl C-hez képest lomha) php-t futtatva, mivel eredetileg amúgy webre kellene neki (nem tudom milyen nyelven írtad amúgy, csak feltételezem, hogy nem szkriptnyelv)

[link]

természetesen a futásidőbe a kapcsolat felépítését is belemértem.

de amúgy most tényleg milliszekundumokon rugózunk? :D

Nem. Azt bizonyítottam, hogy hülyeségeket beszélsz. Egy ilyen kis programot sem érdemes mindjárt dependencyvel terhelni. Pláne ha a világon semmi szükség nincs rá, előnye meg nincs semmi.

Az a "16 elemű tömb" egyébként egész pontosan 370 ezer és készázhatvan (370260) elemet számlál.