Re: Database for EAV model
[email protected] Tue, 9 Sep 2008 05:40:55 PDT
| Newsgroups | gmane.comp.java.sun.kvm |
|---|---|
| Message-ID | <28220823.83391220964086506.JavaMail.tomcat@sdcst12.sjc.collab.net> |
Thanks again for your reply and for the comments. :)
Please bear again to the long reply=E2=80=A6.
{the story behind the project (: )
Actually, the project is based from an open source code, so, probably (and =
hopefully), if our group (we are 3 college students) will finished it, it w=
ould be integrated into the original one:
http://code.google.com/p/chits-ph/
The current project is a LAMP-based running on an intranet set-up in a rura=
l health center:
[b]
desktop/workstation(health center)--------------{intranet}-------------->se=
rver(health center)[/b]
However, many of the data/information comes from the remote area (far away =
from the center) and rural health workers who collect the data just jot dow=
n it temporarily on a paper and latter encode it into the workstations(work=
ers visit the center at least once a week). This method is obviously errone=
ous and irksome.
So our task is to provide a mobile interface of the application.
And as you have suggested, the most efficient/easiest way is by connecting =
the mobile phone to the server via wireless HTTP protocol.
So the model 1 is supposed to look like this:
[b]workstations(center)< ----------{intranet}---------->server(center) <---=
-------{WAP}---------->phone(remote area)[/b]
But the =E2=80=9Cgreat=E2=80=9D technological cost hindered this set-up. Pr=
esent locations (rural centers) where the project was deployed don=E2=80=99=
t have any internet connection and the installation/maintenance of it is re=
latively expensive (the doctor said it=E2=80=99s not really possible for ru=
ral areas, not at these present times).
So our next model is to utilize SMS messaging (which is very popular here i=
n the Philippines) to query/update the data from server.
Model2:
[b]
workstations(center) <----------{intranet}---------->server(center) <------=
----{GSM}---------->phone(remote area)[/b]
=09But then again, even this greatly cheaper set-up (unlimited SMS messagin=
g/=E2=80=9Dtexting=E2=80=9D in this country would cost only ~0.50$ a day) w=
as not agreed to be effective, again, due to its expected =E2=80=9Caccumula=
tive high cost=E2=80=9D. (As you could see, developing countries barely pri=
oritize health concerns of the public)
So the final resort is to make a low- or no-cost maintenance set-up. Thus =
came the =E2=80=9Cstrange=E2=80=9D idea of storing the whole database on th=
e phone. For this method, the health workers obtain the updated/latest cop=
y of the database for their work in the remote area, and as they will retur=
n into the center (once a week), the data gathered/edited is synchronized/u=
pdated into the database server and their copy of the database is also upda=
ted (along with the updates from the center and from workers in different r=
emote areas).=20
Model 3:
[b] workstations(center) <-------{intranet}------>server(center) <--------{=
Bluetooth}------->phone(center after a week in remote area)[/b]
The doctor even suggested the elimination of the workstations in the health=
center by substituting a mobile phone. He believes that this set-up will c=
ut the cost of installing the project in a rural area.=20
Model xxx:
[b]phones(static in center) <------{ Bluetooth }----->server(center) <-----=
--{Bluetooth}------>phone(center after a week in remote area)[/b]
So that=E2=80=99s the long story of our project. :)
In the past, the problem is the cost. Now, the performance and even the att=
ainability of the set-up.
p.s. MIDlet would connect into a Java swing interface in the server that co=
mmunicate to the present MySQL database
[Message sent by forum member 'public2public' (public2public)]
http://forums.java.net/jive/thread.jspa?messageID=3D298040
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
[email protected] and include in the body of the message "help".