Végülis iroda szekcióba tettem, mert ehhez áll a legközelebb. Van nekünk egy kb. 800-1000 rekordot számláló kotta nyilvántartásunk. Igen egyszerű: szerző, cím, raktári jelzet, megjegyzés. Három tábla van az adatbázisban (szimfonikus,szalon,kamara), lehet lesz még egy partitúra is, de ez nem is fontos. Szeretnék valami jópofa szép felületet, ahol kereshetnék, szűréssel, vagy felvihetnék új rekordokat is. Szóval alap dolgok. Adott lenne a az Access, de azt valahogy mindig rühelltem. Lehetne egy sql exporttal meg némi php gányolással webes alapokon csinálni, de ahhoz ugye kéne helyi webszerver (*ampp). Ez sem szimpatikus. Tudtok-e esetleg valamilyen más megoldást, esetleg kész nyílt forrású projektet, amibe szabadon belenyúlhatok és kis gányolással személyre szabhatom? Win alapokon megy az irodai gép, de ha keresztplatformos/webes attól sem zárkózom el. Vagy teljesen más ötleteket is szívesen fogadok. a lényeg, hogy egyszerűen tudjam testre szabni.
Válaszaitokat előre is köszönöm.
Fórumok
Hozzászólások
Flex-szel (http://flex.apache.org) pillanatok alatt össze lehet dobni egy egész jól kinéző, jól használható felületet, alatta meg SQLite dübörög. Az eredmény egy desktop application.
"Lehetne egy sql exporttal meg némi php gányolással webes alapokon csinálni, de ahhoz ugye kéne helyi webszerver (*ampp)."
Ne fázzál tőle, 1000 rekodot kezelő LAN-os szervernek pont jó a 13.000 Ft-os Raspberry is + egy SD kártya bele. :) A Raspbian disztribúcióban pedig minden benne van, ami neked kell.
Tehát nem kell húdeszerverben gondolkoznod. Természetesen a saját gépedre időről időre backupolva az adatokat.
És mégis kényelmesen elérik a kottát webes felületen az irodából a zenész lelkek ezen a kisforgalmú, 3 wattot fogyasztó éjjel-nappal járó szerverecskén.
Már régóta tervezem beszerezni. Igaz otthonra fájl/média-szervernek. De adtál egy remek ötletet. Hisz úgyis van alapból "céges" tárhelyünk. Egy aldomainon elhelyezhetnék akár egy kisebb CMS-t is, amit erre hegyeznék ki. Tudtok esetleg ilyet?
Hát az rpi nem épp CMS futtatására való.
Oracle XE + Apex
Ezt szokás mostanában javasolni Access helyett, ingyenes alternatívának.
Össze lehet kattogtatni a felületet az adatbázisra. (Azért annyira nem egyszerű, de könnyen tanulható)
Bár ehhez is kell szerver, de ha csak irodán belül kell, akkor felrakható az irodai gépre.
Szerverrel azt hiszem, nem az az elsődleges gond, hogy irodai gép vagy önálló szerver. Sokkal inkább (szerintem), hogy amíg valaki használja az alkalmazást, annak a gépnek mennie kell.
Az irodai desktopokra meg normális helyen az a jellemző, ha munkaidőn túl nincsenek bekapcsolva.
Igen pontosan így van. Bár offline mehetne. Végül is nem feltétlen fontos az online elérhetőség.
Tudom web, meg php de én ezt egy MVC-ben dobnám össze, mondjuk PostgreSQL-el.
----------------------------
Előnevelt csirke kapható!
Nem álltam le az agyalással és végül arra jutottam, hogy az általam legjobban ismert nyelvekben a legegyszerűbb megírni. Vagyis html5, css3, js kombóval. Adatbázis, pedig mivel roppant egyszerű és nem kell szerver xml-ben dobnám össze. Az Excellnek talán van is direkt xml export funkciója.
Van számos keretrendszer hozzájuk, nagyon szimpatikus pl a wakanda. Van esetleg más framework ötlete valakinek?
Azt azért számold hozzá, hogy az XML alapú lekérdezések bizonyos rekord szám után már lassabbak lesznek.
Nem véletlenül találták ki SQL esetén is az indexeket.
Bár 1000 sornál talán még nem lesz ez akkora probléma.
Egyébként Libre Office adatbázis kezelője nem játszott egyáltalán (tapasztalatom nincs benne, de ha az MS-től fázol csak, akkor ez talán alternatíva lehetett volna)?
Szerintem max ezer sor lesz a vége. Majd tesztelem a sebességet. Őszintén szólva nem ismerem az LO adatbázis kezelőjét, de egy próbát megér. Ugye nem VisualBasic-et használ?
Nem valószínű :)
Nem feltétlenül lesz lassabb, nagytömegű vagy komplex adatok esetén pont, hogy gyorsabb lesz: http://nativexmldatabase.com/2010/08/22/xml-versus-relational-database-… Ez persze itt nem valószínű, hogy előjön, mert nincs annyi adat jelenleg. :) Mi is inkább hibrid megoldásokat alkalmazunk.