ugrás a tartalomhoz

Program saját használatra

jeti · 2011. Szep. 8. (Cs), 23.02
Sziasztok!

Ti hogyan készítenétek el saját magatoknak egy adatbázist használó programot? (Például naptár programot.)
A.) „asztali programozással” pl.: C++
B.) „webszerver oldali programozással” pl.: PHP, MySQL
C.) „kliens oldali programozással” pl.: JavaScript, SQLite

1. Melyiknek mi az előnye és mi a hátránya?
2. Melyik a legmobilisebb, legtöbb helyen futtatható és melyiknél oldható meg a legkönnyebben a szinkronizálás? (C aztán, B végül A?)
3. Melyik a legbiztonságosabb? (Szigorú tűzfal mögül ~ nagyjából csak választ enged be. SQLite esetében pedig: a böngésző mappájában csak egy szimbolikus link lenne az SQLite fájlra.)
 
1

Probléma

Poetro · 2011. Szep. 8. (Cs), 23.33
Itt valami probléma van a kérdéssel. Az adatbázist rengeteg féleképpen fel lehet fogni, egy naptár például lehet egy darab szöveges fájl is. Vagy feloszthatjuk fastruktúrába, minden nap, amihez van bejegyzés, egy mappa, minden bejegyzés egy fájl. Az se világos, mit értesz azon, hogy hogyan. Gondolom úgy, hogy leülünk, megbeszéljük a követelményeket, felvázolunk egy tervet, elkészítünk egy designt és összedobjuk az alkalmazást. És ez pont így működik mindegyik változatra. A kliens oldali programozást nem értem. Mi a különbség az asztali és kliens oldali között?
1. Melyiknek mi az előnye és mi a hátránya?

Mindegyiknek rengeteg előnye és hátránya van. Ha leírod, melyik kérdésed mit jelent, akkor talán lehet rá válaszolni. Na meg, az is kérdéses, mit akarsz megoldani az alkalmazással.
2. Melyik a legmobilisebb

Nincs olyan, hogy legmobilisebb. Határozd meg a célplatformot, és akkor tudjuk, azon milyen lehetőségek vannak. Minden lehetőség operációs rendszer és eszköz képesség függő. Hiába írtál meg egy iszonyú jó Java alkalmazást, ha az csak grafikus környezetben fut, az eszköz, amin használni akarod pedig szöveges. Talán érdemes szöveges módú alkalmazást írni DOS környezetben, azt támogatja a legtöbb operációs rendszer valami emulációs környezetben. Talán még C64 kód is lehet, arra is van rengeteg emulátor. Minden attól függ mit akarsz csinálni, nincs olyan, hogy egy megoldás mindent visz.
melyiknél oldható meg a legkönnyebben a szinkronizálás?

A kérdésnek szintén nincsen értelme, minden környezetben megoldható a szinkronizálás hasonló bonyolultsággal.
3. Melyik a legbiztonságosabb?

Az, amelyiket a legbiztonságosabbra írod. A kérdésnek nincs ebben a formában értelme, mert nem tudjuk, mit akarsz megvalósítani. A legbiztonságosabb talán, egy C64-en futtatni, ami egy aggregátorról veszi az áramot és a Gobi sivatag közepén van elásva 20 km mélyre, egy 50 m falvastagságú betonacél-ólom borítású tömbben.
2

Pontosítás

jeti · 2011. Szep. 9. (P), 00.00
Pontosítok néhány dolgot. SQL-lel kezelhető adatbázisra gondoltam. (Más fajta fájl formátumot van értelme használni? Arra gondoltam, hogy az sql kezelő függvények megvannak írva és nem kell azzal foglalkoznom.)
A hogyan-t úgy értettem, hogy a A-C variációból melyik megközelítés a legjobb. (Például később se kelljen nagyon módosítani, hogy akár a jövőbeli Chrome OS-szerű rendszerekbe is át lehessen vinni. Vagy ez a szempont már a biztonság rovására megy?)
Asztali programozás alatt értem az asztali alkalmazásokat, pl. jegyzettömb, számológép. Klienset meg a böngészőre értem, akár úgy is, mint például az Opera widget motorja és a többi böngésző hasonló megoldása.
A célplatformnál Ubuntura, Windowsra és Androidra gondoltam. A cél hogy ezek között lehessen minél könnyebben adatot cserélni. (Az elég Androidnál, hogyha egyszerűen a memória kártyán lévő tároló fájt olvasom és írom.)
A 3. válaszod tetszett. :-) Itt arra gondoltam, hogy kívülről melyikhez a legnehezebb hozzáférni.
5

Saját vélemény

Poetro · 2011. Szep. 9. (P), 11.21
Én minden változatot JavaScript-tel oldanék meg, elvégre az a platformok nagy részén natívan futtatható. Ez alól talán a MacOS lehet az egyetlen kivétel, de mivel azt nem ismerem ebből a szempontból, ezért erre nem tudok válaszolni, lehet ott is lehet natívan futtatni JS-ben írt asztali alkalmazást. Szerver oldalon ugye jó régóta van JavaScript futtatási lehetőség, és a Node.js óta tényleg használják is, sőt gyorsabb mint a legtöbb szerver oldalon futtatható szkriptnyelv (pl. sokkal gyorsabb, mint Perl, PHP, Pyton). Windows alatt natív alkalmazásokat lehet benne írni .NET segítségével, akár grafikus felülettel is (mindennel amit a .NET tud). Android és iOS alatt pedig Appcelerator segítségével szintén natív alkalmazásokat lehet írni, amiket a motor iOS alatt Objective-C-re illetve Andoid alatt Java-ra fordít. A böngészőben pedig egyértelmű hogy JavaScript lesz e nyerő, mivel eleve nincs más.
Az SQL-hez pedig nem tudom miért ragaszkodsz, talán érdemes lenne megismerkedned a NoSQL rendszerekkel is. A biztonságnál pedig tényleg csak az a lényeg, hogy te mennyire biztonságos rendszert fejlesztesz.
7

Az SQL-hez pedig nem tudom

Hidvégi Gábor · 2011. Szep. 9. (P), 16.13
Az SQL-hez pedig nem tudom miért ragaszkodsz, talán érdemes lenne megismerkedned a NoSQL rendszerekkel is.
Melyiket és miért ajánlanád?
8

Feladatfüggő

Poetro · 2011. Szep. 9. (P), 16.44
Van, hogy egyáltalán nincs szükség adatbázisra, elég tényleg csak pár fájl, vagy például XML. Azokban is nagyszerűen lehet keresni, XML-hez pedig rengeteg beépített eszköz van, amivel ezt el lehet látni.

A másik dolog ami pl. a MySQL-lel és hasonlókkal, hogy alapból szolgáltatásként futnak, amik akkor is terhelik a gépet, amikor nincs is szükség rájuk. Elég lenne őket az alkalmazás futási idejére elindítani, majd az alkalmazás végén bezárni.

Olyan rendszerekre gondolok itt NoSQL alatt, mint például a Solr, és amire épül a Lucene. Kényelmesen tud indexelni adatokat, valamint nagyon hordozható, és gyors is. Nagy mennyiségű adat mellett is gyorsabb mint pl. egy MySQL ugyanakkor csak keresésre jó, az adatok tárolását és a Lucene / Solr rendszerbe küldését neked kell megoldani.

Teljesen más tészta a MongoDB vagy CouchDB, amik dokumentum alapúak, és a beállított indexek mentén tudnak keresni. A választás attól függ, mennyi gépen akarod futtatni, is a sebesség vagy a megbízhatóság a szempont.
A MongoDB például nagy mennyiségű adat mellett is nagyon gyors, főleg mivel nagyon jó a replikációs képessége (master-slave). Képes az adatbázisokat feldarabolni (sharding).
A CouchDB kicsit fejlettebb replikációs képességekkel rendelkezik (master-master), verziókezelni tudja a dokumentumokat, de valamivel lassabb.
A fentieknek az egyik fontos előnye, hogy JavaScript barát adatformátummal és lekérdezési rendszerrel dolgoznak, illetve a szerver oldalon abban programozhatók. Kovács Kristófnak van egy nagyszerű összehasonlítása, hogy mikor melyiket érdemes használni.

Ami hátrány tud lenni a legtöbb NoSQL rendszerben, hogy az adatokat gyakran denormalizálni kell, hogy megfelelően kereshetővé tehessük. Ezáltal nő a helyfoglalása az adatbázis adatoknak, ezért például mobilon használt alkalmazásoknál inkább ajánlott pl. SQLite-ot használni, ami kevés helyet foglal, valamint az adatbázismotor sem igényel jelentős memóriát és tárhelyet az adatok mellett.
9

A MongoDB honlapján régebben

Hidvégi Gábor · 2011. Szep. 9. (P), 17.01
A MongoDB honlapján régebben olvastam, hogy a lapozásoknál (pl. terméklista) gondja van a rendszernek, minél "távolabbi" egy adat, annál lassabban tudja lekérdezni, viszont erről most már nem találtam információt, javították?
A másik dolog ami pl. a MySQL-lel és hasonlókkal, hogy alapból szolgáltatásként futnak, amik akkor is terhelik a gépet, amikor nincs is szükség rájuk.
Csak a memóriát terhelik, ami egyrészt olcsó, valamint azzal az előnnyel jár, hogy így gyorstárazzák a legutoljára használt lekérdezések eredményeit. Én annak örülnék, ha pl. a PHP-t lehetne hasonlóan működtetni.
10

A MongoDB honlapján régebben

Poetro · 2011. Szep. 9. (P), 17.20
A MongoDB honlapján régebben olvastam, hogy a lapozásoknál (pl. terméklista) gondja van a rendszernek, minél "távolabbi" egy adat, annál lassabban tudja lekérdezni, viszont erről most már nem találtam információt, javították?

Én nem tudok ilyenről, pedig a mi adatbázisaink több mint 100Gb-osak és több százezer dokumentum van egy adatbázisban.

Csak a memóriát terhelik, ami egyrészt olcsó

A mobil eszközöknél általában a memória fix, ezért ott igenis ügyelni kell arra, hogy az alkalmazásunk és annak komponensei mennyi memóriát fogyasztanak. Asztali környezetben természetesen más a helyzet, bár ott is érdemes ügyelni a memória fogyasztásra.
11

Megtaláltam. Az

Hidvégi Gábor · 2011. Szep. 9. (P), 18.07
Megtaláltam.

Az adatbázisoknál meg csak a szerverekre gondoltam.
12

range

Poetro · 2011. Szep. 9. (P), 18.40
Érdemesebb range-et használni. És szerintem mi is azt használunk, és nem sokkal bonyolultabb kezelni őket, csak
query.skip((pageNumber - 1) * nPerPage).limit(nPerPage)
helyett
query.range((pageNumber - 1) * nPerPage, pageNumber * nPerPage)
Bár lehet, hogy tévedek, és más adatbázis van itt lekérdezve, nem Mongo.
14

Találtam egy érdekes cikket,

Hidvégi Gábor · 2011. Szep. 11. (V), 09.57
Találtam egy érdekes cikket, a Postrgre egyik volt vezető fejlesztője szerint nem az SQL, sem a NoSQL, hanem a NewSQL a jövő, rámutatva az előbbiek hibáira.
15

+1 buzzword

Arnold Layne · 2011. Szep. 11. (V), 14.29
+1 buzzword, már várom mennyire lesznek vele tele az álláshirdetések. mint anno az ajax lufi, meg most a html5.
16

Megnézve a VoltDB oldalt

Hidvégi Gábor · 2011. Szep. 11. (V), 14.51
Megnézve a VoltDB oldalt kiderül, hogy ez egy újabb relációs adatbáziskezelő, amiben többek között nagy hangsúlyt fektettek a skálázhatóságra. Mindenesetre az ürge nagyon bátor volt, hogy ezzel elment egy NoSQL konferenciára, le a kalappal előtte : )
3

Google Calendar APIs and Tools

Karvaly84 · 2011. Szep. 9. (P), 00.46
4

Fenntartva, hogy ez így

bb0072 · 2011. Szep. 9. (P), 11.12
Fenntartva, hogy ez így tényleg nem elég konkrét, a következőket mondanám:

Cross-platform akkor lesz, ha minden (vagy legalábbis a legtöbb) platformon létezik hozzá valamilyen értelmező (interpreter), ami az adott operációs rendszeren futtatja a kódodat. Egy php scriptet is futtathatsz asztali alkalmazásként, de a legjobb megoldás talán a java, mert az a legelterjedtebb, Window, Linux, OSX, mobil platformokon is működhet. Ekkor az adatbázisod valszeg azon a gépen lesz, ahol futtatod, és ettől nehezen tudod majd ténylegesen átvinni az egyik eszközről a másikra. (Át kell vinni az adatbázismotort és a teljes db dumpot.) De használhatsz valami hálózati erőforrást is adatbázisnak, akkor ezt kikerülöd.

Legjobb talán, ha webszervert működtetsz, mert http kliens létezik minden platformon (a nem grafikus platformokon is), az adatokat pedig egy helyen, a szerveren tudod tárolni. A szerver valószínűleg publikus elérésű, ezért ha a biztonság nagyon fontos, tedd htaccess mögé, szolgáltasd a 44447-es porton, illetve írd biztonságosra a kódot.
6

SQLite és társai

Poetro · 2011. Szep. 9. (P), 11.48
Ha valami SQLite, vagy hasonló adatbázismotort haszálsz, akor elegendô az adatbázis fájlt mozgatni, az mindent tárol, és (szinte) minden platformon van hozzá driver.

A Java pedig a mobil platformokon eleve rosszul támogatott, és ahol van, ott is csak egy meglehetôsen szûk eszközkészlettel.
13

Hogy férek hozzá a mobil fájlaihoz?

jeti · 2011. Szep. 10. (Szo), 00.06
Köszönöm az ötleteket. Valószínűleg javascript és PHP párosítása lesz. Előbbi lesz a program nyelve, utóbbi pedig a szinkronizálásért fog felelni. Adatbázisban SQLite-ban gondolkozom. Érdemes XML-ben próbálkozni? Milyen előnyei vannak?

Már korábban is próbáltam, de nem sikerült a mobilon lévő fájlokhoz hozzáférnem. A mobiltelefonom pendriveként csatlakozik a számítógépre. Ha beírom a csatolási pont címét a böngészőbe, akkor látom a tartalmát, de ugyanezt PHP-ből már nem tudom megnyitni. A mappa jogosultsága rwx a tulajnak, a többieknek nincsen semmilyen joga. Ha MC-ben a haladó chown-al átállítom (777), akkor sem változik semmi, még a mappa jogosultság sem.
Az etc/fstab-ban nincs megemlítve ez az usb-s csatlakozási pont.
A php melyik felhasználói névvel fut? A print(exec('whoami',$kimenet)); print_r($kimenet); parancsokra csak egy üres tömböt kapok.
Mi lehet a hiba? Hogy tudok hozzáférni a fájlokhoz?

(Ubuntut használok.)