Adatbázis: SQL, XML DB

Letezik-e ilyen framework/lib Web+Android+iOS-re?

Aki elolvasva a cimet rogton linkelne a phonegapet vagy az iceniumot (esetleg a flexet), azt megkernem hogy elobb olvasson tovabb, es csak akkor linkelje, ha az altala emlitett technologia biztosan tudja ezeket.

Eloszor is: kozepes szinten ertek webfejleszteshez, Android alkalmazasok fejlesztesehez es iOS alkalmazasok fejlesztesehez is. A hetekben ismerosoktol tobb olyan mindharmat erinto otletet kaptam, aminek ugy kezdenek neki, hogy az altalam kerdezett db frameworkot megkeresnem ha letezik, es megirnam ha nem letezik (annak tudataban is, hogy nemely otletrol (nem mindrol) nehezen tudom elkepzelni, hogy valaha tul fogja lepni a bevetele az uzemeltetes kolsegeit (tipikus IT startup betegseg, de ez most mindegy)).

Tehat adott a kovetelmeny:
-van egy kozponti DB, webes feluletrol nyilvan az egeszet el szeretnek erni, mar csak egy csak webrol elerheto admin felulet miatt is. Ez a FULL DB
-adottak a mobilalkalmazasok iOS es Android alapokon. Mindkettonel teljesen mas jellegu DB megoldast szoktak hasznalni. Az Androidnak sajat (szerintem kifejezetten jol hasznalhato es baratsagos) SQLite konyvtara van, iOS-nel pedig valaszthatsz a C SQLite library es az Objective-C/Cocoa Touch-os xcode altal is tamogatott CoreData megoldasa kozt (nyilvan ez utobbit konnyebb hasznalni minden szempontbol, de az elozo is tulelheto)
-Mig egy admin feluletet is ellato weboldal siman elbir egy tobbmillio rekordos db-vel, addig egy iOS-t vagy egy Androidot futtato eszkozon ennel tobb okbol is joval kevesebb rekordot erdemes tarolni. Van pl. 1'000'000 user, abbol 1 user adatahoz ferhetunk csak hozza eleve a webappbol, akkor csak ahhoz a userhez kapcsolodo adatokat szeretnek a kozponti db-bol lefetchelni.
--Ugyanakkor illik egy mobilappot ugy megirni, hogy offline is mukodjon, ergo ha nincs se tererod, se mobilneted, se wifid (iOS-en ezt tudod ellenorizni a Reachability class-szal pl.), akkor is tudjal abbol a db-bol olvasni es abba a DB-be (akar kesleltetetten) irni.

Kovetkezmeny:
1. Alapeset: le akarunk kerdezni minden adatot, ahol a userunk aki epp be van lepve a FOREIGN KEY a tobbi adathoz, ezeket letoltjuk a mobilapphoz tartozo PARTIAL DB-jebe
2. Azoknak a tovabbi FOREIGN KEY-eihez tartozo adatokat is le akarjuk kerdezni a FULL DB-BOL a PARTIAL DB-be
3. Rajovunk, hogy ez igy nem eleg, van par statikus adattabla amit midenkeppen le akarunk kerdezni egeszben a FULL DB-bol a PARTIAL DB-be (pl. egy user jogosultsagokat vagy kategoria ID-kat tartalmazo altalaban kismeretu tabla), mert anelkul nem mukodik transzparensen az app offline (ezt mondjuk be tudjuk allitani egy config file-ban vagy egy include-ban)
4. Ha mar van configunk/include-unk, a FOREIGN KEY-ekkel meg nem jelolheto (pl. mas db-ben levo, vagy egy tablaban egyszerre ket oszlopban is elofordulo (pl. contact1: x user es contact2: y user es az is kell ahol a userunk x es az is ahol a userunk y)) adatokat is jo ha le tudjuk menteni, erre jo ha kulon meg tudunk adni szabalyokat, hogy "ezzel azt is fetch-eld le mindig a FULL DB-bol a PARTIAL DB-be"
+Idonkent valtoztatunk a tablakon (ALTER TABLE ADD COLUMN), ez ha pl. a szerveren (FULL DB, amit a webapp hasznal) megtortenik, akkor arrol valahogy (pl. verzioszam valtoztatasaval) szerezzen tudomast a szinkronizalasi kiserletnel az iOS/Android app (PARTIAL DB) is, mielott barmi tortenne, es modositsa a sajat semait ennek megfeleloen.

Kivant vegeredmeny:
-ugyanugy tudjuk megirni az SQL query-ket az iOS appban, az Android app-ban, es a webappban, de az iOS es az Android appban csak az a szelete legyen bent az adatbazisnak, amelyik az adott user interakcioihoz kell (ami nyilvan joval kevesebb rekordot takar).
-mindehhez a programozonak eleg legyen a configolason kivul es az "import fuggvenykonyvtar"-on kivul egy fuggvenykonyvtar.syncdb(userid)/[fuggvenykonyvtar syncdb forUser: userid] utasitast kiadnia
-primary key-ekben legyen mindig a webes appdb-nek igaza (pl. ott kezdodhet 10001-tol a primary key, a 10000 alattiak meg local recordok, es a webserver mogott futo db azoknak szinkronizalaskor ad egy globalis primary keyt amit a mobilapp letezo kapcsolat eseten magatol befrissit erre az egyetlen sync parancsra, ha a mobilapp 10001-edik local rekordot akar kesziteni, akkor meg Android/Java eseten ugye dobjon kivetelt, iOS/Objective-C/Cocoa Touch eseten meg returnoljon false-t/NSNull-t/Egyeb NSObject-et, es majd a programozo lekezeli, hogy hogy kene kozolni a userrel, hogy mostmar illene internetre csatlakozni).
-Amikor letrehozunk egy adatbazis semat, legyen egy egyszeru user tabla semank aminek dedikalt helye van a configban (az alapjan donti el a "sync" parancs, hogy milyen db szeletet ker le), es azon kivul amikor a tobbi CREATE TABLE/ALTER TABLE utasitast megirjuk, az jojjon letre transzparensen ugyanugy a webapp PostgreSQL/MySQL/Oracle db-jeben (PDO?), es ugyanugy az Android SQLite libjeben, es ugyanugy az iOS C-szintu SQLite db-jeben es/vagy a Cocoa Touch CoreData megoldasaban. Tehat ehhez is legyen eleg a config fajlba beirni a db szerver adatait, es a mar emlitett fuggvenykonyvtar.syncdb(userid)/[fuggvenykonyvtar syncdb forUser: userid] legyen eleg arra, hogy letrehozza/verziovaltozas eseten editalja a db-t semastol.
-emiatt lehetseges egy overhead: modification_date oszlop kotelezoen hozzaadodik pl. minden tablakhoz es/vagy edits/deletions tabla letre kell hogy hozodjon a szinkronizalas idoinek menedzslesere, stb.
-commit mindket helyen nyilvan akkor tortenik, ha a sync parancs vegen is van egymassal connection es ACK, kulonben rollback

[Felmerulhet a kerdes sokakban, hogy mi tortenik, ha nem csak egy user adatai kellenek, hanem egy usergroupe-e: lekerdezed a FOREIGN KEY-es modszerrel a group-ot es annak a tobbi rekordjat, es meg is jon resultkent a tobbi user, azoknak is besynceled az adatait userkey alapjan (vagy beallitod a configban, hogy GROUP ID-ra is menjen olyankor vegig)]

Kerdesek:
-Van ilyen fuggvenykonyvtar/framework? Az Icenium/Phonegap tudja ezt/ezeket/hasonlot ami _konnyen_ ezze alakithato? Bar az igazat megvallva azok tudtommal UI frameworkok (is), jobban orulnek, ha valami egyedul ezt a DB sync-es dolgot tudna (a la UNIX: "do one thing and do it well"), a maximum amit meg talan szivesen vennek az a DB sorobjektumainak az adott nyelv osztalypeldanyava valo konvertalasa (amit szerintem konnyebben fogok talalni joval, mint ilyen libet/frameworkot), de ez mar opcionalis, kevesbe lenyeges szempont.
-Amennyiben nincs ilyen, mennyire volna szerintetek igeny egy ilyen/ilyesmi libre? Lehet nekiesnek valami hasonlonak, ha az egyik-masik startup tervvel megis meggyoznek az ismerosok, hogy igenis eletkepes (mint irtam, mindnek igy esnek neki kozuluk, hogy ezt elobb megoldanam). :)

[megoldva] Vizualizátor paraméterezés

A legjobb ingyenes (webes kimenetet is adó) adatbázis-vizualizátort a schemaSpy személyében ismerem. Paraméterezéssel lehet e programban színeket változtatni az idegen kulcsokat összekötő vonalakon? Itt az látszik, hogy ez már másnak is volt eszében. S a kérés végén ott visszajelez az egyik fejlesztő, hogy valami XML-beli megadással ez lehetséges is (lenne). De ezt hol kell megtenni, milyen fájlban? Írtam a fejlesztőnek, de nem válaszolt. A forráskód is elérhető. Ötlet?

Az is szóba jöhet, hogy belenyúljunk a programba. A dot program az egde kulcsszóval jelöli az éleket (vagyis az adatbázis ábráján az idegen kulcsok vonalait), s ez a net/sourceforge/schemaspy/view/DotFormatter.java-ban kerül elő.
Próbáltam egy effélét:

dot.writeln(" edge [");
if (colorMe) {
dot.writeln(" color=\"#111122\"");
dot.writeln(" style=\"bold\"");
}
dot.writeln(" arrowsize=\"0.8\"");
dot.writeln(" ];"

Ezt a colorMe változót (amit felvettem új paraméterként a 229. sorban: private void writeHeader(String diagramName, boolean showLabel, LineWriter dot, boolean colorMe) szeretném valahogy paraméterezhetően változtatni. Magyarán, pl. hogy a valami_id idegen kulcsként való előkerülése esetén történjen meg a színezés.

(Ha elhagyom ezt a colorMe feltételt, akkor minden élt megvastagít (és pirosít) a program; ebből azt látom, hogy jó helyen keresgélek.)
Senki többet?
Ne tolongjatok!!

===

Végül egy kerülő megoldást találtam: a program diagrams alkönyvtárában vannak a .dot fájlok, amiből a diagramok képei készülnek. Itt egyszerűen átírhatóak az összekötő vonalaknak megfelelő kódrészletek:


"valami_lista":"kutya1_id":w -> "kutya1":"id.type":e [arrowhead=none dir=back color=red arrowtail=crowodot];
"valami_lista":"valami_id":w -> "valami":"elipses":e [arrowhead=none dir=back arrowtail=crowodot];

A pirosítás elérhető egy ilyen paranccsal a schemaSpy/diagrams/summary könyvtárból (megfelelően módosítva a tabla és id szavakat):
perl -pi -w -e 's/("tabla":"id".*)( arrowtail)/$1 color=red $2/' *.dot

S ezután ráeresztve egy "dot -Tpng bemenetifajl.dot -o kimenetifajl.png" utasítást, el is készül a kívánt .png fájl...

MS Access alapú program hiba?

Sziasztok!

Van egy .mde kiterjesztésű MS Access alapú programom. Mely bizonyos tételehez árakat tárol és számol. Ennek az adatbázisát .dbh kiterjesztésű fájlokkal tudom feltölteni.
Eurós árakkal töltjük fel és az árfolyamot megadva, ő átszámítja forintra.
A baj csk az, hogy ha olyan árat talál a táblázatban aminek a tizedes pont után 2 nullát tartalmaz pl:290.00 akkor itt eltolja a tizedes pontot balra kettővel azaz 2.90 el fogja a váltó számot beszorozni. Csak az ilyen alakú áraknál számol így ha 291.5 az ár akkor azzal jó számol importálásnál.

Találkozott valaki ilyen hibával? Tud rá valaki esetleg megoldást, vagy valamilyen Access alapbeállítást változtatást pl: numerikus beviteli mezők hossza?

Előre is köszönöm a segítségeteket.
ÜdV

PostgreSQL visszaállÍtása

Sziasztok,

a következő a problémám: Van egy program, ami PostgreSQL-t használ adatok tárolására. Windows 7-en futott, PostgreSQL 9.2. Egy ismerősöm újra akarta rakni a windowst, ezért lemásolta a postgreSQL data könyvtárát backup-nak, majd újratelepítette a windows-t meg a PostgreSQL-t. Rámásolta a lementett data könyvtárat az új install-ra. A probléma az, hogy most az új windows-on a PostgreSQL látja, hogy ott van az adatbázis, de nem látja a táblákat :)

Mint utóbb kiderült, úgy mentette le a data könyvtárat, hogy nem állította le a PostgreSQL server-t :) Van arra valami mód, hogy vissza tudjuk állítani az adatokat? Magának az adatnak ott kell lennie, mert kb 32 Gb foglal :)

Előre is köszi.

phpmyadmin: root belépés letiltása.

le szeretném tiltani a phpmyadmin-ba a root belépést, és bár rengeteg oldalt végignéztem ezügyben, nem akar engedelmeskedni a makacska.

amit olvastam, és meg is tettem:

A leírások jelentős része azt írta, hogy a /etc/phpmyadmin/config.inc.php fájlban fűzzek néhány plusz sort, mégpedig:

$cfg['Servers'][$i]['auth_type'] = ‘cookie’; (pontosabban ez már benne van, csak ki volt ütve //)
$cfg['Servers'][$i]['AllowRoot'] = FALSE;

Ezeket elvégezve semmi nem történik.

Ti ezt hogy oldjátok meg, valami tapasztalat? Köszönöm!

[megoldva] Egyoszlopos tábla helyett mit

Postgres adatbázisra készítettem egy sémaelemzést, és azt adta a SchemaSpy, hogy anomáliának számít az egyetlen oszlopot tartalmazó tábla. Mi szokott lenni a bevett gyakorlat az értékkészlet-listák (pg) adatbázisbeli ábrázolására? A SEQUENCE-szel leginkább csak számokat szokás kezelni, ha jól tudom.

Megtaláltam: CREATE TYPE mood AS ENUM ('sad', 'ok', 'happy');

mysql master slave replikacio

Sziasztok,

Valami trivialis dolgon elakadtam es nem jovok ra min.

Szal debian 7 , rajta Ver 14.14 Distrib 5.5.31 mysql server. S ezt allitanam be a mysql replikacio slave serverenek, valahogy igy:

mysql>
CHANGE MASTER TO
MASTER_HOST=’10.10.1.2′,
MASTER-PORT=3306,
MASTER-USER=’repl’,
MASTER-PASSWORD=’123456’;

erre ezt mondja:
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '’10.10.1.12′, MASTER-PORT=3306, MASTER-USER=’repl’, MASTER-PASSWORD=' at line 1

Nezem a mysql honlapjat es ezt irjak, igy kell felparameterezni, de nem.
Mit nezek el ?
Segitsetek legyszi !

Koszi
Sztupi

Postgresql

Sziasztok

Nem tudom mi lehet a probléma, van két vasam

server 1:

Intel(R) Xeon(R) CPU E3-1240 V2 @ 3.40GHz
Ram: 16GB
RAID SSD OCZ VERTEX
OS: Ubuntu 12.04

Server 2:
Intel(R) Xeon(R) CPU E3-1240 V2 @ 3.40GHz
Ram: 32GB
RAID SSD SAMSUNG 840 EVO
OS: Ubuntu 12.04

Server 1 en postgresql 9.1 adatbázis fut ahol egy lekérdezés 1,8 másodpercig tart egy táblában amiben 70 ezer sor van.

Server 2 ön postgresql 9.3 adatbázis fut ahol egy lekérdezés 25 másodpercig tart egy táblában amiben 70 ezer sor van,

A config egy az egyben ugyan az annyi különbséggel hogy a work_memet , shared_bufferset kicsit feljebb emelte, a több memória miatt.

Olvastam hogy analízáljam az adatbázist, megtettem, de szintén zenéz.
Köszönöm a véleményeket.

Access

Sziasztok!

Érettségi - estire járok. Segítség kellene Access adatbázis lekérdezésben. Sajnos nem vagyok jártas a területen. Eddig sikerült létrehoznom két táblát. Elsődleges kulcsokat definiálni, egy "egy a többhöz" kapcsolatot létrehozni. A lekérdezés létrehozásánál már bajban vagyok, mert nem nagyon megy.
Tud valaki valamilyen oldalt ajánlani, ahol egyszerű lekérdezések menete le van írva?
Szombaton kell egy beadandót beadni, ehhez kérném a segítségetek.

opensuse 13.1 postgresql 9.2, 10 szeresére nőtt lekérdezési idő.

Van egy pár nem túl szép lekérdezésem. Ezek eddig Ubuntu és Debian alatt nem okoztak észrevehető problémát.
Tesztelgetem az openSUSE 13.1 -t és csodálkozom, hogy a szoftverem ami eddig gördülékenyen futott, most néha tétlenkedik. Már tegnap az adatbázis importjánál észrevettem, hogy ez eddig nem így futott, de itt van pár mérés :
Ubuntu 13.10 ext4: 68.802 ms openSUSE 13.1 btrfs: 867.052 ms
Többször is mértem több lekérdezéssel ciklusban is, minden mérésnél 10 szeres minimum az időkülönbség.

Merre induljak ? Lehetséges, hogy a fájlrendszer miatt van vagy a pg configokat bújjam?

update1:
nem a filerendszer okozza.

update2:
OpenSuse -re feltettem virtualboxba egy debian7 -et és postgresql9.1 -et. Szintén jól teljesít. Úgy gondolom, nem a lekérdezéseimmel van a baj, ha még virtuális gépen is 10X gyorsabb mint a host rendszerrel szállított pg 9.2. -n.

Egyenlőre a témát lezártnak tekintem. Nem jöttem rá mi a baj a suse -vel szállított postgresql verziónak, de nincs rá több időm. Bugreportot nem küldök, mert angolul úgysem tudnám leírni a problémát és nem is vagyok benne biztos, hogy ez bug. Majd kiderül ha debian -hoz is lesz 9.2-es verzió.